trailing slash on urls - does it matter in terms of SEO

[Nicolaas Thiemen Francken - Sunny Side Up]

Hi

It appears to me that Silverstripe allows both mysite.co.nz/foo and mysite.co.nz/foo/

http://www.silverstripe.org/community

vs 

http://www.silverstripe.org/community/

However, I also noticed:

http://www.silverstripe.com/services/website-and-application-development

redirects to

http://www.silverstripe.com/services/website-and-application-development/

From my reading, Google does not have a strong preference on what is better, but it does treat them as separate pages.

A client of mine alerted me of this through their SEO partner.  I pointed out to her that all the links on the site have a trailing slash - but the problem is that the client had also created their own links, without the final slash, and thus both pages were being indexed by Google - from what I understand.

Are there any solutions out there?  Writing an .htaccess rule is the obvious one, but I am scared we are going to overlook some important exception that is going to create some other bug or problem.

Thank you

Nicolaas

[Patrick Nelson]

Yeah, this was a problem for us as well. In our "Page" object, I implemented the following on the ->init() method:

public function init() {
   parent::init();

   // Perform a redirect if not at the correct URL (just a difference in the trailing slash, to be safe).
   $uri = $_SERVER["REQUEST_URI"];
   $correct = $this->Link();
   if ($uri != $correct && rtrim($uri, "/") == rtrim($correct, "/")) return $this->redirect($correct, 301);
}

I wonder if this is the sort of thing that belongs in core? Maybe provide a private static setting of "$require_trailing_slash" (or something) with the default value set to true.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Will Rossiter]

I had a patch that never made it in / closed which we use.. Ref: https://github.com/silverstripe/silverstripe-cms/issues/327 - http://pastie.org/2373435

[Richard Rudy]

My solution is to use a canonical tag in the head that all the juice stays with one URL, though a more an more native solution is nice. 

Sent from my iPhone

[Nicolaas Thiemen Francken - Sunny Side Up]

awesome info and feedback

here is an article on canonical tag: https://support.google.com/webmasters/answer/139066?hl=en

Nicolaas Thiemen Francken
  www.sunnysideup.co.nz

  phone: +64221697577

[Marijn Kampf]

A possible SEO downside is that I'm pretty sure that Google (used to) recommended against using 301 redirects in your site's internal navigation if at all possible. Best solution would be to get your users to add the trailing slash in the original link.

Marijn

[Patrick Nelson]

Marijn, do you happen to have a source for that? I thought 301 functionality was symmetric regardless of where it was used.

[Marijn Kampf]

It's on my SEO checklist that I started using in 2004 :) I can't remember the source the closest current one is https://developers.google.com/speed/docs/insights/AvoidRedirects which focusses on landing pages. As speed has become a bigger SEO factor I still believe it's relevant. My reasoning is the redirect adds additional time/server load which can be easily avoided (if you can convince your users to implement it that is).

Marijn Kampf
Exadium - Online Marketing & Web Development
www.exadium.com

[Patrick Nelson]

I see. At first I thought you were suggesting it affected page rank. Still, it's a good argument to persist the redirects to help ensure those who incorrectly link the URL will copy/paste the correct one and theoretically that would reduce the overall number of invalidly linked pages due to the internal setup to perform auto redirect (plus you gain client side caching for free for past visitors). Then again canonical works just as well for these purposes (notwithstanding the "reduced invalid link" theory I got going). 

In this case the article is citing speed issues due to multiple redirects due to internal linking issues like multiple going to the same page or several redirects in a row. In this scenario SS may have less overall issues (especially with my sample code) since it already is very good at consistent linking (via SiteTree->Link()) and all of those will include the trailing slash.

I don't know, maybe it's just me, but if you've setup a structure (e.g. Always have trailing slash or never have it) and to allow both just sort of triggers a deep OCD; dammit, there can be only One True URL. 

Sent from my iPad

[Nicolaas Thiemen Francken - Sunny Side Up]

I reckon ...  the best solution would be to let urls without trailing / go to 404 - rather than writing some awkward double-check plus redirect that bloats the core / htaccess rules / ???. Basically, the Link method should always return a link with a / at the end. 

Is that a bad idea?

Nicolaas

​

[clyons]

I'd say so, considering people occasionally type URLs and may omit the trailing slash.

[Patrick Nelson]

Yes, an unrecoverable 404 failure when there's an easy automated method of recovery is profoundly worse than 3 lines of bloat. You assessment is correct.

--

[Daniel Hensby]

Having duplicate content on a URL and then the exact same one with a trailing slash will not hurt page rank in any way.

Duplicate content in this way is a myth - http://searchengineland.com/googles-matt-cutts-duplicate-content-wont-hurt-you-unless-it-is-spammy-167459

Google has said time and time again, duplicate content issues are rarely a penalty. It is more about Google knowing which page they should rank and which page they should not. Google doesn’t want to show the same content to searchers for the same query; they do like to diversify the results to their searchers.

Google, built on top of building some of the most clever algorithms, is not going to be confused by the fact you have pages that return with and without a slash.

