SEO and file names

“I am curious to get additional input on the imortance of file names
(i.e. keyword.html) as it relates to SEO. Some experts advise to name
website files using keywords, and others are silent on the subject.
Given the formula for page density, # of inbound links and the actual
text of the inbound links, I don’t know where the name of the file can
fit into the equation.”

No changes were made to the page so it seems to have risen on its own
accord. AFAIK know, no additional links have been added, so this is all
on-page. On it is already ranked 6th. With just one page and
4 links all originating from a dmoz listing. there are over 70,000
pages competing for the exact phrase “webmaster community”.

There is plenty of disagreement about whether exact keywords as domain
name helps or not. I think this is highlighting that it might just be
an important factor and the sole reason is not just about link text in
keyword domains.

I think the question of keywords in file names is one of the very good
examples of how dynamic algorithms works in search engines. You can
find valid examples where a keyword in the file name seems to be the
dertermining factor and other examples that show it’s clearly not –
competitive or non-competitive. It makes analysis very confusing. Not
only do we have to understand what role a parameter like this (out of
hundreds) influence on rankings but also when it does so – in which

In my personal experience keywords in file names are one of the less
significant ranking factors. For most searches it dosen’t seem to me to
be a very important factor and for the few where it is I most often
find it very easy to compete against – even with file names without the
keyword. So, in other words, I have personally found it to mostly be a
determening factor for less competitive searches.

I believe it used to matter more. Expecially in Google.
Mikkel deMib Svendsen

The real question is not if keywords help in file names [they do] but if they help more or less than a shorter url.

Imagine you are a search engine;…you-like-it.htm

Which is likely to contain the “best” content?
/> Which is likely to contain the “best” content?

This is a very interesting question. Many of you probably remember the
analysis Yahoo did, I think it was last year, where they tested the
quality of pages with various number of hyphens in them. As I remember
they said the quality dramatically went down after two!

I am pretty sure they make similar analysis of URL-length, complexity
and other such things all the time. And you are right NFFC, such
testings may very well show that, generally, shorter URLs contain
better content. If the analysis show that, in general, be asured it
will be used. However, I have no solid proof that is in fact the case
today. I do not that very long URL’s hurt your but I am actually not
certain about the exact cutt off.


What is certain is that on Google search result listing, though not in
all, keywords in file names are EMPAHSIZED. That’s why I know it is

You can’t draw that conclusion based on what Google chose to show. What
they show and highlight in a listing is not the same as how they rank
pages. Ranking algo’s is a million times more complex than what they
show (and thats probably wise if they want to keep the majority of
average users! )

why not just


10 fundamental rules for the age of user experience technology

1) More features isn’t better, it’s worse.
2) You can’t make things easier by adding to them.
3) Confusion is the ultimate deal-breaker.
4) Style matters
5) Only features that provide a good user experience will be used.
6) Any feature that requires learning will only be adopted by a small fraction of users.
7) Unused features are not only useless, they can slow you down and diminish ease of use.
8) Users do not want to think about technology: what really counts is what it does for them.
9) Forget about the killer feature. Welcome to the age of the killer user-experience.
10) Less is difficult, that’s why less is more



People like narratives. They understand them. Narratives also affect the way people process information. If you use stories to present information to consumers you can influence their decision making process, their emotions, and their intention to purchase.

What may be even more interesting […] is the impact that stories have on the way we do our work.

When we use stories […] we are using a powerful method that fits the way people think, learn, and process information.

We have always noticed that when we use stories this way it helps get buy-in from stakeholders […] Now we know there is a research basis for the power of the story.”




People like narratives. They
understand them. Narratives also affect the way people process
information. If you use stories to present information to consumers you
can influence their decision making process, their emotions, and their
intention to purchase.

What may be even more interesting […] is the impact that stories have on the way we do our work.

When we use stories […] we are using a powerful method that fits the way people think, learn, and process information.

have always noticed that when we use stories this way it helps get
buy-in from stakeholders […] Now we know there is a research basis
for the power of the story.”



