Mar 10, 2022
A Comprehensive List of HTTP Status Codes
An HTTP status code is a message issued by a server regarding a client’s request status. If your browser displays it when accessing a particular web page, it means the upstream server encountered a problem when trying to process a request.
There are different types of HTTP response status codes based on the server’s response to the client’s request, making them a valuable tool for troubleshooting. Knowing what each of these statuses means will help maintain your website’s performance and search engine optimization (SEO).
Keep reading to know more about HTTP status codes and their types. We will also cover HTTP status codes that have an impact on SEO.
What Are HTTP Status Codes?
When you access a website, your browser sends a request to a web server for page content. After processing the request, the server sends back the requested content along with an HTTP status code.
An HTTP status code consists of three digits. The first digit, ranging from one to five, indicates the status type. The second and third digits refer to the status codes within the first digit’s range. The Internet Assigned Numbers Authority (IANA) maintains over 40 official status codes.
Despite residing in the page’s HTTP header, your browser generally doesn’t display the said HTTP status code by default. However, you can use your browser’s built-in inspect tools or an HTTP header checker to see the HTTP headers that the server returns.
The status code is only visible when the server fails to process the request, preventing the browser from displaying the requested content. The status code will vary depending on the error.
Types of HTTP Status Codes
The existing HTTP response status codes are divided into five response classes. Each status code class represents a type of communication that happens between the web server and the client.
Here are the five HTTP status code classes:
- 1xx (informational) ‒ the server received the request and is currently processing it.
- 2xx (successful) ‒ the server successfully received the request and sent back the expected response.
- 3xx (redirection) ‒ the server requires additional actions to complete the request due to resource relocation.
- 4xx (client error) ‒ the server cannot fulfill the request due to bad syntax.
- 5xx (server error) ‒ the server fails to fulfill a valid request.
The following sections will explore these five HTTP status code classes and their most common response status codes.
The 100 status code class indicates that the server is still processing the request. Its error message, issued on a provisional basis, consists of a status line and optional header fields. An empty line will terminate it.
HTTP status codes of this class inform the user regarding the ongoing process, prompting them to wait for a response. Therefore, a server may send more than one status code during this period.
This status code confirms that the server hasn’t rejected the request headers and prompts the client to send the message body.
Its purpose is to determine whether the server is willing to accept the request without sending the request body, making the process more efficient.
101 Switching Protocols
The server has complied with the request sent by the user agent to switch protocols for optimal response delivery. For example, switching to a newer version of HTTP will reduce download times and server latency.
103 Early Hints
This status code indicates that the client will receive some request header fields preceding the final HTTP message. It lets the user agent preload the resources while waiting for the process to complete. A server will generally include the same header fields in the final response.
The 200 status code class confirms that the server has successfully received, understood, and accepted the request.
This is a standard response status code for a successful HTTP request. The server sends it along with the requested resources, allowing the web page to function normally.
The information returned with the status code depends on the chosen request method:
- GET request ‒ contains an entity corresponding to the requested resource.
- HEAD request ‒ contains the request header fields corresponding to the requested resource excluding the request body.
- POST request ‒ describes or contains an action’s result.
- TRACE request ‒ contains the request message that the server received.
This status code confirms that the request was successful and the server has created a new resource which will be sent back in the response body.
A Location header field or the request’s Uniform Resource Identifier (URI) identifies the newly created resource. The media type in the Content-Type header field determines the entity format.
The server has approved the request but hasn’t started or completed the process yet. By sending this response code, the server can accept a request for another process without forcing the user agent to maintain the connection until the process is complete.
203 Non-Authoritative Information
This response code only appears when using a proxy server. The proxy server modifies the 200 response status code sent by the origin web server before passing it to the client.
204 No Content
This status code communicates that the server successfully processed the request but isn’t returning any content. It will be terminated by the first empty line after the header fields, preventing the request from having a request body.
For example, this status code may appear on a web page with a “save and continue” function. The client doesn’t need to navigate away from the web page after successfully saving the changes.
205 Reset Content
Similar to the 204 status code, 205 Reset Content indicates that the server has successfully processed the request but will not return any content. The only difference is that it also asks the user agent to reset its document view.
206 Partial Content
This status code generally appears on browsers compatible with HTTP header Accept-Ranges, meaning that the browser supports partial downloads.
It indicates that the server successfully processed the request but only sent part of the requested resources as described in the Range header field.
The 300 status code class signals that the user agent needs to take additional actions to fulfill the request. The reason is that the requested resource has been relocated to another location. That’s why it usually comes with redirects to the new place.
Due to its function, this status code class generally appears in URL forwarding. However, you may not see this status code if the second request uses either the GET or HEAD request method. In this case, the user agent can carry out the additional action without user interaction.
300 Multiple Choices
This redirect status code indicates that the user agent may choose one of the available requested resources. It generally appears when there are multiple filename extensions or ambiguity within the request.
301 Moved Permanently
This status code generally appears with permanent page redirects. It communicates the resource’s permanent relocation to another URL, which is stated in the Location headers.
As the relocation is permanent, search engines will redirect all traffic from the old page to the new one when web crawlers encounter this status code. For this reason, web owners usually use this status code when transferring or changing their domain or merging two websites.
Similar to the 301 status code, 302 Found redirects a user to another URL. However, since the relocation is only temporary, it prompts the browser to process future requests using the old URL.
303 See Other
This status code indicates that a user is redirected to another page instead of a newly uploaded resource, which is retrievable using a GET request method. It generally responds to PUT, POST, or DELETE HTTP requests.
304 Not Modified
The server is telling the browser that the resource hasn’t changed since it was cached. Therefore, the browser can access its local cache for the requested resource, reducing the page load time.
305 Use Proxy
The requested resource is only accessible through a proxy server stated in the Location header field. Therefore, the browser should connect to that proxy and resend the request. Only origin servers are allowed to generate this status code.
307 Temporary Redirect
This redirect status code has a similar purpose to 302 Found. The only difference is that 307 Redirect doesn’t change the used HTTP method and the original message body when redirecting the request.
Websites usually use 307 Redirect to send a confirmation message.
308 Permanent Redirect
308 Permanent Redirect works similarly to 301 Moved Permanently. However, it mirrors 307 Redirect in that it doesn’t change the HTTP method and the original message body.
400 Client Error
The 400 status code class targets events in which an error originating from the client-side prevents the server from processing the request. The issue may be with the browser or the request itself.
If you see this error code, there’s a client-side error that makes the request invalid for processing. Some of the most common causes include faulty request syntax, invalid cookies, and an unsynchronized DNS cache.
The server couldn’t process the request because it lacked valid authentication credentials. The response must include a WWW-authenticate header field containing information on what to do if the user insists on accessing the password-protected resource.
402 Payment Required
This status code is for future use since the plan for using it with digital payment systems has fallen through. It indicates that the server refused to process the request because the user hasn’t made the required payment.
As there’s no standard rule to using it, many eCommerce websites use 402 Payment Required to create paywalls.
403 Forbidden has a similar purpose to 401 Unauthorized. That said, 403 indicates a refusal to authorize the request even with valid login credentials. Therefore, the user shouldn’t repeat the request.
The most common cause is insufficient permissions – for example, a user with a Writer role trying to access pages for Editors only.
We’ve written an article dedicated to helping users solve the 403 Forbidden status code.
404 Not Found
This status code informs the user that the server failed to locate the requested resource. However, it doesn’t contain information about whether the resource is missing temporarily or permanently.
The error message varies depending on the browser. Many websites like Hostinger also customize it to include a brief explanation about the error.
Some of the most common causes include a mistyped URL, caching problems, and incomplete domain propagation.
Visit our article on the 404 status code for more information on how to fix it.
405 Method Not Allowed
The origin server supports the HTTP request method, but the target resource doesn’t. The status code comes with an Allow header containing a list of the supported methods to choose from to access the resource.
406 Not Acceptable
The server’s response conflicts with the values defined in the Accept headers. That said, this status code is rarely used as servers tend to present the resource as it is regardless of the Accept headers’ value.
Similar to 405 Method Not Allowed, this status code usually comes with a list of supported entity characteristics to choose from.
407 Proxy Authentication Required
This client error status code appears when using a proxy server. It indicates that the user must first provide valid authentication credentials for the proxy server.
The status code comes with a Proxy-Authenticate header field containing instructions for authorizing the proxy server.
408 Request Timeout
The origin server may send this response code if a user doesn’t submit a request within the timeout period, deeming the connection unused.
Since this error is mostly caused by slow internet connections or incorrect URLs, the user can repeat the request at a different time without changing the content.
The server can’t complete the request because of a conflict with the target resource. This error may be caused by multiple users updating a file simultaneously or the newly uploaded file being older than the one stored on the server, creating version conflicts.
This status code is similar to 404 Not Found. The difference is that 410 indicates that the resource is missing from the origin server permanently and there’s no redirection.
411 Length Required
A server may send this response code when the request doesn’t define the Content-Length header required by the resource.
412 Precondition Failed
413 Request Entity Too Large
The server refuses to process a request because the request entity was too large for the server to process. It usually happens when a user tries to upload a file that exceeds the server’s size limit.
We recommend checking our article on 413 Request Entity Too Large for the steps to fix it.
414 URI Too Long
The server refused to process a request because the request URI was too long. It usually occurs when a client converts a POST request to a GET request incorrectly, the redirected URI prefix points to its own suffix, or a client uses fixed-size buffers to attack the server.
415 Unsupported Media Type
The server doesn’t support the media type included in the client’s request entity.
416 Range Not Satisfiable
The server can’t return a portion of the file requested by the client. It might be because the file doesn’t contain the requested ranges or the range request-header field carries an incorrect value.
417 Expectation Failed
The server can’t fulfill the requirements stated in the Expect request-header field.
419 Authentication Timeout
This non-standard status code occurs when previously valid authentication expires. It serves as an alternative to the 401 Unauthorized status code.
422 Unprocessable Entity
The server cannot complete the request because it contains semantic errors. The request fails due to a wrong variable, operator, or incorrect order of operation, rendering it meaningless.
The server can’t access the resource because it is locked. This error code is part of the WebDAV specification, specifically its locking mechanism.
424 Failed Dependency
This error code appears when a request fails due to being dependent on another request that has failed. Like 423 Locked, it’s also part of the WebDAV specification, which is an extension of HTTP.
425 Unordered Collection
The server refuses to process a request that might be replayed, preventing hackers from launching replay attacks.
426 Upgrade Required
The client is required to upgrade to a different protocol. The server’s response must come with an Upgrade message header field containing the requested protocol.
428 Precondition Required
The origin server requires the response to be conditional, which means that the request must have a precondition header. If the said header doesn’t match the server-side state, the server will send back a 412 status code.
429 Too Many Requests
The user has sent too many requests within a certain time frame. The server may include a Retry-After header containing a time interval after which the user should repeat the request.
431 Request Header Fields Too Large
The server refuses to process the request due to one or multiple HTTP header fields being too large. This response code generally indicates the problematic header fields in its message body, allowing the user to fix the issue. Read our tutorial on how to fix error 431.
440 Login Time-out
The client must log in again because their session has expired.
444 No Response
This non-standard status code only appears in NGINX log files, instructing the server to disconnect without sending a response to the client. It’s generally used to deny malicious requests.
449 Retry With
The server can’t process the request because the client hasn’t provided the required information.
450 Blocked By Windows Parental Controls
A Microsoft extension code that’s triggered when Windows Parental Controls blocks access to a particular web page.
451 Unavailable For Legal Reasons
The server can’t access the resource due to legal restrictions implemented by the client’s government.
495 SSL Certificate Error
The NGINX server has failed to verify the SSL client certificate, deeming it invalid.
496 No Certificate
This NGINX response code appears when a client doesn’t present the required SSL certificate.
497 HTTP to HTTPS
This NGINX response code is an extension of 400 Bad Request. It occurs when a client sends an HTTP request through an HTTPS port.
499 Client Closed Request
The client has closed the request before receiving a response from the NGINX server.
500 Server Error
The 500 status codes indicate a failed request due to a server-side error. Servers generally send 500 status codes when they cannot find a more suitable response.
500 Internal Server Error
The server is unable to fulfill the request due to an unexpected condition.
In WordPress, a bad plugin, theme or a corrupted .htaccess file may trigger this error. Other possible causes include an insufficient PHP limit and incompatible PHP versions.
We’ve got an article that covers the 500 status code thoroughly, including how to fix it.
501 Not Implemented
The server doesn’t recognize the request method or functionality required to fulfill the request.
This response code is the opposite of the 405 Method Not Allowed, which indicates that the server recognizes the required functionality but chooses not to support it.
502 Bad Gateway
The server, serving as a proxy, cannot fulfill the client’s request because it has received an invalid response from the upstream server.
This response code may occur when a domain name hasn’t fully propagated after moving to a new host. In some cases, a firewall might deem the request an attack on the origin server due to an incorrect configuration.
Other possible causes include an origin server overload and browser errors due to outdated browser versions or corrupted files in the browser cache.
We have an article that covers the 502 status code, including the methods to fix it.
503 Service Unavailable
The server cannot handle the request because it has run out of resources or is down for maintenance.
Servers generally send this response code due to temporary issues. The response comes with the Retry-After request-header field containing the estimated recovery time.
Check out our article on the 503 status code for more information on it and how to deal with it.
504 Gateway Timeout
The proxy server hasn’t received a timely response required for fulfilling the request from the upstream server.
Some of the most common causes include a faulty firewall configuration, unresolvable domains, server overload, connectivity issues, limited PHP workers, and DNS issues.
For more information, read our article on the 504 status code.
505 HTTP Version Not Supported
The server doesn’t support the HTTP protocol version used in the request. Using an outdated web browser usually triggers this response code.
The response generally contains information about the protocols supported by the server.
506 Variant Also Negotiates
The server has conducted the Transparent Content Negotiation protocol, prompting the user agent to choose one of the supported variants to serve the resource.
In some cases, this response code indicates a circular reference, which means that the chosen variant resource is configured to engage in content negotiation. As a result, the process has no proper end.
507 Insufficient Storage
This WebDAV response code signals the lack of storage space needed to store the representation, preventing the server from completing the request.
508 Loop Detected
This WebDAV response code indicates that the server has encountered an infinite loop when processing the request.
Another version of the 508 error message is called “Resource limit reached”. In this case, the server cannot fulfill the request because it has exceeded the resource limit implemented by the web host.
509 Bandwidth Limit Exceeded
This response code usually appears on websites running on a shared hosting plan. It indicates that the server has exceeded the bandwidth limit due to high site traffic volumes.
510 Not Extended
The client isn’t using any of the extensions supported by the server. The response generally includes all the information required to issue the required extension.
511 Network Authentication Required
This error message is sent by intercepting proxies that control access to the network. The client must be authenticated before the network can grant access.
It commonly occurs when trying to access public networks. Users must agree to Terms of Service to gain access.
520 Web Server Returned an Unknown Error
This Cloudflare response code signals that the origin server returned an empty or unknown response to the reverse proxy. Read our guide on how to fix 520 error.
521 Web Server is Down
This Cloudflare response code appears when the origin server cannot connect to the reverse proxy. It might be because the origin web server is blocking connections from specific Cloudflare IP addresses.
522 Connection Timed Out
Cloudflare couldn’t reach the origin server to establish a Transmission Control Protocol (TCP) connection, resulting in a timeout. DNS misconfiguration is the most common cause of this issue.
523 Origin is Unreachable
Cloudflare couldn’t reach the origin web server. This is caused by incorrect or missing DNS records or settings of the server.
524 A Timeout Occurred
Cloudflare has managed to establish a TCP connection to the origin server. However, the reverse proxy hasn’t received an HTTP response within a certain time frame, resulting in a timeout.
525 SSL Handshake Failed
Cloudflare couldn’t execute an SSL or TLS handshake with the origin web server. The website might have an improperly configured SSL certificate, preventing the client and server from establishing a secure connection.
599 Network Connect Timeout Error
Some HTTP proxies send this response code when a network connection timeout occurs to the client in front of the proxy.
HTTP Status Codes and SEO
Search engines use web crawlers to index the content of websites to rank them on search engine results pages. When crawling through websites, web crawlers register all HTTP status codes they encounter to determine the site’s health and each web page’s ranking.
For this reason, HTTP status codes play a significant role in a site’s SEO.
The best possible scenario would be to have all of your web pages return a 200 status code, signaling that all website resources are accessible.
While 300 status codes aren’t necessarily harmful to SEO, you want to keep their number at a minimum. This HTTP status code class informs search engines whether a page redirect is temporary or permanent.
400 and 500 status codes are the ones that can harm your website’s SEO. These response code classes prevent crawlers from indexing web pages, leading to search engines’ algorithms finding your site to be of low quality.
Checking a website’s HTTP status codes periodically is the best way to preserve its SEO. There are two ways to monitor your website’s HTTP status codes ‒ manually or by using a URL inspection tool.
The manual method is best for checking individual web pages as it’s done on a page-by-page basis. You can do it using the browser’s built-in tools.
Here’s how to check a web page’s HTTP response code using Chrome DevTools:
- After opening the desired web page on Chrome, click the three dots on the top menu bar and navigate to More tools -> Developer tools.
- Open the Network panel at the top. Select the double arrow symbol to expand the options if you don’t see it.
- Select one of the HTTP requests shown on the table. The HTTP status code will appear on the Headers tab. The following screenshot shows that the Hostinger homepage returned a 200 status code.
If you’re running a multi-level website, it’ll be easier to use an HTTP header checker. HttpStatus.io, for example, supports bulk checking of up to 100 URLs.
That said, we recommend using the tool provided by Google Search Console as it has URL Inspection and Index Coverage Report features that check a website’s overall health.
First, let’s add your website to Google Search Console:
- Go to Google Search Console’s homepage and click Start now.
- Enter your domain name and click Continue.
- Copy the verification code generated by the platform. Leave the tab open.
- Navigate to your domain name registrar’s DNS management console. Hostinger users who register their domain with us can access it via the DNS Zone Editor from hPanel.
- Add a new record using the verification code as follows:
- Type ‒ TXT
- Name ‒ @ (leave the default value as it is)
- TXT value ‒ insert the Google Search Console verification code
- TTL ‒ 14400
- Click Add Record. If the process is successful, you should see a confirmation message.
- Wait until the DNS records are fully propagated. Then, go back to the Google Search Console tab and select Verify.
- If you see the following message, you’ve successfully added the website to the platform. Click Go to Property to access the dashboard.
Use the URL inspection tool to check individual web pages or open the Coverage tab to see your website’s general health.
Keep in mind that Google Search Console only works for tracking websites registered in Google’s index.
Knowing how to read HTTP status codes is essential for internet users, particularly webmasters. Each status code communicates the state of a client’s request, informing the user whether the server can retrieve the requested resource or not.
As HTTP status codes significantly impact SEO, it’s best to monitor them regularly using an HTTP header checker. Ideally, all of your web pages should return the 200 status code, indicating successful HTTP requests across the site.
We hope this article has helped you understand HTTP status codes better so you can respond to each of them appropriately. Good luck.
HTTP Status Codes FAQ
Will I See an HTTP Status Code Every Time a Website Error Occurs?
An HTTP status code will appear when a website encounters an error. The only exception would be if there’s an interceptor placed between the server and the browser or the console.clear() method is used and triggered in the right environment to clear the console output.
How to Prevent Website Errors?
The best way to prevent website errors is to analyze user flows via analytics and in-person observation and anticipate every possible error that might occur. Enforcing constraints to user input and preceding irreversible operations with a confirmation dialog can also help reduce error risks.