Simple Guide to HTTP Response Status Codes
Table of Contents
Status codes are sent when a web page is requested. Along with the content you see in your browser, a web server also sends back some other information.
This info is called a Response header. This can contain quite a number of different bits of data. Some of it is informational, and some is about how the page should be treated. One of these is the status code.
What's a Status Code?
A status code is a numerical 3 digit codes. These broken roughly into 5 groups, in 100 ranges, so 100 - 199, 200 - 299 and so on. Each group currently contains far less than the maximum 100 it could. It means there's plenty of room to add more down the road if it was needed though.
They are designed to tell whatever is accessing the requested URL if the request was successful. It can also tell if there's something else that needs to be done rather than just display the content in the browser.
Why Should I Care?
It's back to that function of telling the client (the browser, bot or script) how this page should be treated. It's particularly important for search engines as there bots (or crawlers as they are commonly termed). Bots tend to pay a lot more attention to these codes (or at least some of these).
Sometimes, it's perfectly possible for a visitor, or you, see the content in a browser. The status code that came with it could be telling a crawler something entirely different though. So it's worth getting a handle on these and understanding what codes to use, and when.
This isn't meant to be a complete guide to all the known status codes. I'll just cover the common ones relevant to most sites here. I'll skip the 1xx codes, which are Informational responses. For the most part aren't something you'll encounter day to day. So I'll skip straight to the 2xx ones.
2xx - Success
Status codes in the 200 range are success codes, put simply it means everything is ok with this page. There's really only one status code we're interested in here, 200.
200 - OK
This code basically means everything was fine, we got what you asked for and have sent it to you.
It's like going into a shop, asking where the milk is, and it being exactly where the staff pointed too.
When to use a 200?
A 200 can be thought of as the standard response. If the content is there, on the URL requested, and it's available to everyone, it should be a 200.
When not to use a 200?
3xx - Redirects
Status codes in the 300 range are redirects. Basically it means that the content isn't on the URL requested, but we know where it is. They normally then trigger the browser, and also crawlers, to follow the directions to where the content can now be found. There is one notable exception to that rule.
301 Moved Permanently
This status means that content that used to be on the URL requested now has a new permanent home on a different URL.
A 301 status is like going to your store for your milk. The staff tell you it is no longer on aisle 3 and instead point you to its new location on aisle 4.
Both browsers like Chrome, Firefox, Edge, and most search engine bots will follow this redirect. They will go to the new URL specified along with the 301 status code. 301 means permanent, so a browser will cache this redirect. The next time you go to the old URL, it will automatically go to the new one, unless the cache had been cleared.
A search engine will drop the old URL from its index and update it with the new one. It will also pass along ranking signals like incoming links, helping to preserve any rankings the older URL had built up over time.
When to use a 301?
When content has moved to a new place and it is staying there. It's worth mentioning that it's not just for when you are moving 1 piece of content. It is also used if you are moving domains.
You can let customers know your shop has moved to a new building up the street by putting up a sign. In the same way you can 301 redirect your old domain to your new one. For example, you could redirect oldexample.com > newexample.com.
In these cases, you should make sure all content redirects, so oldexample.com/milk.html would go to newexample.com/milk.html. Likewise oldexample.com/fruit.html would go to newexample.com/fruit.html.
Unlike a physical location, there can be slight variations in a URL too, so a URL could have a HTTP & a HTTPS version. It could also be on www and non-www version.
http://example.com/milk.html and https://www.example.com/milk.html are different URLs, even if they serve exactly the same content. Picking one version and 301 redirecting the other variations to it is good practice.
When not to use a 301?
The idea is to redirect to the contents new home. So make sure you are redirecting only to relevant pages. Don't be tempted to mass redirect everything to a homepage if you've deleted stuff.
If you went into a shop for milk, and was sent back to the front of the store to look again you'd be miffed. Especially if there isn't any milk in the shop.
Don't 301 redirect a URL if you want it to stay indexed. It will drop from the search engines, and it can take some time to get re-indexed if you reverse that decision.
Anything else to look out for with 301s?
Try and keep chains of redirects to a minimum. It's sometimes easy as time goes on to have a chain of redirects build up. But send them from aisle 2 to aisle 4, not aisle 3 to 6 to 2 to 4.
A 302 is similar to a 301 in that it points both browsers and crawlers to a new location for the requested content. But the difference is that this is potentially a temporary situation. Unlike a 301, you are not telling people this is one piece of content that has now moved.
Instead of saying please replace this URL with this other one, a 302 says this is a valid URL. It's just currently pointing to something else.
It's like the milk has been moved out of the fridge right now, but it (or something else) will be back in the future.
Unlike a 301, browsers don't cache 302 redirects. So each time you come back the browser will check to see where it redirects too.
Googlebot treats them the same way, unless it sees the URL redirecting to the same, new location for a while. At that point it decides that you must have meant to use a 301 redirect and treat it as one.
When to use a 302?
When the URL should remain indexed (although Google might take that decision away from you). A common use is if you absolutely must redirect a user to a site based on location. For example redirecting visitors from the UK away from the Spanish site.
When not to use a 302?
When the move is a permanent one.
304 Not Modified
A 304 status is the odd one out in the redirect group. It doesn't cause a browser or bot to go to a different URL. Instead it instructs the client to redirect the request to its own cache of the resource. It is, in essence a caching control tool.
It works by the site sending out headers that contain a timestamp, know as Last-Modified and / or a serial code known as an ETag. Both of these are changed as appropriate when a page, or resource, is updated.
This is stored by the browser or crawler along with the cache of the content, and sent the next time the URL is requested. The dates, or Etag serial are then compared. If they match, rather than waste time and bandwidth downloading the content again, the client knows to use what it already has.
It's like going to the record shop and asking if there is an new albums by your favorite artist. Instead of reeling off the entire list of what they have, them just telling you "No, same as last Tuesday".
It can be a very handy way of boosting performance, and it a great solution for both the visitor, and the site. It means things load faster with less overhead. It's particularly powerful on resources that don't often change. Googlebot can use 304s, but does so infrequently. It doesn't deindex or change the URL if it sees a 304.
When to use a 304?
Whenever you can! If your server and website CMS or code base can support it.
When not to use a 304?
If you can't support it technically, especially if you can't ensure Etags and / or Last-Modified headers can be updated reliably when your content changes.
4xx - Client error
The 400 range of status codes cover client errors. Basically they mean there was something 'wrong' with the request itself. The client part of it means the browser, or crawler. The thing requesting the URL.
Error is also a word that can cause a bit of alarm, because in many cases, it's not something that's wrong. In fact, the status is the right one to send. So keep in mind that although they are often termed errors, it doesn't necessarily mean something is faulty.
A 401 means that the content on this URL is not available to everyone, and the web server has no idea who you are. Basically, you need to log in, or provide some kind of authentication.
It's like having to show I.D. in a shop to be able to buy a bottle of whiskey. It might be that you are allowed to buy it, you just need to prove it first.
401's are status coded you perhaps are not that likely to see so much these days. They tend to be used with pages that use Basic access authentication. They're also more common interacting with APIs that require some kind of authentication, via an API key or the likes.
Many modern web CMS, and sites in general, don't tend to use this method any more. They instead control authentication by redirecting to login pages, and utilize noindex on these if they don't want the login pages indexed.
Google will not index pages that serve a 401 status.
When should I use a 401?
If you are doing some kind of authentication, but it's not the only way do do this.
When not to use a 401?
On any page that should be publicly available.
A 403 means that the client isn't allowed to access this content. It also means that the server isn't waiting for the client to prove it is allowed to.
The server knows enough about the client to know they are not allowed. That could be because the client has provided incorrect access details, or is using an IP address that isn't whitelisted. It can also apply if you are trying to access resources that are only available internally.
To put it simply, a 403 means your name is not on the list, and you are not coming in.
A client will still display the content sent from the server. A search engine like Google will either not index the URL, or deindex it if it's already indexed.
When to use a 403?
For stuff that shouldn't be indexed and accessible by the general public. Development and staging sites can be kept out of the search engines this way. Just remember you still need to prevent normal visitors actually seeing the content!
When not to use a 403?
Don't serve a 403 status code when you want the content to be indexed.
404 Not Found
A 404 status means that the server cannot find the content you asked for. That could be because the URL never existed, or it perhaps once did but doesn't any longer.
It's like going into the shop, going to the shelf to look for tomato soup, but the soup isn't there.
Unlike an empty shelf though, a 404 status can 'lie'. A browser will still display the content sent, so your server could sent your article or product page, and everything could look fine. To a search engine you are saying "This doesn't exist!".
Google and the other major search engines will drop URLs that send a 404 status from their index. Search engines may hold on to them a little while until they are sure it's staying as a 404.
Most search engines will also occasionally check back on the URL to see if it now exists. That could be exists again, or for the first time. Or it could now redirect to a different URL.
When to use a 404?
When a URL no longer exists, like a deleted page or image. It should also be the default response for URLs that never existed. That means if you just made up a URL on a site, http://example.com/MadeUpRubbish.html it should respond with a 404.
When not to use a 404?
When the content exists and you want it indexed.
You should also not use a 404 when the content has moved to a different URL. In those cases you should use a redirect instead.
A 410 status is very similar to a 404, it too means the content can't be found. Unlike a 404, a 410 means a URL did once exist, but it has now gone for good. It's a slightly more affirmative way of specifying that content is deleted.
It's like going into the shop and being told that they used to sell tomato soup, but they don't anymore, and won't again.
Like a 404, a search engine will drop any URL returning it, and will return to check it from time to time. It might be dropped a little quicker, and not be revisited as often. But the difference is minimal.
When to use a 410?
When you delete a piece of content and you want to enforce that it's gone for good.
It might help search engines drop the content a little quicker.
When not to use a 410?
In the same cases as a 404, and also if you think the URL might come back at some point in the future.
418 I'm a teapot
Don't brew coffee in a teapot. Simple. (this is actually a status in the specs.)
When to use 418?
Used when you are joking. Perhaps as a talking point around the water cooler at your web developer's offices.
When not to use 418?
When it's not funny anymore. Internet is serious business, don't you know?
5xx Server Error
The 500 range of status codes mean there was an error on the server. These mostly mean something has broken or there's some other issue so the content can't be served.
500 Internal Server Error
A 500 status code is says that something has gone wrong, without specifying what. It's common when scripting or a database isn't working, but can be caused by many things.
It's like you can't go to the shop at all because of some disaster.
If you are getting 500 errors, it's time to check your log files, or reach out to your developers and / or hosting company.
Your server may still send out content, which a browser will display. A search engine receiving a 500 error wouldn't index the content if it was new to it. If it was coming back to recrawl this URL, it wouldn't drop it straight away.
When search engines, particularly Google, see a number of 500 errors, they stop crawling quite as much. They do this mostly in case they are to cause of the errors.
If a URL returns a 500 status for some time, it will then be dropped by Google.
When to use a 500?
A 500 status you probably ever want to intentionally serve. It is worth checking your server sends it out if things do go wrong though. It helps Google understand there's an issue at the moment.
When not to use a 500?
500 status codes should only accompany errors, so pretty much all the time.
503 Service Unavailable
A 503 status code is used to tell the client that the server isn't ready to serve the request. That could be that the server is intentionally down, or it could be that it is too busy.
It's like going to the shops and finding it closed for repairs.
Like putting a sign up on the shop, you can specify when the server might be open again. You can do this by sending out a Retry-After: header with the response.
If a search engine sees a 503 status code, it will not drop the URL at first. It will also back off, like it does with a 500. If you send out the Retry-after: header, search engines try to honor that.
It can also be used when your server is overloaded, basically just to busy with other requests to serve the content. Likewise, search engines will hold off crawling for a bit and come back later.
If a URL continues to serve a 503 for some time, eventually search engines will drop it.
When to use 503?
Use a 503 status code when you take your site offline for maintenance. It will help preserve your rankings until it is back online again. Likewise if you have a sudden traffic spike you are struggling to deal with, 503 can help until things are stable again.
When not to use a 503?
When your server is fine, and perfectly capable of serving the content.
How do I Check the Status Code?
You can also use the devTools in the Chrome browser.
It's also worth mentioning that sometime a site can serve different status codes to different clients.
A normal user might get a 200 status code, a search engine could get a 404.
Both Google and Bing offer webmaster tools that report on these kind of issues. Google offer Search Console and Bing offer Webmaster Tools. Add your site to both and check frequently to see if any problematic statuses are being served.