To even discuss this problem is a waste of time :P

On Friday, 19 June 2015 16:09:57 UTC+1, Patrick Nelson wrote:

Yes, an unrecoverable 404 failure when there's an easy automated method of recovery is profoundly worse than 3 lines of bloat. You assessment is correct.

[Olli Tyynelä]

It gets really tricky to convoy the pointless of that to a client that has got the seo audit from a third party company. It's easier to comply to their suggestions than try to tell why the seo company is wrong or shouldn't worry about it. Some of the seo suggestions rely on voodoo in some extent :)

We use our custom meta script that outputs the canonization with or without the trailing slash.. Cant remember what we ended up using. That way you don't have to worry about it at all and don't have to do redirects etc.
 

Our custom meta takes care of the opengraph tags also some sharing also.

:Olli 

Lähetetty iPhonesta

[Olli Tyynelä]

Showing 404 for users that didn't remember to put the / end is really bad idea imho. 

As Apache and nginx will serve index file from a folder by default with or with the / as far as I know.

So best thing is to use canonization as that's purpose is to tell search engines what's is the correct url for indexing purposes.

If the user gets / sees a different url it's presentation for the user but data wise we tell crawler the right one with meta that they see.

:olli

Lähetetty iPhonesta

[Marcus Nyeholt]

I actually prefer the unslahed url as being the "correct" version. From Apache's perspective, the / historically meanst to return the index of the requested folder, ie return index.html or display a list of contained files. The resource itself doesn't have a slash at the end.

[Patrick Nelson]

Completely tangential at this point, but: I can actually agree from aesthetics actually. When I setup my redirect I thought about this for a little while and concluded that trailing slash would be best because, logically, many of the pages on the site will be base pages which will contain more pages. That directory metaphor stops there, however,  because in SS you can access both with and without a trailing slash, where as you indicated the slash IS the directory and effectively also the index page, where that same page (not accessible without the slash) is then only alternatively accessible even deeper in the URL at ./index.html. 

So, with any page potentially being able to have a sub page,Andy continuing with the concept that a trailing slash implies there could be deeper pages, I retained it for all pages. Helps to just keep it simple and stick with one format. You can use a single format for either approach, but that's at least my rationale. 

TL;DR, I crack my eggs open on the larger side only. 

Sent from my iPad

[Daniel Hensby]

Using canonical tags is very risky because pages with custom actions need special rules, so unless you're very careful you can cause silent errors.

Using a 301 is slow, depending on whether every link ends up being 301ed due to the default output or not. However, when deciding to have or not have a slash, the best rule of thumb is to not have one. You can make the most generic rule which won't start breaking links to actual files.

You'll give yourself more of a penalty with Google by slowing your site through constant 301s, or 404s on arbitrarily different URLs, or erroneous canonicals.

The easiest way to explain it to a client is that Google works to provide the most relevant and best experience to a search user to find what they are looking for. Does consistently removing or adding a trailing slash affect the experience of the user? No. But slowness does.

Ultimately, the delay to do a 301 (via htaccess) will be pretty neglagable, but if you're arguing over unifying trailing slashes on URLs, the delay from 301s is much more of an issue to focus on.

If you have a client or their agency saying you have to do it, just charge for it and do it. I'm not sure it's worth perpetuating this myth on dev mailinglists to do that.

Dan

[Olli Tyynelä]

Valid points there Dan.

The point that i was trying to make with the client comment and relates to this:

"The easiest way to explain it to a client is that Google works to pro" 

Believe me, i have tired so no its not, well not at least here in Finland and depends frankly on the mood of so many peope: your project manager, account manager or the client, who did the seo thingy and so on. Its easier not to get in to a peeing contents with the seo company.. well at least on the / thing :).

In our canonization worked as a compromise that basically satisfied the seo peeps without having to start doing redirects.

> If you have a client or their agency saying you have to do it, just charge for it and do it. I'm not sure it's worth perpetuating this myth on dev mailinglists to do that.

I wasn't trying not to perpetuating any myth. I was just giving my own point of view on the / matter and clarify the rationale behind the decisions that we had made: as an alternative way of handling it wihtout any redirects for the user.

:Olli

[Nicolaas Thiemen Francken - Sunny Side Up]

reading all the comments, I feel the best thing to do is to do nothing about these slashes or lack thereof ;-)

​

[Patrick Nelson]

> On Jun 20, 2015, at 3:18 AM, Daniel Hensby <d...@hens.by> wrote:
>
> Using a 301 is slow, depending on whether every link ends up being 301ed due to the default output or not. However, when deciding to have or not have a slash, the best rule of thumb is to not have one. You can make the most generic rule which won't start breaking links to actual files.

Thankfully in my case it isn't at all since the only way you'll get a 301 is due to manual entry. Everything is linked internally via SS's ->Link() method on SiteTree which contains the trailing slash already, and the Page->init() is simply comparing current URL to the presumed "correct" URL (since SS will show the same page at both for some reason) and then happily redirects if needed.

Sent from my iPad