Thanks to Søren Sprogø from Afdeling18 we've been aware that there might be a problem for correct Google indexing of certain pages if you use the RSS Community Package.
According to Søren this is due to Google using the guid attribute (ie. /26156) from the RSS to index the Umbraco pages but it detects it as duplicate content if already have indexed the content using the niceurl (ie. /blog/2009/4/7/how-to-migrate-umbraco-40-to-iis-7-and-aspnet-35).
What's the best solution - 301 or 302 redirects?
The solution to this is to make Umbraco detect if there's an incoming guid link (ie. yoursite.com/pageid) and then do a redirect and I'll look at implementing this for 4.0.2 (with the option of disabling it).
The big question is then - should it be a 301 redirect (permanent) or a 302 redirect (temporary). In my logic it should be a 302 as the whole point of a guid link is to ensure it won't change (and the id won't change, but the nice url might if a page title is changed). Søren argues that to fix the Google problem it needs to be a 301, which would be very sad as the whole point of ensuring links over time is then lost.
I've looked at how Wordpress handles this and it seems that hosted blogs (on wordpress.com) uses 302 redirects, while many Wordpress installs uses 301.
So calling all SEO/Google/RSS experts - what should we do?
My thinking is it should be a 301 redirect - permanent - because you want google to index the nice URL for seo, not the guid - a human readable URL rather than a guid is better for your pagerank...
I would go with the 301 if I had to choose. But why not make it configurable for the user? If you are going to create a setting for disabling it, why not create a setting for which type of redirect you want? *GuidRedirect=Enabled *GuidRedirectType=301
Are the GUID URI's supposed to be indexed at all? Aren't their sole purpose to act as a unique and permanent identifier for a given feed item and if they also act as a permalink (e.g. dereferencable), it should of course redirect to the so-called "nice URL" of the given item? If they don't redirect today, that's a bug. If they do, then why would they ever end up in Google? Regarding what status code would be best, I'd say 301. The reason for this is that the URI you end up at should never change anyway. If it changes by the article identified by the URI moving, the old URI should 301 to the new URI as well. In a CMS that respects the web architecture, all URIs should be seen as permanent and should never go away. Getting a 404 on a URI previously available as published through the CMS is a rather serious bug. You should either get a 301 (if the resource has moved to a new place) or a 410 (if the resource is permanently deleted and never to return). Both WordPress and Drupal allow this behavior through plugins/modules. All this is in my humble opinion, of course.
You can see the negative effect of this "bug" right here on Umbraco.org by checking which pages Google has indexed: http://www.google.com/search?hl=en&rlz=&=&q=site%3Aumbraco.org Notice how the URL's are named in the result. This means that Google identifies the real URL's as duplicate content, and removes them from the index. Which has the following negative effects: - Both internal links, and links coming in from other sites, holds no value at all, as they point to the page marked as "dupe content". - Your site may loose value in Google's eyes, as about half of its content is being marked as removed from the index. The only way to fix this (retroactively even), is to permanent redirect all those wrongly indexed pages. That way Google will "fix" itself after a couple of months. The GoogleBot doesn't do anything with 302's, so a temp. redirect wont really fix anything.
301 permanent redirect. It will always be redirected to the correct page and it is meant to be viewed at another url, thus it is not a temporary redirect.
AFAIK Google won't follow a 302 (Temporary Redirect) but will follow a 301 (Permanent redirect). If you care about SEO then it seems you should offer a 301. I guess it makes sense as you're telling search engines that this resource has only 'temporaraly' moved to this location with a 302, but will be put back to it's original location later. Thus google **won't** update it's index accordingly. Of course I heard this was the case a few years ago, and Google regularly updates its indexing algorithms, so this may have changed since. My logic would be that the blog page is permanently located at /blog/2009/4/7/blog-title-here, until you change the name then its permanently located at /blog/2009/4/7/brand-new-blog-title. Same way when I move house I permanently live at 10 Church Street, until I move house then I'm permanently at 15 Daffodil Drive, ie. nothing is truely permanent, its only permanent 'for-all-intents-and-purposes'. Also what happens if someone bookmarks the URL **/blog/2009/4/7/how-to-migrate-umbraco-40-to-iis-7-and-aspnet-35** and you then change the title. There'll be potentially 100's of bookmarks and links in forums etc. that are now out of date. Have you thought of including the blog ID in the URL?
Excellent replies. I guess in the end this is all relates to Umbraco should be able to automatically address url name changes. While it's possible today to do that via Events and INotFoundHandlers, a build in solution would be best. So, ultimately we should: 1) Do a 301 for the id urls 2) Track internal url changes in a log and do 301s on those as well Right?
right, do a 301 redirect - there is no other way... (if you want good rankings in Google)
This is just an idea - but what about making the guid not a link (eg: 26156:umbraco.org). Then google can't follow and index it, and would be forced to use the link element as the link which can use the nice url. That said, I agree that if creating a redirect, then you probably want to use a 301. I would rather not do 301 redirects on internal name changes - certainly not by default. I frequently move nodes around and rename them to create new ones in most of the sites I build and maintain.
A 301 will make Google treat the two URLs as one page; a 302 will make it treat them as two pages, essentially no different to just serving the same content at both URLs. However, this could be an ideal job for the new canonical URL link (http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html). Adding to the GUID page(or indeed to every page - I don't think there's a problem with a page declaring itself as the canonical version). This should remove any duplicate content worries without introducing any redirect-related side effects.
Oops, let's escape the HTML... <link rel="canonical" href="/the/nice/url/" />
Hmm, why not use the url of the item as guid instead of the id? The permalink="true" as used on the umbraco blog rss indicates that this is the acctual url of the item. The GUID is optional and is mostly used by rss readers to indicate where the acctual item can be found, ie the full url of the item. Of course you have to add the full URL as http://www.mysite.com/ + url also to make it valid. Otherwise 301 is the shit to use.
The RSS Community Package is not the only thing affected. In a v3 site we are working on any page that uses cookies is not indexed properly by Google therefore affecting its ranking. Neils just FYI this looks to be the same problem we notified you about a few weeks back. We also have a forum post about this (search on 'google 302') so any replies would be REALLY helpful ;o)
Hi Niels, No offense but I already had a thread about this problem last year.....The issue (in my case) was that Google used the permaLinks within the RSS-feed which looked like domain.com/1125.aspx. For this reason I dropped the general RSS package and created one myself which used the niceUrl also on the permaLinks. If you like I can search for the XSLT with the right output.... Good luck!! Chris
Excellent, do a 301 redirect - there is no other way... (if you want good rankings in Google)
You comment is being submitted... please wait...
Your comment has been posted on umbraco in reply to: Calling SEO experts - 301 or 302 for RSS package
Something horrible happened. and your comment could not be posted. Please ensure that all fields have correct values, and that yourEmail address is valid.