What are they and why are they important?
When you request a URL or an element within a page, your browser you send a request. The magic of the tinter-web happens and the server you end up on sends back the content, with a response code, that communicates with your computer and confirms success/failure or an alternative action suggestion.
To really know what your servers are doing I really would suggest that you monitor your server response codes. This is especially important during any migrations/ launches or major changes. You can get this data easily inside Google Webmaster Tools or any internal tools you may have e.g. Tealeaf. If you are doing testing you can even get browser plugins e.g. http headers, or, fidler for Firefox.
Monitoring server response codes gives you insight into your site health, indexation, what is really happening, advanced usability monitoring, especially if you look by useragent or at a session level.
Server response codes are NOT “error codes”
It all depends on what you wanted your site to do. I jokingly say that reading repsonse codes are a bit like ‘tarot cards’ as you need to add context to when the code was given. You will see some common definations below. So, if you mean to give a 404 to delete a page from Google, then it is a positive thing. However, if you have accidentally deleted or moved a page, then its bad.
So, What are the most commons response codes I should know about?
Defintitions are from the mid Nineties and havent really changed. They are all numerical and they are grouped as…
Successes are in the 200’s
These codes indicate success. As in, you requested and you received.
200 = OK
The request was fulfilled as requested. This is the ideal answer to most requests made. And if you see redirects e.g. a 301, at the end of the chain you should get a 200.
201 = Created and OK
This should following a POST command. POST means that you send a request and the content is then generated, then returned. As opposed to a GET command, which ‘gets’ the same page every time! In the old days, POST was to get search results and GETs were ‘static’ pages. These days, you can have a GET URL, but actually POST to get the content. More to come in real HTML5 as we object.
Redirections are in the 300’s
These codes handle redirections of permanent or temporary in nature.
301 = Move permanently
The data requested has been assigned a new URL, and the change is permanent. This is the most common type of redirect for any kind of content movements, site migrations or major platform upgrades (effectively an internal migration). A user may notice a different URL in their browser. But for a SEBot, this means replace the URL you requested with this new one.
302 = Temporarily moved. A temp re-direct
The data requested actually resides under a different URL temporarily. A user will not likely notice, and the instruction to a SEBot is to look at the new location, but to keep the original URL in its db.
Bad requests are in the 400s
The request had bad syntax or was inherently impossible to be fulfilled.
403 Forbidden request
The request is for something forbidden. You may see this if you are looking around a server and the sys admin has put permissions/access rules. Or an internal request has not be given the right level to authentication.
404 = Page not found
A commonly used terms across the business, but do they know what it means? In short, the server has not found anything matching the URL requested. This could be a problem if you are not expecting this response code, or could be great if you have deleted a page and you want the search engines to remove this page from its index.
You should ensure that the content of that page works for the user! Ideally a sign-post-page. But a common mistake when creating a “404 page”, especially if you are use your app layer to resolve the request that it treats it like a disambiguation request and 302s to a 200 with a 404-style-message. You should check your 404’s 404 response status today.
Server problems are in the 500’s
500 = Internal Server Error
This means that the server encountered an unexpected condition which prevented it from fulfilling the request. Normally this would be an outage. If you see these in your analysis, you probably can’t do much about these, other than to keep your sys admins/hosting company in check.
503 = Temporarily not available
In the real world, if you take your website down for maintenance or updates etc. (if you need to take it down – why not load balance?), you should return a 503. This is effectively a soft 500. This tell the SEBots to come back later. This is important, as if you give a SEBot too many outages, you will lose your rankings!
There are more response codes, but in reality, every day, these are the only ones you will normally come across.
Link to a fun post about response codes shown in pictures of cats.