HTTP errors allow for error handling and response codes, which is especially helpful when interacting with services that have strict standards and need to know exactly what went wrong when something goes awry. They are essentially codes used to indicate the failure of a URL request in some way or another.
A client can receive over 200 documented responses from an HTTP server. These codes range from common success codes like 200, or error codes like 404 and 500. While most of these error codes tend to be self-explanatory, some aren’t so obvious – especially when resolving them.
Let us take a closer look at some of the more common HTTP status codes and how best to resolve them when they happen.
HTTP (HyperText Transfer Protocol) status codes, also known as HTTP response codes, are how the server returns information about the success of an HTTP request.
There are five classes of HTTP status codes: 1xx, 2xx, 3xx, 4xx, and 5xx. Understanding them can help you quickly determine the general content of a status code before you go into the specifics. Jump to the section where we explain All HTTP Status Codes in detail.
When a search engine bot crawls a website’s URLs, it detects the HTTP status codes. These messages can determine whether a webpage is indexed or not and whether the website is perceived as healthy. Thus, HTTP status codes matter a lot for SEO.
Read the section: ‘How to Resolve HTTP error codes’.
6.
7.
8.
10.
HTTP (HyperText Transfer Protocol) status codes, also known as HTTP response codes, are how the server returns information about the success of an HTTP request.
The status code is a standard way for servers to communicate with users (and vice-versa).
With an HTTP status code, you can determine whether a website is working correctly or if there is an issue that needs to be fixed. HTTP status codes are delivered to your browser in the HTTP header. This is where you'll find the status code, as well as the message that was sent with it.
The reason for the existence of an HTTP response code is simple: to help servers and browsers understand what happened during a request. Status codes are categorized as informational, successful, redirects, or error codes.
Each type of code indicates the result of a specific request made by a user. The most popular status code is “200 OK”, which means the request was successful. The other codes might indicate a problem with the website or server, but most of them have a meaning.
There are five classes of HTTP status codes. These groupings of responses have similar or related meanings. Understanding them can help you quickly determine the general content of a status code before you go into the specifics.
The five classes include:
Informational HTTP response codes are all numbers in the 1xx range, meaning they’re informational messages that don’t necessarily indicate an error. For example, they can be used to communicate that a request was received or if there was an issue with the request.
Successful HTTP response codes are all numbers in the 2xx range, indicating a successful request, and the webpage can load without issue. The browser was able to receive, understand, and process the requested resources successfully.
Redirection HTTP response codes are all numbers in the 3xx range, used to indicate a redirection from the requested page to another. Redirection status codes are typically used for temporary situations, such as a page under construction or a page that has been temporarily moved. Read our complete guide on URL Redirection here.
Client Error HTTP response codes are all numbers in the 4xx range, meaning they’re client errors and indicate issues with end-user requests. These errors can include issues such as missing required parameters or invalid syntax.
Server Error HTTP response codes are all numbers in the 5xx range, meaning they’re server errors and indicate issues with server-side requests that prevented the completion of the request.
There are various server codes within each of these classes. We will discuss the specific meaning of each code in a more comprehensive list below.
Yes, they do, as they are a valuable tool for proper SEO and web platform management. For example, proper error management can help SEO teams keep track of all their issues and know precisely what went wrong and why. The ability to track issues and understand what went wrong and how to fix it can help SEOs assess the overall health and stability of a site’s infrastructure.
When a search engine bot crawls a website, it notices the HTTP status codes. These messages can determine whether a webpage is indexed or not and whether the website is perceived as healthy.
If a search engine bot notices an error code, it will not index the page. This is because it understands that there are issues with the website’s infrastructure, content, or both and that there is a high probability of the same errors appearing on other pages. This can cause a degradation in search engine bot crawling.
A search engine bot may lower its crawl rate as soon as HTTP status code errors are noticed. This is especially true for the 5xx class of HTTP status codes.
In addition, a website’s HTTP status codes can be used by search engines to determine how relevant your content is to their users’ queries. Therefore, the better you manage your site’s HTTP status codes and errors, the more relevant your content will appear in search results.
For example, if you have an error message on your site saying “page not found” (404), users have tried to access a page that does not exist – which is considered one of the most common user experience issues on websites today.
Suppose you do not have an error page set up for these types of errors and instead display some generic information about the requested page (such as “this page does not exist”), in that case, search engines can determine that this error message does not align with users’ expectations and relevance requirements, which may negatively impact your site rankings in SERPs.
It is suggested to set up custom 404 pages and includes elements like additional navigation paths via internal linking. This can ensure you provide a positive experience to your website users even if they land on an error page.
Every professional SEO and website owner should know the status codes with the most significant impact on SEO. Knowing HTTP response code classes and common server errors will help you diagnose and troubleshoot problems on your website quickly and efficiently.
Some common HTTP Status Codes every SEO should know include:
1. Status Code: 200 - OK
This code indicates the request was successful and that the requested content is being returned.
2. Status Code: 301 - Moved permanently
This code indicates the request was successful, but the requested content has permanently moved to a new URL. For example, this code is used when content is permanently removed or changed. Learn more about the 301 status code and URL redirection here.
3. Status Code: 302 - Moved temporarily
This code indicates the requested content has temporarily moved to a new URL. It’s often used when a website undergoes construction or even testing. This code is also used when administrators have deleted the content but want to preserve its links. Learn more about the 302 status code and URL redirection here.
4. Status Code: 404 - The request was not found
This is the most critical error. It is used when the requested file, such as a web page, image, or CSS file, cannot be found. Read all about the ‘404: Page not Found’ Error here. Read How to Fix a 404 Error Page here.
5. Status Code: 500 - Internal Server Error
This error indicates an unexpected error occurred while handling the request. This usually means that something is wrong with your server.
There are over 40+ HTTP server status codes, but you are unlikely to see all of them regularly. The more common ones are listed below, along with a few rare codes you may still come across.
All 1xx status codes are informational and mean that the request was received but not yet processed.
This status code is used when a server initially receives a request but needs to wait before processing it, such as when loading resources or making additional checks on security and permissions. When this response is received, the client should continue with its request instead of waiting for a final response from the server. See RFC7231, Section 6.2.1, for more information.
The HTTP protocol has grown significantly since the evolution of the Internet when HTTP 0.9 was first documented. HTTP 2.0 is the current version, which is also known as HTTP/2.
When the server receives a request from a browser to switch to a different HTTP protocol using the Upgrade header field, HTTP status code 101 Switching Protocols is returned. For example, when a page is requested, the server might return HTTP status code 101 and then the Upgrade header, indicating that the server is switching to a newer HTTP version.
A server will only switch protocols if it is in the server's best interest, for example, by upgrading to a newer protocol rather than an older one. See RFC7231, Section 6.2.2, for more information.
The 102 status code indicates that the server has received and is now processing the request. This response code may be used when a server is working on fulfilling a request but is not yet complete, meaning that clients can continue to send additional requests while waiting for a response from the server. See RFC2518, Section 10.2, for more information.
A 103 status code is used when a server has made an early attempt at fulfilling a request and encountered an issue, but it's not yet clear if it will be successful or if there was an error. See RFC8297, Section 2, for more information.
All 2xx status codes convey successful server response codes and mean that the request was successful but may include improvement recommendations.
This status code indicates that the request was successful and any data requested by clients was returned successfully by the server; this response code is typically used with resources such as images, documents, etc. See RFC7231, Section 6.3.1, for more information.
This response code is used to indicate that the request was successful and any data requested by clients was returned successfully by the server, but that it also resulted in a new resource being created; this is typically used for resources like blog posts or documents that have been uploaded to a server. See RFC7231, Section 6.3.2, for more information.
This response code indicates that the request was accepted for processing, but the processing has not been completed yet; this is typically used when a request has been sent but will take some time to complete (such as with a long-running process). See RFC7231, Section 6.3.3, for more information.
An HTTP proxy or third party sitting between the client and server may modify the responses before delivering them to the client. To indicate that a response has been altered, the server returns a status code of 203. See RFC7231, Section 6.3.4, for more information.
A 204 code indicates that the server has successfully delivered the response, and no additional content will be sent in the response body. See RFC7231, Section 6.3.5, for more information.
This response code indicates that the server has sent the request successfully and requires the user agent to refresh/reset the view to its original state. A 205 status code assumes no additional content will be provided. See RFC7231, Section 6.3.6, for more information.
A 206 status code can be used for various requests and typically indicates that the server has fulfilled a partial request for a resource. For example, suppose a client is looking for a specific range, or a portion, of a particular page or resource. In that case, this is a standard practice among HTTP video players to avoid bandwidth and latency issues. See RFC7233, Section 4.1, for more information.
This status code is used in WebDAV to indicate multiple status codes for a single request. Learn more about 207 HTTP status code.
This status code is used in WebDAV to avoid repeatedly sending the same information about a collection that has not changed. Learn more about 208 HTTP status code.
This status code indicates that the server has fulfilled a request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. Learn more about 226 HTTP status code.
These status codes are used when the client must take additional action to complete the request. For example, a 3xx status code indicates that the requested resource is available at a different URL and that the user agent must process a second request to obtain the resource.
Read our blog on URL Redirection to understand the concept before implementation.
Some common 3xx redirection status codes include
A 300 Multiple Choices status code indicates that a resource has moved and can redirect to multiple locations. In this case, it is up to the user to decide which resource to use. Due to the lack of a standardized method of choosing among multiple responses, this status code is rarely used in practice. See RFC7231, Section 6.4.1, for more information.
This status code means that there has been a change in the content of the requested resource and that future requests should use another URL to access it (the new URL also can be found in the Location header). See RFC7231, Section 6.4.2, for more information regarding this status code.
The requested resource resides temporarily under a different URL and will be retrieved using an alternative method (generally used by HTTP proxies). See RFC7231, Section 6.4.3, for more information regarding this status code.
This status code is used when the requested resource can be provided using a different URL, and the client must follow a different link to access it. See RFC7231, Section 6.4.4, for more information regarding this status code.
This status code is used when the requested resource has not been modified since the version specified by the client in its request. See RFC7232, Section 4.1, for more information regarding this status code.
Servers should use this response under abnormal conditions (i.e., DNS failures) that don't have a valid response ready to send to a client's request; it tells the client that it must try again later because of some temporary condition beyond the server's control. See RFC7231, Section 6.4.7, for more information regarding this status code.
This response should be used when the requested resource can permanently redirect to another URI, and all future requests should use that URL instead of the original one (the new URI also can be found in the Location header). See RFC7238, Section 3, for more information regarding this status code.
When HTTP status codes reach 400, they become problematic. You may receive these error codes if your browser or request has encountered a problem.
Some common 400 status codes are
The response code request means that the server cannot process the request due to an issue from the client. This could be due to any number of reasons, such as a file being too large, bad syntax, an invalid URL, or some other issue caused by a third-party application, which is why the 400 status code is sometimes used as a catch-all status code, even if there is an issue on the server-side. See RFC7231, Section 6.5.1, for more information regarding this status code.
The 401 status code indicates an issue with the request and/or data included in the request, including issues such as invalid syntax or missing required parameters. This response is sent by a server that refuses to fulfill a request because the user (or client) lacks the necessary authorization. See RFC7235, Section 3.1, for more information.
This status code indicates an issue with authorization; if you’re making requests over HTTPS, you may receive this error if your browser doesn’t have access to your account. For more information on the 402 Payment Required error code, see RFC7231, Section 6.5.2
This status code indicates an issue with permissions on the server; this can include issues such as not having permission to access a particular file or folder on a website. See RFC7231, Section 6.5.3, for more information.
The 404 status code indicates that no resource was found at the specified URL. The requested resource could not be found but may be available again in the future (e.g., after restful API changes have been made). Learn How to Fix a 404 Error Page here.
This error occurs when the hosting server (origin server) supports the method received, but the target resource does not. For more information on the 405 Method Not Allowed error code, see RFC7231, Section 6.5.5
The 406 status code Indicates that the server cannot provide the content specified in the request due to the type of content requested. See RFC7231, Section 6.5.6, for more information.
The 407 status code indicates that a proxy server is in use and requires your browser to authenticate itself before continuing. For more information on the 407 Proxy Authentication Required error code, see RFC7235, Section 3.2
This status code indicates no activity on the connection even though it had been idle for longer than the server would allow. This is usually due to a client being unable to handle a request in a timely fashion or server latency. See RFC7231, Section 6.5.7, for more information regarding this status code.
The 409 status code indicates that the request could not be completed due to a conflict with the current state of the resource, similar to when you have an edit conflict in a word document, and you have to resolve it before you can save your changes. For example, a server sends this response if the user tries to create, update, or delete an existing resource. See RFC7231, Section 6.5.8, for more information.
This status code indicates that the requested resource is no longer available and will not be available again; usually used if an API has been deprecated or if there was an error and the API no longer exists (e.g., if there was an error connecting to an external service). See RFC7231, Section 6.5.9, for more information regarding this status code.
The 411 status code indicates that the requested resource requires the client to specify a certain content-length header while making requests, which did not happen. See RFC7231, Section 6.5.10, for more information regarding this status code.
The 412 status code indicates that the server refuses to process a request because the preconditions were not met. For example, if you don’t have permission to update a resource, you will receive this response when trying to update it. See RFC7232, Section 4.2, for more information regarding this status code.
This status code indicates that the server is refusing to process a request because the request body is too large (e.g., uploading an image too large). See RFC7231, Section 6.5.11, for more information.
A 414 HTTP status code indicates that the URL provided was too long and has been truncated; usually used when there is too much text being sent as part of the query string (i.e., too many parameters are sent in one request). See RFC7231, Section 6.5.12 for more information.
This status code indicates that the server does not support the media type of the request body. See RFC7231, Section 6.5.13, for more information regarding this status code.
The 416 HTTP status code indicates that the range specified in a request is not available; usually used if you try to get a range of characters in a document or resource that does not exist or has been removed from an API service. See RFC7233, Section 4.4 and 10, for more information regarding this status code.
This status code indicates that there is some client expectation failure; usually used when one side has made assumptions about how certain parts of their interaction will work with another party, and those assumptions were incorrect. See RFC7231, Section 6.5.14, for more information regarding this status code.
This status code indicates that the request was directed at a server that is not able to produce a response. This can occur when a client sends a request to the wrong server, or when a server is not able to route the request to the appropriate downstream server. Learn more about 421 HTTP status code.
A 422 response code is used when the request cannot be processed due to semantic or syntax errors, e.g. if you send a malformed JSON document. See RFC4918, Section 11.2, for more information regarding this status code.
This status code indicates that the resource that the client is trying to access is locked, and that the client should try again later. Learn more about 423 HTTP status code.
This status code indicates that the request failed because it depended on another request and that request failed. Learn more about 424 HTTP status code.
This code is sent when the server is unwilling to process a request because it may be replayed. See RFC8470, Section 5.2, for more information regarding this status code.
This status code indicates that the client must use some newer protocol to communicate with the server. See RFC7231, Section 6.5.15, for more information regarding this status code.
This HTTP code is used when a precondition is not met in the request, e.g. if you do not have write permissions for an image or video you are trying to update or delete. See RFC6585, Section 3, for more information regarding this status code.
The 429 HTTP code is used when the rate limit on your account has been exceeded, e.g., if you are hitting the rate limit on your account too quickly. See RFC6585, Section 4, for more information regarding this status code.
This HTTP code is used when the server refuses to process the request because one or more header fields are too large. See RFC6585, Section 5, for more information regarding this status code.
This indicates that something about your request is illegal and/or violates ethical reasons (e.g., copyright violation). See RFC7725, Section 3, for more information.
These status codes are used when the server encounters an error or failure that prevents it from fulfilling the request. They are considered some of the more serious HTTP error codes related to search engine bot crawl rates. These bots do not want to encounter these status codes.
Some common 5xx HTTP status codes include
This indicates that the server experienced an error of its own. Something went wrong on the server, and the requested resource was not delivered. This code is typically generated by third-party plugins, faulty PHP, or even the connection to the database breaking. See RFC7231, Section 6.6, for more information regarding this status code.
This indicates that the server does not support the functionality being requested by the client, e.g. if you make a call to an API endpoint that has not been implemented on the server or is currently undergoing maintenance. See RFC7231, Section 6.6.2, for more information regarding this status code.
This HTTP code is used when there are no available gateways to handle your request, e.g., if there are no available gateways and/or load balancers to manage your request or backend services are all down (e.g., network outage). See RFC7231, Section 6.6.3, for more information regarding this status code.
This response code is used when a service cannot process requests for temporary reasons, e.g. if a service is experiencing load issues or network outages that cause it to be unresponsive. See RFC7231, Section 6.6.4, for more information regarding this status code.
This HTTP code is used when a gateway has not received a timely response from the backend service, e.g. if the backend service is experiencing intermittent issues or delays in responding to requests. See RFC7231, Section 6.6.5, for more information regarding this status code.
This is used when the server does not support the HTTP version used by the client, e.g. if you make a call to an API endpoint using HTTP 1.0 when the server only supports HTTP 1.1 or vice versa. See RFC7231, Section 6.6.6, for more information regarding this status code.
This status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process. Learn more about 506 HTTP status code.
This status code indicates that the server is unable to store the representation needed to complete the request. Learn more about 507 HTTP status code.
This status code indicates that the server detected an infinite loop while processing the request. Learn more about 508 HTTP status code.
This status code indicates that the server requires further extensions to the request in order to fulfill it. Learn more about 510 HTTP status code.
This indicates that you're attempting to access a resource on a network that requires network authentication, e.g., if you are trying to access a database server on a corporate network that requires you to log into a network or database server. See RFC6585, Section 6, for more information.
Several tools and website crawlers are available for finding a page's server response code. You can also find the error codes on your browser.
Inspect the HTML source code of the web page to find the HTTP response code.
For example, in Google Chrome, press Ctrl+U (or Cmd+U on Mac) to view the source code of a page. Alternatively, you can right-click on a page and click View Page Source or similar.
In Firefox, press Ctrl+Shift+U or Cmd+Shift+U on Mac to view the source code of a page. For Internet Explorer, press F12 and click Console. You can also copy/paste the URL from your browser's address bar into an online HTTP response code checker tool (discussed below).
Numerous tools are available for analyzing pages for HTTP response codes, including WebFX, Screaming Frog, and Site Checker. You can also use website crawlers such as Googlebot, Bingbot, Yahoo! Slurp, etc., which visit web pages and return information, including server response codes.
Google Search Console can be used to monitor how Google perceives HTTP status codes on your site. For example, the Coverage report displays 300-, 400-, and 500-level status codes.
The Excluded, Error, or Valid with warnings sections may contain pages with 300-, 400-, and 500-level HTTP status codes. A 301 redirect, for instance, may be listed under Excluded as a page with a redirect. 400- and 500-level status codes will likely turn up under Error.
Another way to view HTTP status codes is using the URL Inspection tool within Google Search Console. This can help you know the HTTP status of individual web pages on your website and what error code it is returning.
To use the command line to check and resolve HTTP error codes, you can follow these steps:
1. Open the Command Prompt or Terminal application on your computer.
2. Type in the following command: curl -I https://example.com, replacing "https://example.com" with the page URL you want to check.
3. Press Enter to run the command.
4. Look for the HTTP status code in the response header in the command line output. The status code is typically found on the first line and will be a three-digit number, such as 200, 404, or 500.
5. Interpret the status code using a reference guide to HTTP status codes, such as the one provided by the Internet Assigned Numbers Authority (IANA).
6. If the status code indicates an error, take steps to resolve the issue. For example, if the code is 404 (Not Found), you may need to check whether the page exists and the URL is correct.
You can also take this knowledge and apply it to future requests to receive even better results. Knowing how your requests are handled allows you to make adjustments to obtain even better results. This is especially helpful if you’re working with APIs that have rate limits. When you know how your requests are handled, you can make adjustments to receive even better results.
When you know what goes into the HTTP response, you can better understand how your requests are handled and how to resolve issues when they arise. With this information, you can rest easy knowing that you’ve got everything you need to resolve any issues that may arise.
HTTP status codes are a series of numbers and brief phrases that provide information on the status of a URL request. Each code indicates a different type of response to a request, such as success, failure, redirect, client error, server error, or informational response.
HTTP status codes are categorized into five main classes: informational (1xx), success (2xx), redirection (3xx), client error (4xx), and server error (5xx). Informational status codes indicate that the server is processing the request and that no data is returned. Success codes indicate the request was successfully processed. Redirection codes indicate that the request has been redirected to another URL. Client error codes indicate that the client made an error in its request. Finally, server error codes indicate that the server failed to fulfill a valid request.
HTTP status codes can be returned using PHP's header() function. The function takes two arguments: the status code, which is a number that corresponds to a specific type of response, and a brief description of the response. After calling this function, the server will return the corresponding status code and description to the client. This can help ensure the client receives the appropriate response to the request.
Quattr is an innovative and fast-growing venture-backed company based in Palo Alto, California USA. We are a Delaware corporation that has raised over $7M in venture capital. Quattr's AI-first platform evaluates like search engines to find opportunities across content, experience, and discoverability. A team of growth concierge analyze your data and recommends the top improvements to make for faster organic traffic growth. Growth-driven brands trust Quattr and are seeing sustained traffic growth.
Try our growth engine for free with a test drive.
Our AI SEO platform will analyze your website and provide you with insights on the top opportunities for your site across content, experience, and discoverability metrics that are actionable and personalized to your brand.
.svg)
.svg)
