TheMadScientist - 3:54 am on Nov 12, 2012 (gmt 0)

absolutely HATES getting redirected to the front page in response to a 404.

The index page in this context (the context of this thread) is the index page of the section where the specific item the visitor is looking for can be found. Read the entire thread for the full context.

And, Google is not more or less happy over a 410 than a 404, they just treat them with a slight difference. Neither one nor the other will make any difference in rankings, but a 410 will remove a URL from the SERPs nearly immediately where a 404 will take a bit longer and a 410 will be recrawled less frequently sooner than a 404.

so i guess we all agree: - if you do it wrong and google "can find a way to sort it out, they do", or not. - if you are willing to take "a chance you are making things difficult for Google to rank a site appropriately" then you can ignore protocol.

Not really...

You're preaching 'exact protocol' WRT a search engine that does not follow exact protocol which makes following exact protocol unnecessary (and you're not even correct about what the status code that should be used according to the exact protocol definition is in this specific situation - see below), so I have to say, "No, we don't all agree..."

If Google followed strict protocol, then following strict protocol would be important, but since they don't it doesn't make a hill-of-beans difference if your protocol is 100% correct in each and every situation, and the specific protocol used (302 redirect status code) in this situation is not and has not been the issue, possibly because it's technically the correct status to use.

The redirect is undefined by the server other than as 'Found' and the redirect may or may not be removed in the future (read the posts in this thread to see where that's stated), which means the actual specific redirect code that should be used is NOT a 301:

301 Paragraph 1: The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. [w3.org...]

Since the specific redirect discussed in this thread is not known to be a permanent redirect, meaning it May be altered on occasion (read the thread to see where that's stated), we now have 302 Found, 303 See Other, and 307 Temporary.

303's Main intended use is totally different, even though I said I'd give it a shot in this situation, as far as technically correct goes, it's out.

Which leaves 302 Found & 307 Temporary.
The following are the definitions of each:

302 Paragraph 1: 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. 307 Paragraph 1: The requested resource resides temporarily under a different URI. Since the redirection MAY 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. ### 302 Paragraph 2: 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). 307 Paragraph 2: 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) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI. ### 302 Paragraph 3: 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. 307 Paragraph 3: If the 307 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. [w3.org...]

So, with the exception of HTTP/1.0 User Agents 'not getting' what a 307 redirect means, a 302 and 307 are technically described as the same *bleeping* thing, which means using just a bit of reasoning we can very easily determine:

302 is the correct status code in this situation according to Exact protocol definitions, because we know from reading this thread the redirect Might be altered (removed) on occasion ... Go figure.
My guess is the use of a 301 is actually technically incorrect, much as it would be in this situation...

[edited by: tedster at 4:35 am (utc) on Nov 13, 2012]