Redirects and SEO

79 views
Skip to first unread message

Martimiz

unread,
May 29, 2015, 7:15:50 AM5/29/15
to silverst...@googlegroups.com
Hi guys,

I'm starting this topic because of a request I had concerning my LanguagePrefix module. It's a module that works with Translatable and lets you have a language prefix like /nl/ in front of the URL.

Some people wanted a custom setting where you can leave out the prefix for  the default language and just use it for secundairy languages - someone thought that that would even be better SEO-wise. And someone else thought it would not :). This brings me to my questions:

a. Would a solution like that really be better SEO-wise, or worse?
b. Would just displaying an older link, instead of 301-ing, be considered duplicate content (since it isn't really part of the site navigation)?
c. More general: how should we go about (re)directing requests. For instance: 301-redirecting older links to current links has always been part of SilverStripe. But on a multilingual site there are more options thinkable. So I'm thinking: any link that could have been used before, should be 301, redirected?

1. Suppose en is the default language for which we omit the prefix, then /en/about-us/ (with prefix) should probably be redirected to /about-us
2. But if  /over-ons points to a dutch page, should it be redirected to /nl/over-ons/ or considered a non-existing english (default) page?
3. If the prefix is not or no longer omitted, /about-us should now probably be redirected to /en/about-us/
4. Something like /nl/about-us/ should be considered a non-existing dutch page and be 404-ed in Dutch, because it probably was never used
5. ...????


I'm not much of a SEO expert, but I'd really like to do this the right way, so any thoughts are most welcome

Thanks, Martine




Patrick Nelson

unread,
May 29, 2015, 10:20:29 AM5/29/15
to silverst...@googlegroups.com
SEO can be magic ("Some may say..."), which I don't like, but - certain things are certainly more objective. Having a prefix vs. no prefix? Only matters possibly in terms of diluting keywords located in the URL. If it's 2 chars, I'd not worry about it. The other concern is more canonical (i.e. authoritative page for content, in case there is dupe content within the page). Personally I'd suggest consistency between all languages, but that's me.

-- tangent --

On another note (and possible tangent): I literally just dealt with overriding 404 pages to facilitate handling a custom (complex) redirect, in case a page was imported (from old version of the site) and moved to another location and that was a huge PITA. In this case, that 404 may still have an English language equivalent that you'd like to failover to -- how do you do that? Well, that's a good question and I'm very glad you asked, and Welcome to SilverStripe! To allow 404's to still 301 redirect to a new location (if that were something you needed) this might be how you'd do it (I'm sorry I know how to do this):
  1. Define a CustomErrorPage_Controller which extends Page_Controller
  2. Define a "CustomErrorPage_Controller" in your YML config as an override
  3. In the handleRequest() method, you'll want to just check to see if the current $this->ErrorCode is == 404 and then throw in custom logic there, but wait, there's more to it...
  4. Create another class called CustomSS_HTTPResponse which extends SS_HTTPResponse. Why? Because...
  5. If in the ->handleRequest() above you need to redirect and you return a response to redirect, the code get's clobbered and overridden to 404 again, which we cannot have.
  6. In your new CustomSS_HTTPResponse class, just ensure that once the ->setCode() method is called, only allow changing the code if currently still the default of 200
-- end tangent --

Phew -- just FYI incase you do want to use the 404 route to failover to a 301 for a better page alternative. From a cultural standpoint, I'd be willing to wager that a reasonable amount of the "nl" speakers would at least be likely to understand "en". Only caveat there is that now their experience has just been converted to entirely being English which they obviously may not prefer. 

- Patrick



--
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.

Martimiz

unread,
Jun 30, 2015, 7:20:19 AM6/30/15
to silverst...@googlegroups.com
Hi Patrick

First of all I want to apologize for my late reaction, especially after you made such an effort to reply!! I'm not going into all kinds of explanations, I'm just sorry!

After what you said, I've been reading up on this again and you are absolutely right - language prefixes is something that Google doesn't (or does no longer) use, so it's basically just for the benefit of users knowing where they are. And maybe usable if you want to use the same urlsegment throughout languages (think 'contact'). So there's me making such a fuss about almost nothing :(

Thanks for your ideas about redirecting 404's. I wasn't actually thinking of implementing something like that - it was more a question of either returning a 404 or a redirect. But it sure is an interesting (and weirdly complex) concept. I admire you for knowing how and understand you wanting to let that knowledge go :)

Anyway - thanks again,

Martine (still red in the face)
Reply all
Reply to author
Forward
0 new messages