Benefits of Fast Iterations

  • Fail Fast
    A major benefit of fast iteration is you also fail fast. Failing fast means
    you invest less time in the things that don’t work. If you quickly find out
    what works and what doesn’t work, then you take action to turn it into something
    that does work.

    Ironically, teams that fail fast improve as fast, if not faster, than those
    who try to get it right the first time. The reason is simple: Teams trying
    to get it right the first time fail as often as everyone else does. However,
    when they fail, they fail really slowly and struggle to pinpoint problems because
    they’ve changed so much at once, making it harder to identify solutions

  • More Experimentation
    The faster you fail, the more experimentation you can do. You can try out
    ideas that might not have a lot of support, but could be potential winners.
    This allows for an innovative environment.

    Perhaps you’ve heard of Google’s 20% time? They expect their engineers to
    work 20% of their time on a personal project — an experiment they find personally
    interesting. This program has the effect of bootstrapping experimentation,
    so it will happen more often.

  • Learn Quickly
    We’ve all had the experience of sitting in meetings arguing whether something
    will work or not. Usually, both sides just don’t have enough data to go on,
    and they end up going with their gut or with the loudest arguer (for better
    or worse). Fast iteration helps solve this problem by giving developers a platform
    on which they can test quickly, helping to collect data about any outstanding
    questions instead of resorting to opinionated arguments.
  • Provide Continuing Interest
    In addition to improving your design, fast iterations may have a psychological
    effect on users. Those users who use your app with any frequency will notice
    the changes, and if the good ones stick, they’ll appreciate your ongoing efforts
    to improve.

    The best teams not only design the changes, but design the process for introducing
    the change. They experiment with methods to overcome the users’ natural resistance
    to change, providing migration paths and clear benefits for each improvement.

  • Reduced Risk
    Quickly iterating helps reduce risk during design. If teams can make many
    small changes instead of a few larger ones, they mitigate risk because they
    know which changes have what effect. If a design team makes many changes at
    once, they have a harder time knowing which parts work and which parts don’t.
    When you make only one or two changes at a time, you know immediately what
    effect it has. Reducing risk is a valuable outcome of moving to fast iteration.

Side Effects

These benefits don’t come easy. There are significant changes design teams
have to make to their core process to iterate quickly. It’s not a switch a
team can turn on or off.

  • Culture Change
    Most designers are accustomed to long release cycles. Fast iteration and fast
    evolution of design creates a different kind of design environment.
    Gone are the grand visions of the redesign, where teams spend months retooling
    vast areas of the site. Replacing it is the idea that the site is a living,
    breathing design that needs constant care and attention. The team at Netflix
    calls themselves “compulsive data wonks”. They rarely dream very
    far in the future. Instead, they’re concerned with what’s happening right now.
  • Design Determinism
    When teams make the switch to fast iteration, it changes the site’s testing
    methodology. Testing becomes ongoing. After a release, you test for a certain
    period of time to determine what to keep and what to throw away. Then you start
    the process over again immediately. And repeat.

    To some designers this sounds overly deterministic: Doesn’t this take the
    fun out of design? If all the decisions are cut-and-dried, what does that say
    about creativity? What about longer-term effects? Is it possible that some
    features take longer to catch on than others, and that an early flop might
    not mean it’s not a valuable feature? With fast iterations, if the feature
    doesn’t work now, then it’s not right for the site, no matter how creative
    it is.

  • You’re Either With Us…
    Netflix’s Chief Talent Officer, Patty McCord, told us their process of fast
    iteration causes uncomfortable situations for some designers. Once, a designer
    had spent time and energy working on a feature that testing showed didn’t work.
    When it came time for the team to remove the feature from the site, the designer
    was distraught. He had become too emotionally invested in his design, and it
    got in the way of his job. He ended up parting ways with the team and moving
    on. Unfortunately, the process of fast iteration affected more than the product

Release Early, Release Often

Eric Raymond, in his famous work, The Cathedral and the Bazaar, wrote the
words organizations like Netflix live by: release
early, release often
. At the time, Raymond was referring to software
created in the open commons, by thousands of people, with little or no delivery

This dictum now applies equally well to web-application development. Fast
iterations provide the freedom to innovate because teams can test more features.
This reduces the risk of each tested feature. However, it takes getting used
to and not everyone adjusts so easily. As with most design processes, teams
get the most benefit from quick iterations when they fully embrace the process.


Empowerment Divide

Participation inequality
is one exponent of the empowerment divide that has held constant
throughout all the years of Internet growth: in social networks and
community systems, about 90% of users don’t contribute, 9% contribute
sporadically, and a tiny minority of 1% accounts for most contributions.


Usability Divide

Far worse than the economic divide is the fact that technology remains
so complicated that many people couldn’t use a computer even if they
got one for free. Many others can use computers, but don’t achieve the
modern world’s full benefits because most of the available services are
too difficult for them to understand.

Almost 40% of the population has lower literacy skills, and yet few websites follow the guidelines for writing for low-literacy users.
Even government sites that target poorer citizens are usually written
at a level that requires a university degree to comprehend. The British
government has done some good work on simplifying much of its site information, but even it requires at least a high
school education to easily read.

