How Google Handles 301 and 302 Pages Options

[cre8pc]

Ammon has been referring to changes in how Google handles 301 and 302 status messages. I haven't been following this, so I'm hoping to generate discussion for the benefit of those interested.

For reference:

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

The new permanent URI 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 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. 

      Note: When automatically redirecting a POST request after
      receiving a 301 status code, some existing HTTP/1.0 user agents
      will erroneously change it into a GET request.

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

The temporary URI 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. 

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client.

Source

Has anyone, in addition to Ammon, noticed changes or new trends by Google for these pages?

[rustybrick]

Your not the only one, a thread at search engine watch named Accidental PageJacking increases with new 8 billion index discusses some of this recent activity. I think.

[cre8pc]

More about this from Ammon.

The biggest change is in how Google is handling 302 redirects. It used to list nothing but the url, and have nothing cached for a URL where there was a 302 redirect. Now it is caching the page that the redirect points to, from the url where the 302 redirect is. But it now seems to have messed up on 301 redirects. Its like they got it backwards.

For an example of this check the cache of the URL for Overture.com
http://www.google.co.uk/search?q=cache:www...w.overture.com/

http://www.google.co.uk/search?q=overture
Note that google is now showing a snippet, not just a description for the Overture root domain. It also has a 'cached' link.

From http://www.cre8asiteforums.com/viewtopic.p...p=100803#100803

[ILoveJackDaniels]

Looks to me like all they are doing is showing the snippet of the page that the redirect points to. Searching for text on the page the 302 points to does not return the URL that returns the 302. Google seems to be using the most popular of the two available URLs for the resource. The URL that returns the 302 also shows up in a search for items within the site that contains the new page.

By the way, does anyone have any information indicating what, if any, changes there are to the way they handle 301 redirects?

[Black_Knight]

The ******s have dropped hundreds of URLs that had switched to using 301s (Google's previously advised, and the correct for the situation) from thier previous 302 redirects. The pages just vanished suddenly, without being replaced with the correct url, and weeks later, were still gone, not replaced.

Oh, and Google are still advising webmasters to use 301 redirects:
http://www.google.com/webmasters/3.html

[esoos]

I was just wondering if anyone had noticed any improvement in the way Google is handling 301s.

I haven't done any tests on this yet (sorry!) but I've spoken to a friend who said that she had seen this happen. The first site had already been indexed when she decided to redirect it to another site. That new site got partially indexed by Google, but then that update/index expansion occurred and the new site was completely dropped (I believe that's how she explained it).

So far, the new site has not been indexed, but the old one has been dropped.

Does anyone have any info on Google's current status regarding 301s?

Thanks

[DianeV]

> 301's

Ammon, if I could ask, does this also apply to 301s within a site, or only from one site to another?

I believe I've seen this behavior with the Inktomi bot; they *never* seem to drop those old URLs.

[esoos]

I have a site that recently came online that uses two different kinds of redirects within the site.

The first is a redirect from the non-www domain name to the www domain name (this may not technically count as being within the site):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^www.sitename.com [NC]
RewriteRule ^(.*)$ http://www.sitename.com/$1 [L,R=301]
</IfModule>

The second is used to redirect some obsolete php pages that had been indexed in Yahoo but not Google:

redirect 301 /articles.php http://www.sitename.com/

Both these redirects are working great - only the www version of the site is being indexed by Google, and none of the obsolete php pages have been indexed at all. All the pages from the site (about 40) were indexed on Dec 18.

These examples might not mean much since these redirects were put in place before any pages were ever indexed by Google, but hopefully it supports the case that Google is doing well handling 301s within a site.

I'm still doing some tests on a site to site redirect and I'll let you know what happens.

I'd certainly appreciate anyone else's feedback on tests you've run or experiences you've had regarding Google and the 301 redirect.