Friday, August 24, 2007

302 & 301 Redirect Fun

Many of us who have engaged SEO consultants have often gotten the feedback or report that our site is not search engine friendly because we are using "302 redirects instead of 301 redirects". Any clarification by the consultants is however not very clear. Our IT administrators proceed to change the 302s to 301s, but either can not explain or don't understand how this is supposed to affect our search engine friendliness. Or if there are any other reasons why 302s are bad.

Before I get into this, let me give you some background. Firstly, my old website (I can whine about it now in public since it has been replaced last week!) was running on Lotus Domino. This fine product from IBM served as the webserver, content management system and database (non-relational of course). Secondly, our web analytics tool is Omniture, which is a great javascript based data collection system; their business model is ASP-based (Application service provider) so there are no hardware/software overheads.

Next let's get the w3.org official definition of the 302 and 301 redirects:

====

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URL and any future references to this resource SHOULD use one of the returned URLs. Clients with link editing capabilities ought to automatically re-link references to the Request-URL to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

The new permanent URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URL(s).

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

10.3.3 302 Found

The requested resource resides temporarily under a different URL. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URL for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

====

(302 has also been more clearly defined as "Moved temporarily")

Now we kinda understand the difference, why is 302 bad?

As it turns out, when the search engines hits a 302, they must index both sites. But it is being told that the content is temporary. So..

1) Should a search engine give a high rank to temporary information vs permanent information?
2) In the case of Google, how does it assign PageRank? To the first link which was redirecting to the second link and has no content? Or to the second link which is temporary?
3) Actually, since a 302 redirect does not pass "referrer" information to the second link, it can not credit the second link with pagerank of the first link.

Yes this get a little confusing for us as well as the search engines. So they don't like it.

In the case of my old website, Lotus Domino only does 302 redirects. This is a nightmare from the above perspective. It was also bad for our Omniture web analytics. Omniture operates as an application service provider (ASP); they host all the servers and reports and we implement some Javascript tracking codes on our pages. Not unlike Google Analytics. But because referrer information is not passed in a 302 redirect, our reports had a lot of "Typed/Bookmarked" traffic instead of actual Referrers.

As for 301, it just tells the search engines that this change is permanent, ignore the first link, and only look at the second link. Any PageRanks or scores should be directly attributed to the second link. Easy enough... As for Omniture, it passes through Referrer information so it's fine there as well.

Then again... ideally, we shouldn't use redirects at all.....

Digg This PostDigg This Post

blog comments powered by Disqus