Lower literacy is the Web’s biggest accessibility problem, but nobody cares about this massive user group.

Senior citizens face the second-biggest accessibility problem, but again there is little interest in the guidelines for making websites easier for older users.
Companies don’t even have the excuse that it doesn’t pay to cater to
this audience, because retirees are rich these days. Even though
seniors are the main remaining source of growth in Internet use,
companies are still endlessly fascinated by young users and ignore
older, richer users who would be much more loyal customers — if only
someone bothered to sell to them.

Whereas the economic divide is closing rapidly, I see little
progress on the usability divide. Usability is improving for higher-end
users. For this group, websites get easier every year, generating vast
profits for site owners. Because they now follow more e-commerce user experience
guidelines, companies that sell online typically have conversion rates
of around 2%, which is twice the conversion rate of the bubble years.
That’s all great news for high-end users, but the less-skilled 40% of
users have seen little in the way of usability improvement. We know how
to help these users — we’re simply not doing it.


Still listening

I know I said we should listen to our outraged users. 

But I didn’t mean we should ignore all our
happy, contented users as well.  Nor do I
suggest that we pay attention to the folks who like some features, but dislike
others.  (Ah, they inhabit the zone of mediocre

Instead, we have to listen to them all, then show good taste
in figuring out which of the voices have value to them.  Sometimes it’s the screamers that make the
good points about your product (no matter how hard it is to get over the
emotional tumult of their delivery), and sometimes it’s the quiet voices with
the critical commentary.

Let me go all Zen on you for a minute and suggest that what
you–as  skilled practitioners of software
/ product / services / education—need to do. 

Listen while being still.

My previous post about listening to the screamers was all
about how to set aside your immediate emotional reaction to their delivery and
look for the nuggets of truth and insight within the scream. 

The same is true for anyone who’s willing to give you some
feedback.  Listen without reacting so you
can hear the valuable bits of what they say. I know this means you have to do a little emotional work on your part,
mostly suppressing your own reaction to their reaction… but you can do it.  If Spock can do it, so can you.

I mentioned the value of hearing someone describe my early
software as “white, male, fascist.”  It
stung to hear that.  That was a great
example of listening to a screamer’s voice. 

But just a few weeks ago I was doing a field study, listening
to a user talking about how hard it is to do some kinds of web searches. “I don’t know,” she said, “I think there’s
got to be a way to find this, but how?”

This was a busy Mom with three little kids (one in her arm as we were talking),
a dog and the plumber all wandering through the house. Even though her house was busy, she literally
spoke quietly and calmly. 

Of course, I could tell her how to use an advanced
maybe show her the advanced search page.  “Ah.. that’s it!
I’ll show her the advanced search!”  I think to myself, “get
her onto the road to
being a power user.” 

Proudly I showed how with one click she could get to a page
with all kinds of power search features.  Tools that I knew would give her exactly the
skills and capabilities she needed to do an instant, precise and potent web

“Oooh.” She said,
upon seeing that page with all the options. It wasn’t a happy
“oooh” either.  I looked at her eyes to see what she was
looking at, and I could immediately see that she didn’t know what
to focus on,
her eyes revealed the truth as they swept from side-to-side, looking
something familiar.  There are a lot of
features and options on the page, perhaps a few too many.

So I asked a very non-techy question: “Umm…
How do you feel about this?”   It’s a low-tech but
high-touch question. It’s
deliberately non-leading and open-ended. 

And she proceeded to talk for another minute about how that
particular page was “scary and intimidating.”   What do you know.

I’ve never thought about a web page, especially a search
page, as being “scary” — but here she was, telling me that it’s a frightening
thing.  Unpacking WHY it gave her that
moment’s pause has been the most illuminating thing I’ve learned this month. 

So the flip side of the screaming user is the user that says
“ooh” in a quiet voice.  Those voices are
important too. Our job is to hear all
the tones and semitones in what our users are saying, and be still enough in
ourselves to be able to understand what it all means. 


Thoughts on the Impending Death of Information Architecture

The simple idea that people’s actions model meaning better than a
directory (even a flexible directory) is a critical step forward in
thinking about the Web. The innovation we’re seeing with
folksonomies, recommendation systems, social networking
sites…all have their roots in the idea that modeling what people
actually do on the Web is the best way to provide answers for them.
And, perhaps more importantly, it is an admission that we simply
can’t predict the future…we can’t design a perfect
information architecture, and to attempt to implies that the world
we’re modeling doesn’t change.