Newsletter
Email:
Poll: Like Our New Look?
Do you like our new SEO.tv look & feel?
Home | Google | How Google interprets underscores and dashes in a URL for Search Engine Optimization

How Google interprets underscores and dashes in a URL for Search Engine Optimization

Font size: Decrease font Enlarge font

How Google interprets underscores and dashes in a URL for Search Engine Optimization

 

MATT CUTTS: Hi, everybody.
I wanted to give you an
update on underscores
versus dashes in URLs.
This is something that a lot of
people have asked me about.
And I had talked about
it a long time ago.
And so I figured it was
time for an update.
So first, let me give a little
bit of history about why,
whenever we see an underscore,
we join that in the URL rather
than separate using that.
So what I mean?
Well, if you say red dash widget
in a URL, we view that
dash as a separator.
So we index the word red, and
we index the word widget.
And those are separate.
Whereas if you were to have War
of 1812 with underscores--
so, war of 1812--
instead of separating on the
underscores we actually glom
all those together.
So that's one term that you
could find by searching for
war underscore of
underscore 1812.
Seems kind of weird.
So why does Google
do it that way?
Well, whenever we started,
AltaVista was huge.
We were just this little
tiny company.
And we were all very techie.
Lots of computer programmers.
And we wanted to find exactly
what we wanted as far as
terms. We really cared
about precision.
And so whenever you are a
programmer, you often have
things like, if you're a
C programmer, you might
recognize TMP underscore MAX.
And so, if you are a programmer,
you want to be
able to search for that term and
find TMP underscore MAX--
and that exact term.
Not just TMP and MAX that happen
to be on the page.
So it was because the original
engineers were programmers,
and the programmers wanted
to be able to search for
programming terms, that we
joined based on the underscore
rather than having that
act as a separator.
Now in practical terms, it
doesn't make that much of a
difference.
It's kind of what we call
a second order effect.
It's not a primary thing that
really makes a huge
difference.
For example, Wikipedia has a
lot of pages that say war
underscore of underscore 1812.
That doesn't keep Wikipedia
from ranking.
Because there's page
rank, there's
proximity, there's title.
There's all the other signals
that we use, over 200 of them.
But if you are going
to make a site and
you're starting fresh--
so you've got a blank
slate to work with--
I would probably go ahead
and go with dashes.
And I would continue to go with
dashes at least for the
foreseeable future.
We had thought about doing a
little project to split on
underscores a few years ago.
But it turns out the amount of
impact it has in our rankings
is relatively low.
And it turns out, to get
engineers to do that versus
some other projects--
there were other higher impact
projects that we could have
them work on.
So at least for the time being,
we still join on the
underscore and separate
on the dash.
So a few people had asked, you
were thinking about splitting
on the underscore, do
you do that yet?
The answer is no.
I don't know when we will.
Nobody is slated to be
working on that.
So at least for the time being,
it's better to stick
with a dash.
Now if you already have a
website, if it already uses
underscores, and if it already
works the way you want, don't
go back and rewrite
every single URL.
I would only bother when it's
a brand new website, when
you're really working
on something fresh.
When you're trying to say to
yourself, OK, I can do this
anyway I want, then that's
a pretty good
time to go for dashes.
If you've already made the
choice and you happen to use
underscores, I really wouldn't
worry about it that much.
It's not a huge factor.
But I just wanted to explain a
little bit about the kinds of
reasons why we would do that
in the first place and just
give a little bit of context
and a little bit of update.

 

 

  • email Email to a friend
  • print Print version
  • Plain text Plain text
Tags
No tags for this article