The Exhaustive List of HTTP Status Codes & What They Mean
We’ve all been there: You’re mindlessly scrolling the web, clicking on a variety of links from Google, social media, or other sites, when suddenly — you’re prevented from continuing a search due to an HTTP error code.
This can be a frustrating experience as a user. However, HTTP status codes go beyond simply communicating an error — these codes can also signify a successful transmission, or a re-direct to a new site URL.
Here, let’s explore an exhaustive list of HTTP status codes, so when you come across one, you’ll know what it means.
The SEO’s Guide to HTTP Status Codes
HTTP status codes are three-digit responses a server returns at the request of a client (a browser or search engine). They are divided into five classes with multiple variants that convey different types of messages.
Every SEO out there should know at least the most common HTTP status codes by heart to quickly evaluate any situation:
- 200 OK
- 301 Moved permanently
- 302 Found / Moved temporarily
- 404 Not Found
- 410 Gone
- 503 Service Unavailable
What are HTTP status codes?
HTTP status codes are three-digit responses that a server returns at the request of a client (a browser or search engine). There are five classes of status codes, and each class conveys a different type of message.
When you requested this page in your browser, you made dozens of requests to our server asking for all of the information needed to view and render the page. That all happened in a flash, without you noticing. HTTP status codes were instrumental in making it possible.
HTTP stands for Hypertext Transfer Protocol. It’s the protocol used by clients and servers to communicate and exchange data. HTTP status codes are part of the communication process.
Please note that we’ll use the terms «URL,» «page,» and «resource» interchangeably, depending on the context. At the end of the day, these are all resources.
- We had many discussions over 301 vs 302 with some of the biggest disparity between what Google officially says versus what practicality tells us. I suggest taking care of any 302s because even though they might pass PageRank in the same fashion as 301s , Google will not update your snippet in the SERPs. Keep that in mind with any type of migration.
- Soft 404s are one of the biggest enemies of large sites after my experience. They usually come down to empty pages and should be fixed, just like 404s .
- 5xx often occur on an ad-hoc basis and should be taken care of immediately because they’re followed by a decrease in crawl budget.
A note on timeouts and other connection errors
Timeout or connection errors unrelated to HTTP status code classes are not server responses. Errors like these mean that the client never reached the server.
As this is important to understand, but a confusing topic for most people, we’ll look at a few examples:
- Connection timeout errors, such as Google Chrome’s «This site can’t be reached,» are not status codes. The server wasn’t reached, so they can’t be server responses and aren’t classified as status codes.
- DNS lookup errors, such as Google Chrome’s «This webpage is not available». This error isn’t a server response either, as the client couldn’t connect with the server because of a DNS issue.
In all cases where you get a HTTP status code, this means the server was reached, and that it was able to issue a response.
Why are HTTP status codes important to SEO?
The goal of SEO is to drive organic traffic that’s likely to be interested in what you have to say.
In order to drive that traffic, you need to make sure your content is accessible to search engine crawlers. When they request your content, you want HTTP status 200 OKs to be returned. What you don’t want is for HTTP status codes 5xx and 4xx to be returned, and you want to keep HTTP status codes 3xx to a minimum as well.
Search engine crawlers and websites speak HTTP . If you’re having a hard time understanding what they’re talking about, how are you going to be an effective SEO?
Not understanding HTTP status codes is like managing a restaurant in a foreign country where you don’t speak the language. You’ll see lots of things happening, but you don’t really know what’s going on, why it happens, and how to improve it.
If you’re using a CMS like WordPress with a Redirect Manager plugin like Yoast, setting up a 301 is easy. As a digital marketer, it’s really useful to also understand how this could be done without a plugin and why status codes you haven’t intentionally set-up may exist. Why? It helps you debug issues much faster and allows you to have more in-depth discussions with developers.
In a perfect world you have zero 404 errors or 301 redirects within internal links of your website.
The most common internal 404 errors are caused by human beings — using relative paths to refer to a different root domain, typing the URL wrong, and sometimes pasting invisible characters into your WYSIWYG editor.
In a perfect world you would fix the root of these problems, and only upon not being able to fix the root of the problem, use 301 redirects as a patch. This is why 301 redirects are fascinating for SEO’s — they’re often much more nefarious under the hood as they live on as patches of tech debt.
Make sure your content is accessible to search engines. Monitor your site with ContentKing and get alerts when HTTP status codes change.
What do HTTP responses look like?
The HTTP responses sent by web servers usually consist of two parts: headers and a body payload.
The headers contain the HTTP status code and other information such as instructions on how long the client should cache the response.
The headers are not displayed to the user, but they do instruct the client on how to deal with the response and how to display the body payload (if any). You can see what HTTP headers were returned by using Web Inspector or other browser tools.
When a body payload is present in the HTTP response, it’s used to render and display the page to the user. When it comes to redirects, there is no body payload—and keep in mind that a body payload is optional for some errors.
What do HTTP status codes look like?
Let’s look at a simplified example of what your browser did when you requested to see this page:
GET /academy/http-status-codes/ HTTP/2
This breaks down into:
- GET : describes the HTTP method used to get what you want from the server.
- /academy/http-status-codes/ : describes what URL the request is about.
- HTTP/2 : describes what protocol to communicate in.
And here’s the HTTP response header our server sent back:
- HTTP/2 – describes what protocol to communicate in.
- 200 OK – the request was successful—this is what you want to see.
What are the most common HTTP status codes in SEO?
The most common HTTP status codes you’ll come across in daily SEO life are:
How do you check HTTP status codes?
You can see HTTP status codes right in your browser by using built-in tools, a browser plugin, or for instance Google Search Console’s URL inspection tool.
As these check types are all done on a page-by-page basis, they’re slow and inefficient if you want to check a large number of URLs. They’re even more tedious if you want to monitor those URLs. If that’s what you want to do, quickly skip to the next section.
Checking the HTTP status code in your browser using built-in tools
Checking the HTTP status code in your browser is pretty similar across different browsers.
Each browser comes with applicable built-in tools:
- Google Chrome/Brave: open up Chrome DevTools, and select the Network tab to see network activity. Read more (opens in a new tab) .
- Firefox: open up Inspector and select the Network tab to see network activity. Read more (opens in a new tab) .
- Safari: open up Web inspector and select the Network tab to see network activity. Read more (opens in a new tab) .
- Edge: open up Developer Tools and select the Network tab to see network activity. Read more (opens in a new tab) .
Checking the HTTP status code using a browser plugin
If you find using the built-in functionality in browsers too difficult or not user-friendly enough, you can use a browser plugin.
One example of a popular Google Chrome plugin is: Redirect Path (opens in a new tab) by Ayima.
Checking the HTTP status code in Google Search Console
Within Google Search Console, you can request the HTTP status code of a URL using the URL Inspection feature. You’ll see the HTTP status code as the value for «Page fetch.»
For instance, when we request https://www.contentkingapp.com/academy/protect-staging-environment/ and open the «Coverage» pane, we see it returns «Successful»—which is really the 200 OK status code.
When we request a nonexistent URL, we see the following:
When it comes to diagnose HTTP Status headers, one of the most common pitfalls I see, is when a server answers conditionally depending on the User-Agent .
For example, I’ve seen cases where a server replies with a 404 status, when a browser tries to access the robots.txt file, but when you use a stateless browser, or command line tool that emulates Googlebot, the server will reply something entirely different. The worst-case scenarios, is when in fact, there’s an HTTP 500 status, instead of the 404 you saw in the browser.
I usually test all the HTTP status via command line, and made a useful shortcut to run a line of code that looks like this:
If you can, also modify this in order to output the HTML to a file.
So my tip here is: verify and ensure consistency in HTTP headers, independent of Browser or User-Agent. Don’t trust one source only, especially browser plugins. Also, unless you know what you’re doing, there’s no reason for a server to answer conditionally to a request.
How do you monitor HTTP status codes?
Unfortunate server issues aside, when you’re moving content around, consolidating or removing it completely leads to lots of HTTP status code changes. Checking them on a page-by-page level doesn’t cut it.
Therefore, we highly recommend monitoring the HTTP status codes of your URLs. You can do so by using ContentKing, which alerts you if important pages start to redirect ( 3xx ) or return client errors ( 4xx ) or server errors ( 5xx ).
And of course, you can see the HTTP status code of any URL at all times, as it’s updated in real-time.
Let ContentKing alert you if important pages start to redirect, or return client or server errors.
The different types of HTTP statuses
There are five classes of HTTP response status codes:
- 1xx – An informational response:
«We’ve received your request and are processing it. Please hold!» - 2xx – A success response
«We’ve successfully received your request; here’s what you asked for!» - 3xx – A redirection response
«Further action is needed to fulfill this request.» - 4xx – A client error response
«The request cannot be fulfilled; something is probably wrong on your end.» - 5xx – A server error response
«We’re having issues processing your valid request.»
HTTP 1xx status codes
HTTP 1xx status codes are all informational. They indicate that a request was received and understood, but that it simply hasn’t been processed yet.
We’re not covering the 1xx status codes, as they are only rarely seen.
HTTP 2xx status codes
HTTP 2xx status codes indicate successful requests. Everything went according to plan.
From an SEO point of view, the most important status code to know in the 2xx range is the HTTP status code 200 .
HTTP status code 200 OK
What does the HTTP status code 200 mean?
When a server sends the HTTP status code 200 as a response, it tells the client that the request was received successfully and replies with the requested content.
Please note that this is not an error code. The HTTP status 200 OK means everything went OK!
An example of correct use of the HTTP status code 200
When a page that exists is requested and this HTTP status code is the response.
A common example of incorrect use of the HTTP status code 200
When a page that doesn’t exist is requested, and an HTTP status code 200 is served instead of either an HTTP status code 404 or HTTP status code 410. This is what we call a soft 404 error.
HTTP 3xx status codes
HTTP 3xx status codes indicate that further action is needed. The request was received, but can’t be fulfilled yet. When the client receives a 3xx status code, it needs to make a new request to the location the server returned along with the redirect. The HTTP status codes that we’ll describe in this section are all redirects.
This happens when a request is made for URL A, but URL A is redirected to URL B. So the request should actually be made to URL B.
Redirects are like bandaids, you use them if you want to quickly fix something. Putting bandaids on top of each other doesn’t work. Avoid doing the same with redirects. Don’t chain redirects; always redirect to the final destination of the redirect.
In this section we’ll cover the following HTTP status codes, because of their significance for SEO:
When reviewing redirection status codes in log analysis, via Chrome or Google Search Console’s Live Test, it is important not to conflate Google’s handling of 30X codes for HTML pages and page assets.
Google uses 30X codes for pages in order to canonicalize and consolidate link equity. 302 vs 301 ‘s on CSS or JS files have little impact since Google doesn’t need to understand the canonical version. Live or either cached assets by Google are used for rendering, not indexing.
301 status code: Moved permanently
What does the HTTP status code 301 mean?
The HTTP status code 301 , «301 redirect» for short, indicates that a resource has permanently moved to another location. The request and all future requests must be redirected to another URL instead of the requested source.
Because of its permanent nature, all signals from the requested URL that is being redirected are passed on to the destination URL. Please note that browsers will also cache 301 redirects to save an additional request in the future, which leads to a better user experience by displaying the page faster.
An example of correct use of the HTTP status code 301
When a website has migrated from HTTP to HTTPS , and each HTTP URL is redirected to its HTTPS version. 301 redirects are essential to the success of website migrations.
A common example of incorrect use of the HTTP status code 301
When a page is only temporarily inaccessible.
I tend to take Google’s advice with a grain of salt. It’s not that I think they are trying to pass on misinformation, I simply don’t believe the answers are always «complete».
Google’s search algorithm is proprietary and part of the SEO «game» is to test into components that positively/negatively impact rankings. I imagine Google sees diminishing returns pretty quickly when providing insights/confirmation to SEO theories so I don’t blame them for being vague or giving potentially incomplete answers to questions.
As to redirects specifically, I strictly use 301 redirects. I’ve seen too many migrations where non-301 redirects have been used with an immediate negative performance impact. Would a 302 or 307 redirect pass ranking/canonicalization value over time (per Google’s statement)?
Maybe.
Am I willing to wait and find out, nope!
When migrating websites, don’t forget to also implement 301 redirects for image files as Image Search is becoming increasingly more important, especially for e-commerce websites.
As Google ignores rel=»canonical» tags for images, setting up 301 redirects is the only way to pass the authority of your old images to the new ones. Keep in mind that Google is still slow when it comes to seeing image related updates so make sure you create image sitemaps for the old and new images to help the search engine see the changes faster.
It’s also important to note that Google will increase its crawl rate when discovering 301 redirects in general, so if you’re running a large e-commerce site make sure your hosting environment can handle the increased crawl rate when you’re migrating a full website!
302 status code: Found / Moved temporarily
What does the HTTP status code 302 mean?
The HTTP status code 302 , «302 redirect» for short, indicates that a resource has temporarily moved to another location.
Because of its temporary nature, no popularity and relevance signals from the redirected URL are passed on to the destination URL and the redirected URL will still rank instead of being consolidated. Please note that after a significant amount of time, 302 redirects can be treated as 301 redirects by search engines.
Simply put: when a 302 redirect has been in place for a long time, it’s treated as being permanent.
An example of correct use of the HTTP status code 302
You’re running a campaign, and for a short period of time, you want to send users landing on URL A to URL B instead. After three weeks the campaign ends, and you remove the 302 redirect.
A common example of incorrect use of the HTTP status code 302
When a website migration is done, and 302 redirects are implemented instead of 301 redirects. Signals from old URLs aren’t passed on to new URLs right away, so the new URLs will not be as successful as the old URLs. It can take a months before 302 redirects are considered to be actually 301 redirects.
303 status code: See Other
What does the HTTP status code 303 mean?
The HTTP status code 303 , «303 redirect» for short, indicates that the server is redirecting the request URL to a different URL. It can for instance be used to prevent users from accidentally re-submitting forms when using the «back» button in their browser, as the 303 redirect indicates that a follow-up request to the temporary URL should be made using the GET HTTP method.
When Google’s Gary Illyes was asked whether 303 redirects pass popularity signals, he said «Yes» (opens in a new tab) ; it’s fine to use 303 redirects when it comes to forms, but don’t use them for redirecting content that isn’t related to forms.
Because Google has noted that 303 redirects also pass link equity (similar to 301 redirects), but what they haven’t noted is that it takes quite a while for this to happen.
An example of correct use of the HTTP status code 303
You’ve got a contact form on your website, and you want to keep users from accidentally re-submitting their input when they use the «back» button in their browser.
A common example of incorrect use of the HTTP status code 303
When content is permanently moved, and a 303 redirect is used instead of a 301 redirect.
Poorly configured redirects can seriously impact your SEO efforts. Run a quick check with ContentKing and see what can be improved.
304 status codes: Not modified
What does the HTTP status code 304 mean?
The HTTP status code 304 , «304 redirect» for short, indicates that the requested resource hasn’t been modified since the last time it was requested; therefore it will not be returned to the client, and instead the cached version should be used.
Example: we’ve accessed a page on May 27th 2019 at 9:00 AM. On Thursday May 30th we’re accessing the page again, but we’re asking the server if the page has changed since the last time we accessed it. We can do so by adding this condition to the request.
If-Modified-Since: Mon, 27 May 2019 09:00:00 GMT
An example of correct use of the HTTP status code 304
Serving the HTTP status code 304 to users when content hasn’t changed is a best practice. From a search engine crawler point of view, you benefit most from the HTTP status code 304 with large websites, say 100,000 pages and up. When we’re talking at this scale, it’s really important to make sure search engine crawlers are efficiently using their crawl budget for your website.
A common example of incorrect use of the HTTP status code 304
Responding with an HTTP status code 304 when a page has actually changed.
307 status code: Temporarily Redirect / Internal Redirect
What does the HTTP status code 307 mean?
The HTTP status code 307 , «307 redirect» for short, is the HTTP 1.1 equivalent of the 302 redirect. A 302 redirect doesn’t guarantee that no changes are made to the HTTP method used, but a 307 redirect does. The 307 redirect was invented to make sure the HTTP method used to make a request doesn’t change when the server responds with a redirect. For instance, if the GET HTTP method was used, then the GET HTTP method is passed on as part of the redirect.
307 status code as Internal Redirect
The 307 redirect is also used as an internal redirect in cases where the browser knows HTTPS is enforced. The browser may know this either because it was told so when making previous requests, or because the domain is on the HSTS Preload list.
The HSTS Preload list is a list of domains that are using HTTPS . Even though a user may request the HTTP version of a URL, the browser will use the internal 307 redirect to request the HTTPS version of the URL. Doing so prevents unnecessary, unsafe requests.
This list is shared across browsers. See HSTS Preload List Submission (opens in a new tab) for more information.
An example of correct use of the HTTP status code 307
When a 307 Internal Redirect is used to make sure a connection stays secure.
A common example of incorrect use of the HTTP status code 307
When content is permanently moved, and a 307 redirect is used instead of a 301 redirect.
308 status code: Permanent Redirect
What does the HTTP status code 308 mean?
The HTTP status code 308 , «308 redirect» for short, is the HTTP 1.1 equivalent of the 301 redirect, and it does not allow changing the request method from POST to GET .
At the moment it’s not very clear how much page authority the 308 redirect passes, so we recommend using the 301 redirect instead to indicate that content has moved permanently.
HTTP 4xx status codes
HTTP 4xx status codes indicate there was an error on the client side. Possible reasons for these errors are: the requesting party’s not authorized to request a page, requesting nonexistent pages, and making too many requests.
In this section we’ll cover the following HTTP status codes, because of their significance for SEO:
401 status code: Unauthorized
What does the HTTP status code 401 mean?
The HTTP status code 401 is an error and describes that HTTP Authentication failed. The requested page requires either a username and password combination, and/or isn’t allowed access based on its IP address.
You’ll typically see the HTTP status 401 when crawlers try to access staging environments, and you’ve implemented HTTP Authentication to prevent this. An HTTP status code 401 is what you want to see; otherwise search engines could be indexing your staging environment, and third parties could be accessing privileged information.
An example of correct use of the HTTP status code 401
When HTTP Authentication is implemented and you reject bad requests with a 401 HTTP status code.
A common example of incorrect use of the HTTP status code 401
Using the HTTP status code 401 instead of the 403 to indicate that authorization failed.
403 status code: Forbidden
What does the HTTP status code 403 mean?
The HTTP status code 403 , «403 error» for short, indicates that it’s forbidden to request a URL. This status code is commonly used as a permanent measure to prevent (search engine) crawlers from making requests after misbehaving. It’s also returned in case the client provides the wrong login credentials.
Please note that the HTTP status code 401 and 403 are used in different situations.
An example of correct use of the HTTP status code 403
When rogue crawlers are requesting too many URLs on your site, and you respond with the HTTP status code 403 to stop them.
A common example of incorrect use of the HTTP status code 403
Using the HTTP status code 403 instead of the 401 to indicate that a client isn’t authorized to make requests.
404 status code: Not Found
What does the HTTP status code 404 mean?
The HTTP status code 404 , «404 error» for short, indicates that the requested resource couldn’t be found. It doesn’t explicitly say it could be found before, unlike the HTTP status code 410 , but it just says: «Hey, we don’t have what you’re looking for (anymore).»
The 404 status code is probably the most common status code for most people browsing the web, as it’s the one they see when clicking a broken link. For example, when the website owner removes a page, but there are still pages linking to it. You could say the returned 404 is not the actual problem—it’s the page linking to it.
404 errors can also incorrectly occur for still existing content, due to bugs introduced by developers or maintenance being done on the web server. Having URLs return 404 errors is bad if you didn’t remove the content.
While search engines won’t drop URLs returning 404 errors from their index after hitting a 404 once, they may do so after a few tries, so you need to monitor for 404 errors. If a URL consistently returns errors, why would they keep it in their index?
Search engines aside, 404 errors are bad from a user-experience point of view as well, as they create a dead end for users. Keep tabs on them!
An example of correct use of the HTTP status code 404
When you serve the HTTP status code 404 for all URLs that are requested that do not exist and have never existed.
A common example of incorrect use of the HTTP status code 404
Using the HTTP status code 404 on pages that exist and are actually working fine.
A word of caution… while 404 and soft 404 errors are common to see in Search Console, and often not cause for concern, DO NOT adopt a policy of redirecting 404 errors for URLs that have never existed!
This has become a common negative SEO tactic where bad actors abuse URLs that could be valid (such as search results). They build spammy links to these pages, and expect that when you see the 404s in Search Console, you will redirect them. Once you do that, those spammy links become accrued to whatever page you redirected to!
Many JavaScript-based platforms make it nearly impossible (or impossible) to properly deliver a 404 status code when a page doesn’t exist. Essentially, the REST API request is successful, but returns no content. Because of the «success» you receive a 200 status code…but there is no page! A common work-around for this is to redirect to a URL that always returns a 404 status status code.
While this isn’t the cleanest solution, it ensures search engines are not misled or become distrusting when there are an infinite number of URLs that return a 200 status code.
410 status code: Gone
What does the HTTP status code 410 mean?
The HTTP status code 410 , «410 error» for short, indicates that the requested URL was permanently removed. This means the URL existed before, but it was explicitly removed and will not come back.
Search engines are quick to remove URLs from their index when the 410 error is returned. This makes it a powerful tool in any SEO’s toolbox, so harness its power—with care.
An example of correct use of the HTTP status code 410
When you serve the HTTP status code 410 for all URLs that were explicitly removed and will not come back.
A common example of incorrect use of the HTTP status code 410
Using the HTTP status code 410 for URLs that are temporarily unavailable.
The 4xx status code grouping is used to indicate when a page is not available on the server. Most often, you will see this as a 404 header with a note indicating «Page Not Found».
The 410 status code is used to indicate that the content has been intentionally removed. While we occasionally see a company using this when they have removed inventory (such as a product or a real estate listing), this is typically not the recommended approach vs. redirecting to a relevant substitute.
Most often we utilize the 410 status code when we have removed URLs that will do not feel will ever return for the domain. As an example, when a site has been hacked and suddenly there are spam urls generated or if we determine it is more advantageous to «cut bait» on a URL vs. continued attempts at link clean-up efforts.
418 status code: I’m a teapot
What does the HTTP status code 418 mean?
The HTTP status code 418 is a bit of a joke really, as it originates from a joke. On April 1st 1998, The Hyper Text Coffee Pot Control Protocol (HTCPCP) was defined in RFC 2324 as a communication protocol for controlling, monitoring, and diagnosing coffee pots.
It’s not an actual status code that does anything, but it’s occasionally used as an Easter Egg by Google, for example.
429 status code: Too many requests
What does the HTTP status code 429 mean?
The HTTP status code 429 , «429 error» for short, indicates that a client has been making too many requests to a server within a certain timeframe.
The 429 error can be seen as a temporary version of the HTTP status code 403, provided we’re talking about clients making too many requests. If the requests keep on coming in despite the 429 error being served, the server may decide to start responding with an HTTP status code 403 instead.
If the server keeps returning 429 HTTP status codes to Google for a longer period of time, Google may remove the content that they’re receiving 429 HTTP status codes for. All the more reason to make sure your hosting platform is solid, and to always return the right status codes for the right job.
Here’s what Google’s Gary Illes said about it on Twitter:
An example of correct use of the HTTP status code 429
When a client requests too many URLs within a certain timeframe, and with an HTTP status code 429 , the server sends a clear signal that the client should slow down.
A common example of incorrect use of the HTTP status code 429
Using the HTTP status code 429 , instead of the HTTP status code 403 , to fight off rogue crawlers.
430 status code: Request Header Fields Too Large (Shopify)
What does the HTTP status code 430 mean?
The HTTP status code 430 is an unassigned (unofficial) status code. This HTTP status code shouldn’t be used.
However, Shopify has mixed up their use of status codes, and incorrectly sends a 430 status code when they should actually be sending a 429 .
So when you’re monitoring a Shopify website, and you’re receiving 430 errors, that means you’re requesting too many URLs within a certain time frame. In this case, it’s best to decrease your monitoring speed.
An example of correct use of the HTTP status code 430
There is no correct use of this status code.
A common example of incorrect use of the HTTP status code 430
Shopify using the HTTP status code 430 instead of 429 .
451 status code: Unavailable for Legal Reasons
What does the HTTP status code 451 mean?
The HTTP status code 451 , «451 error» for short, indicates that the requested URL isn’t available due to legal reasons. It could for instance be served when you’ve been ordered (or just received a demand) to take down a certain page. The status code number 451 is a reference to the Fahrenheit 451 book (opens in a new tab) .
ISPs can also intervene and respond with an HTTP status code 451 , which happens in a lot of countries when illegal torrent sites are requested.
When this response is received by the client, an explanation should be provided as well, detailing why the resource isn’t available, what legislation or regulation applies, and what it really applies to.
An example of correct use of the HTTP status code 451
When someone has blatantly copied content from another website and was subsequently ordered to remove it and thus returns 451 errors to clients that request the URL, while explaining what happened.
A common example of incorrect use of the HTTP status code 451
Serving 451 errors when people from the European Economic Area (EEA) are requesting resources from websites outside of the EEA, due to fears of GDPR repercussions.
HTTP 5xx status codes
5xx HTTP status codes, «5xx errors» for short, are served when clients make valid requests, but servers can’t complete them for whatever reason. The website could for instance be too busy or temporarily down for maintenance.
If search engines often receive 5xx errors (or 429 errors for that matter) when crawling a website, they may do a number of things—none of which are great from an SEO point of view:
- They may think the server can’t handle this many requests, so they’ll slow down crawling. This essentially means they’re assigning less crawl budget.
- They can also demote pages, or completely remove them from the index, as they think the issues are persistent. Search engines aim to provide users with a good user experience, and—similar to 4xx errors— 5xx errors are the opposite of that.
In this section we’ll be covering the following status codes:
500 status code: Internal Server Error
What does the HTTP status code 500 mean?
The HTTP status code 500 , «500 error» for short, indicates that the server had issues processing the request, but isn’t able to explicitly state what went wrong.
An example of correct use of the HTTP status code 500
When an unexpected error cropped up while processing the request, and no other 5xx error applies.
A common example of incorrect use of the HTTP status code 500
Serving a 500 error when the server is actually aware of the issue and should have responded with a more specific hint as to what’s wrong.
503 status code: Service Unavailable
What does the HTTP status code 503 mean?
The HTTP status code 503 , «503 error» for short, indicates that the server is temporarily unavailable, and will be available again later. This can be due to scheduled maintenance (although we strongly recommend against doing this) or when the server is too busy.
The 503 error allows the inclusion of a » Retry-After » value in its response, basically saying: «Try again at a later time, I’ll be able to process your request then».
Similar to the HTTP status code 429, Google may remove content for which they’re receiving 503 HTTP status codes for a longer period of time.
Don’t let mistakes cost you traffic and revenue. Monitor your site with ContentKing and be alerted in case of trouble.
An example of correct use of the HTTP status code 503
When the server is too busy, and can’t process the client’s request at this moment in time.
A common example of incorrect use of the HTTP status code 503
Serving a 503 error with a » Retry-After » value in the past, or far into the future.
If your site goes down for any reason and pages become unavailable for an extended period of time, search engines will eventually remove the page from their index. To prevent this, use the 503 status code with the Retry-After header with a specified time, telling crawlers to try accessing the page again after an X amount of time. You can also specify a date in cases when you have scheduled downtime and know precisely when the site will be available again.
Code sample
Retry-After: Wed, 11 Nov 2019 23:59:59 GMT
This tells crawlers to try reaccessing the site after the specified date and time.
Retry-After: 7200
This tells crawlers to try reaccessing the site in two hours (time is in seconds 60 x 120 = 7,200 seconds, or 2 hours).
Keep in mind that you need to make sure your website is accessible again as soon as possible to prevent your pages from getting deindexed. Not even an 503 status code with the Retry-After header can keep search engines from deindexing pages if they’re unavailable for an extended period of time.
524 status code: A timeout occurred (Cloudflare)
What does the HTTP status code 524 mean?
The HTTP status code 524 doesn’t officially exist. It was made up by Cloudflare and is sent when the request’s origin times out. The issue isn’t on Cloudflare’s end; instead, the server that Cloudflare is relying on is the issue.
It is understandable for Cloudflare to have invented their own HTTP status code here, because when HTTP status codes were designed, companies like Cloudflare didn’t exist yet.
Closing words
HTTP status codes play a fundamental role in quickly getting a message across between clients and servers. It’s important for every SEO to know the most common ones by heart, as it makes them much more effective in their work: it lets them diagnose issues significantly faster.
Here’s the list of the most common HTTP status codes of all:
- 200 OK
- 301 Moved permanently
- 302 Found / Moved temporarily
- 404 Not Found
- 410 Gone
- 503 Service Unavailable
Learn them well!
Good luck, and please let us know (opens in a new tab) if you feel we missed a status code that’s important to SEO!
Frequently Asked Questions
Steven is ContentKing’s VP of Community. This means he’s involved in everything community and content marketing related. Right where he wants to be. He gets a huge kick out of letting websites rank and loves to talk SEO, content marketing and growth.
Jessica is a content marketer for ContentKing. Her days are spent writing marketing content, cycling around canals in Amsterdam and attempting to master the Dutch language.
Also worth checking out:
Google Search Console Index Coverage report
Google Search Console URL Inspection Tool
Redirects
Crawl budget
Crawler traps
Log File Analysis for SEO
Monitor HTTP Status Codes
Do your pages sometimes return 4xx or 5xx errors unexpectedly?
ContentKing immediately alerts you about HTTP status code changes!
Your trial ends soon
Sign up now to stay on top of your SEO performance.
Your trial has ended
Sign up now to stay on top of your SEO performance.
Start your free trial
Get up and running in 20 seconds
- No credit card required
- No installation needed
- No strings attached
- Join over 35,000 smart people
- Loaded with carefully curated content on SEO and digital marketing
- Insightful articles, data-driven research, podcasts and videos
We use cookies to improve user experience and analyze website traffic. By clicking “Accept all“, you agree to our website’s cookie use as described in our Cookie Policy. You can change your cookie settings by clicking “Preferences”.
Last updated January 24, 2022
When you use our website www.contentkingapp.com (“Website”), we may place cookies. This Cookie Policy explains what cookies are and in which way cookies are stored on, and information is read from, your computer, mobile device and/or tablet (“Devices”). Please read this Cookie Policy carefully in order to understand what type of cookies ContentKing uses, the information we collect using cookies and how that information is used.
What are cookies?
Cookies are small text files which are stored on the browser or hard drive of your Device when you visit a webpage or use an application. Cookies may be needed to show the webpage or application on your Device and are also used to enhance the user experience. Cookies cannot damage your Devices or the files saved on it. There are different types of cookies. Some cookies come directly from our website (first party cookies) and others come from third parties which place cookies on our site (third party cookies).
Cookies can be stored for varying lengths of time on your browser or device. Session cookies are deleted from your computer or device when you close your web-browser. Persistent cookies will remain stored on your computer or Device until deleted or until they reach their expiry date.
How do we use cookies?
Essential (Technical) cookies
We try to provide an advanced and user-friendly website that adapts automatically to needs and wishes of our visitors and users. To achieve this, we use technical cookies to i.e. show you our Website, to make it function correctly, to create your ContentKing account, to sign you in and to manage your requests. These technical cookies are necessary for our website to function properly.
Functional cookies
We also use functional cookies to remember your preferences and settings (as username, password, language etc.) and to help you to use the Website efficiently and effectively. These functional cookies are not strictly necessary for the functioning of our Website, but they add functionality for you and enhance your experience.
Analytical cookies
We use analytical cookies in order to collect statistics about the use and visits of the Website. These analytic cookies generate statistical and other information about website use by means of cookies, which are stored on users’ Devices. The information generated relating to our Website is used to create reports about the use of the Website. Analytical cookies may be placed without your consent, unless such cookies have an impact on your privacy. In such cases, prior consent will be asked for.
Google Analytics
We use Google Analytics cookies in order to collect statistics about the use and visits of the Website. With these analytical cookies a permanent cookie is saved on your device to register your use of the Website. Google Analytics analyses this data and provides us with the results. This way, we obtain insight into the traffic of the Website and the way in which the Website is used. Based on this information we are able to make specific adjustments to the Website.
The information that we obtain is transferred to Google and stored by Google on servers outside the European Economic Area. We have entered into a data processing agreement with Google in which agreements have been made regarding the processing of personal data.
If you would like more information about analytical cookies and their expiry date, please visit the Google Analytics information page. Google also offers an opt-out option for data collection within the scope of Google Analytics.
Marketing cookies
We use third party marketing cookies in order to follow your internet browsing behavior and collect data and information on your browsing behavior from various websites you visited. This information is used to make the content of the displayed advertisements as relevant as possible, and to limit repetition of the same advertisements.
Social plug-ins
By using the Website you can get access to social media websites, such as Facebook, Twitter and LinkedIn. These buttons come with a code which has been made by these networks themselves. Using these so called social plug-ins you can login to your social media profile and subsequently share information from the Website with others. With these social plug-ins third party marketing cookies are saved on your Devices. These cookies serve the purpose of optimizing your user experience.
Companies such as LinkedIn, Twitter and Facebook may share your personal data outside the European Economic Area. Please read our Privacy Policy here and the respective social network’s privacy statement to see how these companies treat your (personal) data.
Pixels
We also place pixels of third parties. A pixel keeps track of your surfing behavior and how you use the Website. These data are aggregated and give us information about the target group that visits our website. Based on this information, we can show an advertisement to a specific or similar target group on the website of the third party that produced the pixel.
Disable or delete cookies
When you first visit the Website, we ask you to give consent for cookies that are not necessary or functional and that have an impact on your privacy. If you do not give consent, these cookies will not be placed. In that case, you may not be able to use all the functionalities on our Website.
You can configure your browser so that you do not receive any cookies the next time you use the website. You can read here how you can remove different types of cookies in different browsers. Please consult the help-function of your browser if your browser is not listed below.
Note: Refusing or deleting cookies only affects the Device and the browser on which you perform this action. If you use different Devices and/or browsers you will need to repeat the above described actions on these Devices and/or browsers.
Privacy
It is possible that information collected through a cookie or obtained otherwise, contains personal data. If this is the case, our Privacy Policy is applicable on the processing of these data. The Privacy Policy can be read here.
Can this Cookie Policy be changed?
We may amend this Cookie Policy in the future. If there are substantive or material changes that may affect one or more of the parties involved to a considerable extent, we inform those involved in advance. Our changed Cookie Policy will also be available on this web page, so it is recommended to regularly have a look at this page.
Overview cookies
Essential (Technical) cookies
Essential (Technical) cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function (properly) without these cookies.
| Name: | viewedOuibounceModal |
| Provider: | ContentKing |
| Purpose: | Store state of having closed the exit intent modal. |
| Expiry: | 1 month |
| Type: | http_cookie |
| Name: | nette-samesite |
| Provider: | ContentKing |
| Purpose: | Communication with account service. |
| Expiry: | Session |
| Type: | http_cookie |
| Name: | session_timestamp |
| Provider: | ContentKing |
| Purpose: | Utility for tracking of session start time. |
| Expiry: | Session |
| Type: | SessionStorage |
| Name: | what-intent |
| Provider: | ContentKing |
| Purpose: | Utility for tracking the current input method. |
| Expiry: | Session |
| Type: | SessionStorage |
| Name: | what-input |
| Provider: | ContentKing |
| Purpose: | Utility for tracking the current input method. |
| Expiry: | Session |
| Type: | SessionStorage |
| Name: | contentking |
| Provider: | ContentKing |
| Purpose: | Store state for website functioning. |
| Expiry: | 1 day |
| Type: | LocalStorage |
Statistics (analytical cookies)
These cookies help us to understand how visitors interact with websites by collecting and reporting information anonymously.
| Name: | _ga |
| Provider: | Google Analytics |
| Purpose: | Store and count pageviews. |
| Expiry: | 2 years |
| Type: | http_cookie |
| Name: | _ga_* |
| Provider: | Google Analytics |
| Purpose: | Store and count pageviews. |
| Expiry: | 2 years |
| Type: | http_cookie |
| Name: | _gcl_au |
| Provider: | Google AdSense |
| Purpose: | Store and track conversions. |
| Expiry: | 3 months |
| Type: | http_cookie |
| Name: | _gid |
| Provider: | Google Analytics |
| Purpose: | Store and count pageviews. |
| Expiry: | 1 day |
| Type: | http_cookie |
| Name: | _dc_gtm_* |
| Provider: | Google Analytics |
| Purpose: | Store number of service requests. |
| Expiry: | 1 minute |
| Type: | http_cookie |
| Name: | wd |
| Provider: | |
| Purpose: | Information about browser window dimensions. |
| Expiry: | 1 day |
| Type: | http_cookie |
Marketing (Social plug-ins, third party marketing cookies, pixels)
Marketing cookies are used to follow visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Understanding HTTP response status codes in frontend applications — Part 1: Status codes
In this tutorial, we will explore what status code means and how to use them. We will build a simple Node.js backend to simulate all the most common status codes of all we will cover. This will help us in two ways:
- Consuming APIs when building applications, especially JavaScript powered apps.
- Building RESTful APIs that provide as much accurate response as possible at all times.
HTTP status codes are the defacto language for describing results of the requests browsers (clients) make to servers. Browsers know what the status codes mean, so they know how to present information to you after you make a request.
When you think about it, it makes sense to have defined ways for the server to tell the browser the outcome of a request it made. There are different kinds of browser and different kinds of server configurations to suit specific application needs. If there was no standard communication pattern… anarchy!
Prerequisites
- Basic knowledge of JavaScript.
- Have Node installed on your computer.
- Minimum version Node v8.0.0.
How the browser and server talk to each other
Before you ask “Really? This? Am I three years old?”, I’d urge you to pay attention here, especially if you have not had to build APIs before. Understanding how the browser talks to the server (client-server relationship) in a network will help you make sense of why each status code is important.
Servers are like a central location for data (say a restaurant) and clients are the computers that consistently interact with that data (say hungry customers). Different clients, something in thousands or hundreds of thousands, make requests to the server for data. The server does a number of things:
- First identify what type of client by parsing the header of the request that tells the IP address of the computer, the type of web browser used, type of device used, the preferred language the client wants the data in, the format the data should be in, among other things. This is why when you visit a site like Google with a different language set on your browser, it returns the page in that language. This is how Twitter or Facebook is able to redirect you to m.twitter.com or m.facebook.com when you visit with a mobile phone.
- Confirm you can access the content you are requesting (there are different authorization levels it can use, depending on the kind of content you are requesting).
- Process the request.
- Return the data to you.
The server has to do all of that in split seconds so it can respond to other users who are waiting.
The client on the other hand sends a request along with appropriate headers to properly identify who it is and how it wants to receive the information it has requested. If it is trying to request gated information, it has to present some form of access token/key or be able to show it has authorization to access the data it is requesting. The client is usually not very patient as it is pressed for time and resources. If it does not hear from the server after some time, it closes the connection (just like a hungry customer walks away when they have waited too long to be served).
However, when the server responds, it sends some code to inform the client of the status of its request. Was it successful? Should the client give it more time? Did it fail? Could it not understand the request? Did the client make a mistake in the request it sent? These are the things the server clarifies with status codes.
Of course, client server communication is a lot more complex than that, and there are different tools and protocols that come into play, but that is beyond the scope of this article. What we have looked at now is sufficient to understand the basic status codes we will encounter more frequently when we interact with public APIs.
Clients are not just web browsers. Clients can be computer terminals that make CURL requests or web/mobile applications that interact with APIs to get data or even a device like a refrigerator or TV that is connected to the internet.
The informational status codes — 1xx
What do they do? Short answer — provide information to the browser. They communicate that the request was received and understood, and in most cases, the browser should wait a little as the server processes the information.
100 Continue
When a client gets this status code, it means the server has received their request header and has accepted the request, so the client can go ahead and send the request body. This is most commonly used when a client wants to send content that is large. It will send an Expect: 100 — continue to the server and when the server sends back a response with status 100 continue , it proceeds to send the body.
The status 100 continue received from the server means “You can now send more data or ignore if you are done sending”. In some cases, a client might send Expect: 100 — continue along with the request body. This is most common with curl requests as it is the default mode curl communicates with servers.
101 Switching Protocols
A client can send a request to the server to switch the communication protocol using the Upgrade header. This can be say switching from HTTP/1.1 to HTTP/2 or switching to WebSocket. The server will response with a response code 101 and an Upgrade response header with information on the protocol it upgraded to.
The success status codes — 2xx
These are the status codes we encounter every single day. You load a website and it comes up? One of these status codes was used. You submit a form and get the congratulations message? One of these status codes was used. They are used to indicate that our request was successful
200 Ok
This response status code indicates that our request was successful. This is used mostly when we request for data from the server and it responds with the data. When you visit the link to a webpage, the browser sends a request to the server to give it the contents of that webpage.
The server will respond with a status 200 ok and a header specifying the type of content returned ( text/html , multimedia , etc) and a body containing the content itself.
Many requests for data like visiting a URL are usually GET requests. GET requests are, well, used to get data from the server.
201 Created
This is the response code the client gets after sending resource (data) to the server. This resource is stored by the server and upon successfully storing it, the 201 Created response code is returned with the newly created resource as the request body. It can be form submissions, file uploads or other related activities.
Requests that create resources on the server are usually POST requests. POST requests post resources to the server. In a situation when a PUT request (which is used to update already stored resource) creates the a resource for the first time, a 201 Created can be returned as well.
202 Accepted
This is not a very common response code sent by servers. It is used in cases where a request by the client has been received but the server has sent it in for processing. It is a non-committal response in that when the server eventually comes around to process the request, it may or may not act upon it based on if the client has the right to make that request or if the server has the means to handle it. Also, it means the server will not be sending any response afterwards.
This can be used in cases when a request is transferred to another server or when a request is batched to be proceed at another time. In such a scenario, the server ought to return an indicator of the current status of the request and a way for the client to monitor the processing of the request.
203 Non-Authoritative Information
This is also not a very common response code. It signifies that the response the client is getting is not exactly as it was when sent by the server. It can mean that the response has been modified as it passed through a proxy tunnel or some other related third party.
The data eventually returned might be a subset or superset of the data returned from the server.
204 No Content
This response code tells the client (in the case of a user agent) not to change the current document presented to the user. Header information might be updated, but no new content will be sent along.
This response can be sent after a client makes a request updating a resources on the server and the server does not need to return any data since nothing new was created. The server must never return a response body when it sends a 204 — No Content status code.
205 Reset Content
This response status tells the client to refresh the document sample.
206 Partial Content
This response code indicates that the request has succeeded and the response body has the requested ranges of data. The server only sends ranges of data when the client sets the Range header in it’s request. Bear in mind that the client must never request a range if it cannot handle the range.
If there is only one range, the Content-Type of the whole response is set to the type of the document, and a Content-Range is provided. If several ranges are sent back, the Content-Type is set to multipart/byteranges and each fragment cover one range, with Content-Range and Content-Type describing it.
When a range is requested by the client, the server returns 206 Parital Content and never returns a 200 Ok . Medias like large videos and images are good examples of data return as a range.
Redirections — 3xx
You see these response codes, you need to know them very well if Search Engine Optimization (SEO) means anything to you and your product. These status codes deal with redirection when a client tries to access a resource.
300 Multiple Choices
This status code means the request has more than one possible response. The client is to choose one of them. There is no standardized way of choosing so this is rarely used. In case you see it, look for the Location header which usually contains the servers preferred choice.
301 Moved Permanently
This is arguably the most important of the redirection status codes. When not used properly, it can interfere with your SEO and bury your website forever. It can also created very bad user experience and increase the churn you experience on your website.
This tells the client that the resource they seek has been moved permanently, and then presents the URL to the new location of the resource. This does two things: tells the client where to find the resource and also helps the client know where to go the next time they need the resource. The new location for the resource is specified by the Location header.
301 redirects might require the method (and the body) of the original required not to be altered when the redirection is performed. However, not all client side browsers adhere to this directive. According to Mozilla Developer Docs, it is therefore recommended to use the 301 code only as a response for GET or HEAD methods and to use the 308 Permanent Redirect for POST methods instead, as the method change is explicitly prohibited with this status
302 Found
This is the direct sibling of 301 ��. It is used for temporary redirect. Client browsers will redirect to the specified resource but indexing systems like search engines will not change their reference to the resource as the redirect is only temporary. And like 301 , client browsers might change the body/method of the request, so when you want to temporarily redirect a POST , use 307 instead.
303 See Other
Well, we will call this the cousin to 301 and 302 ��. Simply put, this status code tells the client that the redirect doesn’t link to the newly uploaded resources but to another page, like a thank you page or status monitor page. It is sent as a result of a PUT or POST request and the method to use for the redirections is always GET . I told you this was the cousin.
304 Not Modified
When you have previously fetched a cacheable content, this status code comes in handy. It tells the client that the resource they are trying to fetch has not changed, so they should retain the copy they have. This will come in handy if you are building a system like a newsfeed and you always want to check for new updates. It will prevent you fetching old data and reloading the client browser unnecessarily. A nice option would be to use Pusher’s realtime API.
307 Temporary Redirect
We have already talked about this earlier that it will be okay to skip it right? Well, this response code is sent by the server when it intends to explicitly tell the client to maintain the method originally used for the request. It works just like 302 except it adds a very clear directive not to change anything. Best thing to use in case you have stubborn clients who always change request methods on redirect ��.
308 Permanent Redirect
The 308 Permanent Redirect is the direct sibling of 307 . And it is the strict version of 301 .
Client Error — 4xx
These are the status codes used to inform the client that it made a mistake in the request it made. Was a required field not supplied? Did they send the wrong data format? Are they not authorized to access the resource they are looking at? Do they need to confirm their identity? All of these things are handled by these status codes.
Now, let’s dig into them.
400 Bad Request
I have to admit, this is my favorite status code ��. Every time I get slammed with 400 Bad Request red error on my console, I first look up and ask “What kind of life did I choose?” before I proceed to investigate it.
Bad requests occur when the client sends a request with either incomplete data, badly constructed data or invalid data. Many times, it could be the fault of the developer who did not specify properly what kind of data they expect. Be that as it may, it happens because the data you sent to a request is incorrect.
401 Unauthorized
This response in simple terms means the client needs to authenticate itself before it completes the request. Authentication here could be providing access-token in the case of OAuth or Authorization token in the case of jwt based auth system or even API keys.
Anything that the server needs to identify who is making a request has to be sent for the request to be completed.
403 Forbidden
This error occurs when a client tries to access a resource it is not permitted to. This is not the same as 401 Unauthorized (just see them as fraternal twins ��). An authenticated client can be Forbidden from accessing a resource just as an unauthenticated client can.
Many times, the client only gets 403 Forbidden after it has been authenticated, as the system will have to ensure who the client is first before forbidding or granting them access to the resources.
404 Not Found
If you have used the web frequently, you will definitely have run into this, especially 404 Page Not Found . In API terms, it means the resource you are trying to access was not found or the endpoint itself does not exist. A description of the error might accompany the error, but do not count on this in most cases.
404 does not specify if the resource is missing or has been permanently removed (deleted). In a case where the resource has been removed permanently, the server should return 410 GONE .
405 Method Not Allowed
This response code results when you try to access a resource designed for only GET requests through a POST request and vice versa. Some resources can be accessed via any request method ( GET , POST or HEAD ) and in such a case, you will not get the 405 Method Not Allowed response code.
Standard practice is that when a server sends a 405 response code, it includes a list of methods supported for accessing the resource in question.
406 Not Acceptable
This is a rarely used error code. It indicates that the server cannot produce a response that matches the request the user made, and the server is not willing to send a default response. You can learn more about it on Mozilla Developer Docs.
407 Proxy Authentication Required
This will be the twin of 401 Unauthorized . The only difference is that authentication needs to be done by a proxy.
408 Request Timeout
This response code is sent by the server when it wants to close an idle connection opened by the client. The client may not have completed its request and may be taking so much time doing it.
The standard is that a server will send a close Connection header in the response field along with the response code.
In many cases, the server might shut down the connection without sending any response code.
409 Conflict
This response is sent by the server when a request conflicts with the servers internal operations. A good example of such conflict is trying to update a resource on the server with an older version.
410 Gone
We already mentioned that this status code shows that the resource the client wishes to access has been permanently deleted.
411 Length Required
The server returns this status code if it requires that Content-Length header is set along with the request, and the client did not set it.
412 Precondition Failed
This happens when the client is being too demanding and the server does not have that kind of strength ��. So, clients can send conditional requests to servers, which is excellent. If the conditions are met, the server will response with data. If the conditions are not met, the server will just respond with 412 Precondition Failed .
We will discuss more on conditional requests when we get to 428 Precondition Required .
413 Payload Too Large
The request data is too big for the server to handle ��. In more technical terms, the size of the payload may have exceeded the limit specified by the server.
414 URI Too Long
Just shorten the URL and all will be fine. Realistically, this only occurs when you have a lot of things appended to a URL when constructing a GET request with a lot of parameters.
415 Unsupported Media Type
This is what it is. The server does not support the media type requested by the client.
416 Range Not Satisfiable
The server can’t fulfill the Range specified in the request header. It could mean the Range is requesting more data than the server can give. Think array index out of bounds and you will get the picture.
417 Expectation Failed
When the server cannot meet the expectation contained in the Expect request header field, it sends this response.
418 I'm a teapot
I honestly do not know why this was ever made, but it is a response code for April Fool’s day prank. It means the server refuses to brew coffee because it is a tea pot ��. You can read more about this prank on Wikipedia.
419 Authentication Timeout
At the moment, this is only obtainable with Laravel applications. It means the csrf token of the application has expired. The csrf token in Laravel is sent with every form submission or request to resources protected by authentication and more.
426 Upgrade Required
The server returns this response code when it is unwilling to communicate with the client via a certain protocol, but is willing to continue communication if they change protocols. Yep, I agree… These servers are just full of themselves.
The server sends an Upgrade header with this response to provide a list of protocols it is willing to use in continuing communication.
428 Precondition Required
This response is sent by the server when it requires a request to be conditional. A conditional request is a request where the result might change based on a validation of the resource requested. Conditional requests are useful in scenarios like downloads where a client can pause and resume at any time.
For such requests, a required precondition header like If-Match is required. If the precondition header does not match what the server has, then a 412 Precondition Failed is sent instead.
429 Too Many Requests
This status code is sent when a user has sent too many requests than allowed in a given period of time. It is common with APIs that limit usage by time period.
431 Request Header Fields Too Large
The server is just unwilling to process the request because it feels the headers of the request are too large. That is all.
The client can reduce the headers and try the request again.
451 Unavailable For Legal Reasons
The resource the client has requested cannot be served for some legal reasons. Serving it to that user will mean breaking the law.
In practice, you will rarely encounter most of the error codes, but it is good you know them. They become more common with increasing complexity of the applications you build.
Error — 5xx
These errors occur due to no fault of the client. The servers are to be blamed here and there is nothing the client can do to get their desired response.
500 Internal Server Error
When the server processes the request of the client and runs into a situation it cannot handle, it sends 500 Internal Server Error . These issues can be caused by many things. A service required by the server may not be available. The developer who build the application may have used a package or library and forgot to download it on the server. The developer might have buggy code and the server ran into it. It could be anything preventing the server from completing it’s operation.
501 Not Implemented
The server sends this code when you have made a request to it with a request method it does not know or have the capacity to resolve. Servers are required to implement only GET and HEAD methods, so you might send a PUT or PATCH request and the server will not be able to handle it.
This is not the same as 405 Method Not Allowed because with 405 the server clearly understands the request but cannot respond to it until the method is changed. With 501 the server cannot understand the method used and is therefore incapable of providing any response.
502 Bad Gateway
The server sends this code when it is acting as a proxy server and/or fetching data from an external resource and it gets an invalid response from that external source.
503 Service Unavailable
This is a common server error code that you can get. It means the server might be down and therefore, is not ready handle the request at that time. This might be a result of an ongoing maintenance or an overload on the server.
This is a temporal situation, so if you implement caching in your application, you might want to not cache this response.
504 Gateway Timeout
The direct sibling to 502 ��. The server sends this response code when it is acting as a gateway and the external resource does not provide it with a response in time.
505 HTTP Version Not Supported
This status code indicates the HTTP version the client used for the request is not supported by the server. Think making a HTTP/1.1 call to a server when the server only deals in HTTP/2 ��.
511 Network Authentication Required
This status code means the client needs to get authenticated on the network it is trying to access before access can be granted. This happens when trying to access a network via proxy, so it can be argued to be a distant cousin of 401 Unauthorized .
Where there is a difference is that 401 tells the client directory it needs to be authenticated but 511 means the proxy network cannot access the external resource because of lack of proper authorization.
Conclusion
If you followed this tutortial, then you my friend are more than ready to build very amazing web applications. A proper understanding of these status codes makes all the difference in the user experience of your application. Understanding them means you can efficiently design your application to handle errors or issues that may arise gracefully.
If you are a developer building an API, you can more easily send the appropriate responses for the scenarios your users encounter as they use your application. This is equally very important in building useful applications.
In the next tutorial, we will look it is consuming APIs and experiencing the status codes we have received.
HTTP Status Codes
REST APIs use the Status-Line part of an HTTP response message to inform clients of their request’s overarching result. RFC 2616 defines the Status-Line syntax as shown below:
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
HTTP defines these standard status codes that can be used to convey the results of a client’s request. The status codes are divided into five categories.
- 1xx: Informational – Communicates transfer protocol-level information.
- 2xx: Success – Indicates that the client’s request was accepted successfully.
- 3xx: Redirection – Indicates that the client must take some additional action in order to complete their request.
- 4xx: Client Error – This category of error status codes points the finger at clients.
- 5xx: Server Error – The server takes responsibility for these error status codes.
1xx Status Codes [Informational]
2xx Status Codes [Success]
3xx Status Codes [Redirection]
4xx Status Codes (Client Error)
5xx Status Codes (Server Error)
6. REST Specific HTTP Status Codes
200 (OK)
It indicates that the REST API successfully carried out whatever action the client requested and that no more specific code in the 2xx series is appropriate.
Unlike the 204 status code, a 200 response should include a response body. 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.
201 (Created)
A REST API responds with the 201 status code whenever a resource is created inside a collection. There may also be times when a new resource is created as a result of some controller action, in which case 201 would also be an appropriate response.
The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field.
The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with a 202 (Accepted) response instead.
202 (Accepted)
A 202 response is typically used for actions that take a long while to process. It indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, or even maybe disallowed when processing occurs.
Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent’s connection to the server persist until the process is completed.
The entity returned with this response SHOULD include an indication of the request’s current status and either a pointer to a status monitor (job queue location) or some estimate of when the user can expect the request to be fulfilled.
204 (No Content)
The 204 status code is usually sent out in response to a PUT , POST , or DELETE request when the REST API declines to send back any status message or representation in the response message’s body.
An API may also send 204 in conjunction with a GET request to indicate that the requested resource exists, but has no state representation to include in the body.
If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view. However, any new or updated metainformation SHOULD be applied to the document currently in the user agent’s dynamic view.
The 204 response MUST NOT include a message-body and thus is always terminated by the first empty line after the header fields.
301 (Moved Permanently)
The 301 status code indicates that the REST API’s resource model has been significantly redesigned, and a new permanent URI has been assigned to the client’s requested resource. The REST API should specify the new URI in the response’s Location header, and all future requests should be directed to the given URI.
You will hardly use this response code in your API as you can always use the API versioning for the new API while retaining the old one.
302 (Found)
The HTTP response status code 302 Found is a common way of performing URL redirection. An HTTP response with this status code will additionally provide a URL in the Location header field. The user agent (e.g., a web browser) is invited by a response with this code to make a second. Otherwise identical, request to the new URL specified in the location field.
Many web browsers implemented this code in a manner that violated this standard, changing the request type of the new request to GET, regardless of the type employed in the original request (e.g., POST). RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. 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.
303 (See Other)
A 303 response indicates that a controller resource has finished its work, but instead of sending a potentially unwanted response body, it sends the client the URI of a response resource. The response can be the URI of the temporary status message, or the URI to some already existing, more permanent, resource.
Generally speaking, the 303 status code allows a REST API to send a reference to a resource without forcing the client to download its state. Instead, the client may send a GET request to the value of the Location header.
The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
304 (Not Modified)
This status code is similar to 204 (“No Content”) in that the response body must be empty. The critical distinction is that 204 is used when there is nothing to send in the body, whereas 304 is used when the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match.
In such a case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.
Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.
307 (Temporary Redirect)
A 307 response indicates that the REST API is not going to process the client’s request. Instead, the client should resubmit the request to the URI specified by the response message’s Location header. However, future requests should still use the original URI.
A REST API can use this status code to assign a temporary URI to the client’s requested resource. For example, a 307 response can be used to shift a client request over to another host.
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 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.
400 (Bad Request)
400 is the generic client-side error status, used when no other 4xx error code is appropriate. Errors can be like malformed request syntax, invalid request message parameters, or deceptive request routing etc.
The client SHOULD NOT repeat the request without modifications.
401 (Unauthorized)
A 401 error response indicates that the client tried to operate on a protected resource without providing the proper authorization. It may have provided the wrong credentials or none at all. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
The client MAY repeat the request with a suitable Authorization header field. If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information.
403 (Forbidden)
A 403 error response indicates that the client’s request is formed correctly, but the REST API refuses to honor it, i.e., the user does not have the necessary permissions for the resource. A 403 response is not a case of insufficient client credentials; that would be 401 (“Unauthorized”).
Authentication will not help, and the request SHOULD NOT be repeated. Unlike a 401 Unauthorized response, authenticating will make no difference.
404 (Not Found)
The 404 error status code indicates that the REST API can’t map the client’s URI to a resource but may be available in the future. Subsequent requests by the client are permissible.
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.
405 (Method Not Allowed)
The API responds with a 405 error to indicate that the client tried to use an HTTP method that the resource does not allow. For instance, a read-only resource could support only GET and HEAD, while a controller resource might allow GET and POST, but not PUT or DELETE.
A 405 response must include the Allow header, which lists the HTTP methods that the resource supports. For example:
406 (Not Acceptable)
The 406 error response indicates that the API is not able to generate any of the client’s preferred media types, as indicated by the Accept request header. For example, a client request for data formatted as application/xml will receive a 406 response if the API is only willing to format data as application/json .
If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.
412 (Precondition Failed)
The 412 error response indicates that the client specified one or more preconditions in its request headers, effectively telling the REST API to carry out its request only if certain conditions were met. A 412 response indicates that those conditions were not met, so instead of carrying out the request, the API sends this status code.
415 (Unsupported Media Type)
The 415 error response indicates that the API is not able to process the client’s supplied media type, as indicated by the Content-Type request header. For example, a client request including data formatted as application/xml will receive a 415 response if the API is only willing to process data formatted as application/json .
For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
500 (Internal Server Error)
500 is the generic REST API error response. Most web frameworks automatically respond with this response status code whenever they execute some request handler code that raises an exception.
A 500 error is never the client’s fault, and therefore, it is reasonable for the client to retry the same request that triggered this response and hope to get a different response.
The API response is the generic error message, given when an unexpected condition was encountered and no more specific message is suitable.