Each HTTP Status-Code is described below, including a description of which method(s) it can follow and any meta information required in the response.
There are four HTTP status codes (200|301|302|404) that we are primarily interested in from an indexing and search engine marketing perspective. It is recommended that you verify your URIs are returning the proper Status-Code in the Server Header.
URI - Uniform Resource Identifier
The generic set of all names/addresses that are short strings that refer to resources. RFC 2396
URL - Uniform Resource Locator
An informal term (no longer used in technical specifications) associated with popular URI schemes: http, ftp, mailto, etc.
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
GET an entity corresponding to the requested resource is sent in the response;
HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end server.
Admin Note: The 200 Status-Code means that all is okay. This is what should be returned if the requested resource is valid.
Example of HTTP Status Code 200
Server Response: /w3c/status-codes
Status: HTTP/1.1 200 OK
Date: Mon, 30 Jun 2003 05:31:00 GMT
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.
Example of HTTP Status Code 301
Server Response: http://seoconsultants.com/
Status: HTTP/1.1 301 Moved Permanently
Admin Note: Your web server should be configured to return a 301 Moved Permanently Status-Code for all requests to http://domain.com which should then be permanently redirected to http://www.domain.com/. This solves a possible issue with Google PageRank fluctuation between the non-www and the www versions of the URI. You should encourage your link partners to utilize the full URI of your domain.
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.
Admin Note: From my perspective, a 302 should not be used when parking domains or capturing type-in traffic. The server is returning a 302 Found (temporarily moved) which is not correct.
If you 301 Moved Permanently a resource, then the spider is instructed to ignore the current location and redirect to the new location. In Google's instance, you would be effectively transferring PageRank to the new resource.
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
Example of HTTP Status Code 404
Server Response: /custom-404
Status: HTTP/1.1 404 Object Not Found
Date: Mon, 30 Jun 2003 05:31:00 GMT
Admin Note: I've found many custom 404 pages returning 200 status codes which is not correct. The server header should return a 404 Status-Code when a page is not found. You can configure the 404 from the server level to return a custom 404 page. You should verify that your server is returning the proper 404 Status-Code in the server header response for the custom 404 page.
For more information on HTTP Status Codes, visit these reputable resources...