Webmaster Central Blog
Official news on crawling and indexing sites for the Google index
To slash or not to slash
środa, kwietnia 21, 2010
Webmaster Level: Intermediate
That is the question we hear often. Onward to the answers! Historically, it’s common for URLs with a trailing slash to indicate a directory, and those without a trailing slash to denote a file:
http://example.com/foo/
(with trailing slash, conventionally a directory)
http://example.com/foo
(without trailing slash, conventionally a file)
But they certainly don’t have to. Google treats each URL above separately (and equally) regardless of whether it’s a file or a directory, or it contains a trailing slash or it doesn’t contain a trailing slash.
Different content on / and no-/ URLs okay for Google, often less ideal for users
From a technical, search engine standpoint, it’s certainly permissible for these two URL versions to contain different content. Your users, however, may find this configuration horribly confusing -- just imagine if
www.google.com/webmasters
and
www.google.com/webmasters/
produced two separate experiences.
For this reason, trailing slash and non-trailing slash URLs often serve the same content. The most common case is when a site is configured with a directory structure:
http://example.com/parent-directory/child-directory/
Your site’s configuration and your options
You can do a quick check on your site to see if the URLs:
http://<your-domain-here>/<some-directory-here>/
(with trailing slash)
http://<your-domain-here>/<some-directory-here>
(no trailing slash)
don’t both return a
200 response code
, but that one version
redirects
to the other.
If only one version can be returned (i.e., the other redirects to it), that’s great! This behavior is beneficial because it reduces
duplicate content
. In the particular case of redirects to trailing slash URLs, our search results will likely show the version of the URL with the 200 response code (most often the trailing slash URL) -- regardless of whether the redirect was a 301 or 302.
If both slash and non-trailing-slash versions contain the same content and each returns 200, you can:
Consider changing this behavior (more info below) to reduce duplicate content and improve
crawl efficiency
.
Leave it as-is. Many sites have duplicate content. Our indexing process often handles this case for webmasters and users. While it’s not totally optimal behavior, it’s perfectly legitimate and a-okay. :)
Rest assured that for your root URL specifically,
http://example.com
is equivalent to
http://example.com/
and can’t be redirected even if you’re Chuck Norris.
Steps for serving only one URL version
What if your site serves duplicate content on these two URLs:
http://<your-domain-here>/<some-directory-here>/
http://<your-domain-here>/<some-directory-here>
meaning that both URLs return 200 (neither has a redirect or contains
rel=”canonical”
), and you want to change the situation?
Choose one URL as the preferred version. If your site has a directory structure, it’s more conventional to use a trailing slash with your directory URLs (e.g.,
example.com/directory/
rather than
example.com/directory
), but you’re free to choose whichever you like.
Be consistent with the preferred version. Use it in your internal links. If you have a
Sitemap
, include the preferred version (and don’t include the duplicate URL).
Use a 301 redirect from the duplicate to the preferred version. If that’s not possible, rel=”canonical” is a strong option. rel=”canonical” works similarly to a 301 for Google’s indexing purposes, and other major search engines as well.
Test your 301 configuration through
Fetch as Googlebot
in
Webmaster Tools
. Make sure your URLs:
http://example.com/foo/
http://example.com/foo
are behaving as expected. The preferred version should return 200. The duplicate URL should 301 to the preferred URL.
Check for
Crawl errors
in Webmaster Tools, and, if possible, your webserver logs as a sanity check that the 301s are implemented.
Profit! (just kidding) But you can bask in the sunshine of your efficient server configuration, warmed by the knowledge that your site is better optimized.
Written by Maile Ohye, Developer Programs Tech Lead
Hey!
Check here if your site is mobile-friendly.
Etykiety
accessibility
10
advanced
195
AMP
13
Android
2
API
7
apps
7
autocomplete
2
beginner
173
CAPTCHA
1
Chrome
2
cms
1
crawling and indexing
158
encryption
3
events
51
feedback and communication
83
forums
5
general tips
90
geotargeting
1
Google Assistant
3
Google I/O
3
Google Images
3
Google News
2
hacked sites
12
hangout
2
hreflang
3
https
5
images
12
intermediate
205
interstitials
1
javascript
8
job search
2
localization
21
malware
6
mobile
63
mobile-friendly
14
nohacked
1
performance
17
product expert
1
product experts
2
products and services
63
questions
3
ranking
1
recipes
1
rendering
2
Responsive Web Design
3
rich cards
7
rich results
10
search console
35
search for beginners
1
search queries
7
search results
140
security
12
seo
3
sitemaps
46
speed
6
structured data
33
summit
1
TLDs
1
url removals
1
UX
3
verification
8
video
6
webmaster community
24
webmaster forum
1
webmaster guidelines
57
webmaster tools
177
webmasters
3
youtube channel
6
Archive
2020
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2019
gru
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2018
gru
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2017
gru
lis
paź
wrz
sie
cze
maj
kwi
mar
lut
sty
2016
gru
lis
paź
wrz
sie
cze
maj
kwi
mar
sty
2015
gru
lis
paź
wrz
sie
lip
maj
kwi
mar
lut
sty
2014
gru
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2013
gru
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2012
gru
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2011
gru
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2010
gru
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2009
gru
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2008
gru
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2007
gru
lis
paź
wrz
sie
lip
cze
maj
kwi
mar
lut
sty
2006
gru
lis
paź
wrz
sie
Feed
Follow @googlewmc
Give us feedback in our
Product Forums
.
Subscribe via email
Enter your email address:
Delivered by
FeedBurner