HTTP status codes are 3-digit numbers returned by a web server in response to every browser request, indicating whether a specific URL was successfully delivered, redirected, or encountered an error. Whether you are a website owner troubleshooting broken pages or an SEO professional who runs an SEO agency managing crawl budget, understanding HTTP status codes is critical to maintaining a healthy, high-ranking website in 2026.
Defined in RFC 9110 (the current HTTP Semantics standard) and catalogued by the IANA HTTP Status Code Registry, these codes govern how clients and servers communicate across the web. Every time a visitor loads a page, a bot crawls your site, or an API call is made, an HTTP status code is returned — whether you see it or not.
In this guide, you will find a complete reference to all standard HTTP status codes, their SEO implications, how to check them, how to fix the most common errors, and which tools to use for ongoing monitoring. If you want to improve the user experience on your site and protect your search rankings, start here.
What Are HTTP Status Codes?
HTTP stands for Hypertext Transfer Protocol — the foundational communication system the World Wide Web uses to transfer data between web servers and browsers. Every time your browser requests a page, the server responds with an HTTP status code before delivering (or refusing to deliver) the content.
The status code is a 3-digit integer. The first digit defines the class of response, while the remaining two digits specify the exact status within that class. For example, 200 means the request was successful, and the content was delivered, while 404 means the server could not find the requested resource.
HTTP status codes serve two critical audiences simultaneously:
- Users and browsers — They determine what a visitor sees: a page, a redirect, an error message, or a login prompt.
- Search engine crawlers (like Googlebot) — They tell crawlers whether a page should be indexed, removed, or re-crawled, directly influencing your SEO performance.
For website owners, regularly monitoring status codes can reveal issues like broken links, server problems, redirect chains, and crawl errors that silently damage both user experience and search rankings. Catching and fixing these issues is a foundational part of any technical SEO audit.
What Are the Different HTTP Status Code Classes?
HTTP status codes are grouped into five classes, each identified by the first digit. Understanding these classes instantly tells you the nature of any response — success, redirect, client error, or server error — without needing to memorise every individual code.
| HTTP Status Code Categories | Meaning |
|---|---|
| 1xx Informational | 1xx status codes indicate an interim response. This class of statuses doesn’t usually indicate errors but provides information related to the request. |
| 2xx Success | The 2xx class encompasses status codes for successful requests. This indicates the action requested by the browser worked properly. |
| 3xx Redirection | A 3xx status code indicates the client browser must take some additional action to complete the request. This usually means redirecting to a different URL. |
| 4xx Client Error | A 4xx status code indicates an error on the client side prevented the request from being fulfilled. |
| 5xx Server Error | The 5xx class indicates the server failed to fulfill what appears to be a valid request. |
The Role of HTTP Status Codes in Search Engine Optimization (SEO)
HTTP status codes are one of the most direct technical signals your website sends to search engines. When Googlebot crawls your site, it reads every status code it encounters and uses that information to decide whether to index a page, pass link equity, remove a URL from its index, or revisit a URL in the future. Understanding this relationship is essential for protecting and improving your search rankings.
How Status Codes Affect Crawl Budget
Crawl budget refers to the number of pages Googlebot will crawl on your site within a given timeframe. Every time Googlebot encounters a 4xx or 5xx error, it wastes crawl budget on a URL that provides no indexable content. For large websites, a high volume of error pages means your most important pages may be crawled less frequently — or not at all.
- 4xx errors (particularly 404s) signal to Google that sections of your site may lack value for users, potentially reducing crawl frequency across the domain.
- 5xx errors are treated as temporary but serious. If Googlebot repeatedly encounters 500-series errors, it may reduce crawl rate and, in severe cases, temporarily deindex affected pages.
- Redirect chains (multiple consecutive redirects) also burn crawl budget unnecessarily. Keeping redirect paths to a single hop is a best practice.
How Redirects Pass (or Lose) Link Equity
Not all redirects are equal from an SEO perspective. 301 Moved Permanently redirects pass the vast majority of PageRank (link equity) to the destination URL, making them the correct choice for permanent URL changes, HTTPS migrations, and domain consolidations. 302 temporary redirects, by contrast, are intended for short-term use and do not permanently transfer link equity — meaning the original URL retains its ranking signals rather than passing them on.
Excessive use of 302 redirects or meta refresh redirects, especially chained together, can raise spam signals for search engines. 301 redirects are fine and widely used in SEO — just keep chains short and ensure redirects point directly to the final destination URL.
Soft 404s: A Hidden SEO Risk
A soft 404 occurs when a page returns a 200 OK status code to the server but displays a “page not found” or low-value message to the user. Google’s crawlers are designed to detect soft 404s and may treat these pages as if they were genuine 404 errors, removing them from the index. Ensure that pages with no real content return a proper 404 or 410 status rather than a misleading 200.
503 and Planned Maintenance
If you need to take your site offline for maintenance, returning a proper 503 Service Unavailable code with a Retry-After header is the SEO-safe approach. This signals to Googlebot that the downtime is temporary and it should return later, rather than interpreting the unavailability as a permanent problem and deindexing your pages.
To maximise SEO, aim for robust 200-level responses across all important pages. Checking for and resolving non-200 status codes — using the tools covered later in this guide — should be part of every Google crawling and indexing review and technical SEO audit.
How to Check HTTP Status Codes (4 Methods)
There are several reliable ways to check the HTTP status code of any URL — from browser-based tools to command-line utilities. Here are the four most practical methods for website owners and SEO professionals.
Method 1: Google Search Console (Recommended for Site-Wide Monitoring)
Google Search Console provides the most SEO-relevant view of your site’s HTTP status codes, showing you exactly how Googlebot sees your pages. Here is the step-by-step process:
- Login to Google Search Console and navigate to the site you want to analyze.
- Click on the “Coverage” button (now called Pages in the updated interface) that you will find in the left sidebar.
- Select “URL Inspection” from the drop-down menu.
- In the box, enter the specific URL you want to check status codes for. You can also click the icon next to the box to select a previously crawled URL.
- Click “Run inspection“.
- The “Inspection results” section will populate with details on the page. The status code is shown under the “Last crawled” entry.
- Scan for any status codes other than 2xx. 400 and 500 errors indicate issues that should be addressed.
- Click the “More info” link to see a full timeline of status codes recorded for that page. This helps spot recurring errors.
- Repeat steps 4–8 for any other important pages you want to monitor status codes for. Identifying and troubleshooting errors will improve SEO and UX.
- Once done inspecting pages, click “Back to list” to return to the full coverage report. Review crawl stats and errors.
Method 2: Chrome DevTools (Quick Single-Page Check)
- Navigate to the page you want to check in Google Chrome.
- Press F12 (Windows/Linux) or Cmd + Option + I (Mac) to open DevTools.
- Click the Network tab, then refresh the page (Ctrl+R or Cmd+R).
- Click the first row (the main document request). The Status column shows the HTTP status code returned.
Method 3: curl Command (For Developers and Technical Users)
Open your terminal and run the following command, replacing the URL with your target page:
curl -o /dev/null -s -w "%{http_code}" https://www.example.com/your-page/This returns the HTTP status code (e.g., 200, 301, 404) without downloading the full page. Add -L to follow redirects and see the final destination code.
Method 4: Online Status Code Checker Tools
For quick checks without any setup, several free online tools let you enter any URL and instantly see its HTTP status code, redirect chain, and response headers. These are particularly useful for spot-checking competitor pages or verifying redirects after a site migration.
A Complete List of All 63 HTTP Status Codes Explained in Detail
In this section, we will explore all 63 standard HTTP status codes so you can talk to your server like a pro. You’ll learn what each code means, when it is used, and most importantly, what to do when one shows up on your site. Here is a complete list of HTTP Status Codes:
| HTTP Status Codes | HTTP Status Code Messages |
| 1XX (Informational) HTTP Status Codes | |
| 100 | Continue |
| 101 | Switching Protocols |
| 102 | Processing |
| 103 | Early Hints |
| 2XX (Success) HTTP Status Codes | |
| 200 | OK |
| 201 | Created |
| 202 | Accepted |
| 203 | Non-Authoritative Information |
| 204 | No Content |
| 205 | Reset Content |
| 206 | Partial Content |
| 207 | Multi-Status |
| 208 | Already Reported |
| 226 | IM Used |
| 3XX (Redirection) HTTP Status Codes | |
| 300 | Multiple Choices |
| 301 | Moved Permanently |
| 302 | Found (Previously: Moved Temporarily) |
| 303 | See Other |
| 304 | Not Modified |
| 305 | (Unused) Previously: Use Proxy |
| 306 | (Unused) Previously: Switch Proxy |
| 307 | Temporary Redirect |
| 308 | Permanent Redirect |
| 4XX (Client Error) HTTP Status Codes | |
| 400 | Bad Request |
| 401 | Unauthorized |
| 402 | Payment Required |
| 403 | Forbidden |
| 404 | Not Found |
| 405 | Method Not Allowed |
| 406 | Not Acceptable |
| 407 | Proxy Authentication Required |
| 408 | Request Timeout |
| 409 | Conflict |
| 410 | Gone |
| 411 | Length Required |
| 412 | Precondition Failed |
| 413 | Payload Too Large |
| 414 | URI Too Long |
| 415 | Unsupported Media Type |
| 416 | Range Not Satisfiable |
| 417 | Expectation Failed |
| 418 | Previously: I’m a teapot |
| 421 | Misdirected Request |
| 422 | Unprocessable Entity |
| 423 | Locked |
| 424 | Failed Dependency |
| 425 | Too Early |
| 426 | Upgrade Required |
| 428 | Precondition Required |
| 429 | Too Many Requests |
| 431 | Request Header Fields Too Large |
| 451 | Unavailable For Legal Reasons |
| 5XX (Server Error) HTTP Status Codes | |
| 500 | Internal Server Error |
| 501 | Not Implemented |
| 502 | Bad Gateway |
| 503 | Service Unavailable |
| 504 | Gateway Timeout |
| 505 | HTTP Version Not Supported |
| 506 | Variant Also Negotiates |
| 507 | Insufficient Storage |
| 508 | Loop Detected |
| 510 | Not Extended |
| 511 | Network Authentication Required |
1xx HTTP Status Codes (Informational)
The 1xx class provides provisional status information during initial request processing. These are interim responses — not errors — and are rarely seen directly by end users because browsers handle them automatically in the background. They are most relevant to developers working with WebSocket upgrades, large file uploads, and HTTP/2 server push scenarios.
1. 100 Continue
The 100 Continue status code indicates that everything is okay so far and the client should continue sending the remainder of the request. This is used when the initial part of the request has been received by the server, but the full request isn’t complete yet.
For example, when uploading a large file, the client may send the headers first, then the server will respond with 100 Continue before receiving the actual file contents.
If you see this status when requesting a page, it simply means the server got the first part of the request and is ready for the rest. Just allow the request to complete as normal. The full response will come after the entire request has been received.
2. 101 Switching Protocols
The 101 Switching Protocols code is sent when the server is changing communication protocols at the client’s request.
For example, switching from HTTP protocol to WebSockets.
The client sends an Upgrade header indicating the protocol it wishes to switch to, and if the server supports it, it will send back 101 and change accordingly.
If you receive 101, your client requested a protocol change supported by the server, so no action is needed. Communication will continue using the new protocol. This allows clients to establish more interactive, real-time connections when needed.
3. 102 Processing
The 102 Processing status indicates the server has received the initial request but the processing is still ongoing. No response is available yet. This prevents the client from timing out while waiting for the response.
When encountered, 102 means the request is being processed but not ready yet. The client should continue waiting until the full response is returned, which may take some time for long operations. No further action is required — just allow processing to complete.
4. 103 Early Hints
The 103 Early Hints status is used when the server wants to provide some early tips to the client on how to preload or render content ahead of the full response. This may include routes to early-fetch important links the client will need or details on how to process the eventual content.
If 103 shows up, the server has hints on optimising page loading before the full HTML is sent. Look for Link headers directing prefetch resources and other details that can inform page rendering. This status helps improve perceived performance and is increasingly important in HTTP/3 environments. You can leverage the early hints provided.
2xx HTTP Status Codes (Successful)
The 2xx series indicates success — the server received, understood, and accepted the request. From an SEO perspective, you want your important pages returning 200 OK consistently. Other 2xx codes are essential in REST API development, signalling specific outcomes for POST, PUT, DELETE, and PATCH operations.
1. 200 OK
It is the standard response HTTP status code for successful HTTP requests. The requested resource has been found and sent back in the response. You need to do nothing. This is the most common code you want to see. From an SEO standpoint, consistent 200 responses across your important pages tell Googlebot that your content is accessible, stable, and worth indexing.
2. 201 Created
This HTTP status code means the request is successful and a new resource has been created. This is sent back after POST requests that create something new like a user account or blog post. It confirms the item was created. In REST API design, 201 is the correct response for a successful POST request — not 200 OK. The Location response header typically points to the URL of the newly created resource.
3. 202 Accepted
This code means the request was accepted and will be processed asynchronously in the background. The client should continue to poll the server periodically for status updates. This is commonly used in API workflows where long-running tasks — such as generating a report or processing a large file — are queued rather than executed immediately.
4. 203 Non-Authoritative Information
This status means the returned metadata is from a third-party copy instead of the original server. It is useful for load balancing and caching proxy scenarios where intermediary servers modify response headers.
5. 204 No Content
The server processed the request but has no content to return in the body. It is often sent after DELETE or PUT requests in REST APIs where the action was successful but there is no new data to display. The browser should not navigate away from the current page when it receives a 204.
6. 205 Reset Content
This code tells the client to reset or refresh the current web page associated with the request. It is typically used after a POST request to instruct the user’s browser to clear an input form, ready for new data entry.
7. 206 Partial Content
This response contains partial content per a range request by the client for part of a resource. You will encounter 206 when streaming video or audio, resuming interrupted file downloads, or fetching a specific byte range of a large document using the Range request header.
8. 207 Multi-Status
It is used for batch and multi-status requests and indicates multiple status codes are being returned for different parts of the response. Commonly used in WebDAV (Web Distributed Authoring and Versioning) environments.
9. 208 Already Reported
This status code is used in WebDAV to avoid repeating the same resource binding in response to multiple requests. It signals that the members of a DAV binding have already been enumerated in a prior part of a multi-status response.
10. 226 IM Used
When this code appears, it means the server has fulfilled a GET request using the Instance Manipulation (IM) Header protocol to send a delta encoding of the response body, optimising bandwidth by only transmitting what has changed since the last cached response.
3xx HTTP Status Codes (Redirection)
The 3xx class indicates the client must take additional action to complete their request — most commonly, following a redirect to a different URL. Redirect codes have significant SEO implications because they determine how PageRank (link equity) is transferred between URLs and how Googlebot updates its index. Understanding the difference between each 3xx code is critical for site migrations, URL restructuring, HTTPS upgrades, and managing content that has moved.
301 vs 302 vs 307 vs 308 — Which Redirect Should You Use?
The four most commonly used redirect codes differ in two key dimensions: permanence (is the move permanent or temporary?) and method preservation (does the redirect preserve the original HTTP method, such as POST?).
| Code | Name | Permanent? | Preserves Method? | Passes Link Equity? | Best Used For |
|---|---|---|---|---|---|
| 301 | Moved Permanently | Yes | No (POST may become GET) | Yes | Permanent URL changes, HTTPS migration, domain consolidation |
| 302 | Found (Temporary) | No | No (POST may become GET) | No (equity stays at origin) | A/B testing, temporary campaigns, short-term content moves |
| 307 | Temporary Redirect | No | Yes | No (equity stays at origin) | Temporary redirects where POST method must be preserved |
| 308 | Permanent Redirect | Yes | Yes | Yes | Permanent redirects where POST method must be preserved |
SEO rule of thumb: Use 301 for permanent moves (it is the most widely recognised and supported redirect by all major search engines). Use 302 only for genuinely temporary situations. Avoid redirect chains — each additional hop in a chain dilutes link equity and wastes crawl budget. Always redirect directly to the final destination URL.
1. 300 Multiple Choices
The 300 Multiple Choices status indicates there are several options available for the requested resource. The response contains a list of links to the various possibilities in the form of URI references. The user-agent or client may then select one of the references and resubmit the request to that URI.
This code allows the server to provide links to different formats or language versions of the content, for example. The client can decide which one fits its needs. When receiving 300, the response body should contain the various options to redirect to. In practice, this code is rarely used — most implementations use content negotiation headers instead.
2. 301 Moved Permanently
This is one of the most important redirect codes in SEO. The 301 code indicates the resource requested has been permanently moved to a new URI. The Location response header will contain the new permanent URL to redirect to. All future requests should go to this new URL.
When you get a 301, update any links on your site pointing to the old URL. Search engines will also update their indexes to point to the new 301 location, and link equity (PageRank) is passed to the new URL. It is like telling someone that your phone number has changed and they should start calling your new number — permanently.
3. 302 Found (Previously: Moved Temporarily)
The 302 HTTP status means the requested resource is temporarily located under a different URI. The temporary new location is provided in the Location header of the response. This is similar to 301 but specifies this redirect is only temporary, not permanent.
When encountering 302, you can issue the request to the temporary redirect URL in Location. You don’t need to update links or anything permanent. The resource may move back later. From an SEO perspective, link equity is NOT transferred to the destination — it remains with the original URL. Only use 302 when the redirect is genuinely temporary.
4. 303 See Other
A 303 response indicates the resource can be found under a different URI using the GET HTTP method. This informs the client to make a new GET request to the URI specified in the Location response header instead of the original request that generated the 303.
This is mainly used when a POST creates a new resource, and the response tells you to now go GET the URL of the new resource to view it — preventing duplicate form submissions on browser refresh. You will need to fetch the Location header and make a new GET request.
5. 304 Not Modified
This response code means the client performed a conditional GET request but the document has not changed since it was last retrieved. Based on the If-Modified-Since request header, the server determined the resource has not been modified. In this case, the cached copy can be used by the client.
When you get 304, it means your cached local copy is still up to date. You don’t need to re-download the content. The resource has not changed so your currently cached version can continue being used as is. This is a performance-positive status code — it reduces bandwidth and speeds up page loads.
6. 305 Use Proxy (Deprecated)
The 305 status was defined originally to indicate the requested resource must be accessed through a proxy located at the proxy URL given by the Location response header. However, this status code is deprecated due to security concerns of exposing internal proxies.
If you receive 305, that indicates an obsolete attempt to redirect through an internal proxy. It should not be used or relied upon. Modern web standards forbid this behaviour so you can disregard this status.
7. 306 Switch Proxy (Deprecated)
The 306 status was a prior way to indicate subsequent requests should use a different proxy server than the one behind the current response. It was intended for switching to a more appropriate upstream proxy. However, this status was deprecated after HTTP 1.1 due to inherent security risks in exposing proxy details.
If this deprecated status appears, you should ignore it and not try to switch proxies. The 306 behaviour is no longer supported or recommended due to the aforementioned security issues. Any proxy changes should be configured directly within your HTTP client instead.
8. 307 Temporary Redirect
This status indicates the requested resource is temporarily located under a different URI, provided in the Location header — similar to a 302. The key difference is that a 307 preserves the original HTTP method used on the initial request when redirecting, whereas a 302 may convert a POST into a GET.
A 307 redirect means the resource has temporarily moved like a 302 but when reissuing the redirect request, you should use the same HTTP method as the original call. Use 307 when you need a temporary redirect for a POST request to avoid unintentional method changes.
9. 308 Permanent Redirect
The 308 status is similar to 301 in indicating the original resource URL is now permanently redirected to a new URL provided in Location. The key difference is that 308 preserves the original request method when redirecting, unlike a 301 which may allow POST to be converted to GET.
When receiving 308, you should update any links pointing to the old URL to the new permanent URL provided in Location, just like a 301. Unlike 301 however, if your original request is POST, you will POST to the 308 URL too. From an SEO standpoint, 308 passes link equity the same way a 301 does.
4xx HTTP Status Codes (Client Error)
The 4xx codes indicate an error on the client side — a mistyped URL, insufficient permissions, an invalid request, or a resource that no longer exists. From an SEO perspective, a high volume of 4xx errors wastes crawl budget and signals poor site maintenance to search engines. Identifying and resolving 4xx errors through Google Search Console’s Coverage report is a foundational technical SEO task.
1. 400 Bad Request
The 400 status indicates the server cannot understand the request due to invalid syntax. It is a generic client-side error response. It could mean the request headers, body, or routing are poorly formed and the server has no idea how to parse the request.
Some common causes are invalid request message framing, incorrectly typing the endpoint URL, missing required headers or parameters, sending invalid JSON, and CORS issues. 400 errors mean you need to fix your request syntax before trying again. Double-check everything is structured correctly.
2. 401 Unauthorized
A 401 error means the request requires user authentication. This indicates the client either did not provide authentication credentials, or the credentials provided are invalid and the access attempt failed.
When getting 401, you will need to prompt the user to enter valid credentials in the form of cookies, OAuth tokens, or basic auth. Note the difference between 401 and 403: a 401 means authentication is missing or failed, while 403 means the server knows who you are but still refuses access. For SEO, pages returning 401 will not be indexed by Googlebot.
3. 402 Payment Required
This code is reserved for future use. The intention is to use it one day to request payment or monetary authorisation to access a resource. However, this status is not widely implemented yet. You may see it used on proprietary APIs or services — particularly subscription paywalls and SaaS platforms — but general web serving does not leverage it.
4. 403 Forbidden
A 403 Forbidden error code means the server understood the request but refuses to authorise it. This is different from 401. With a 403 error, the request is well-formed but the client is not allowed to access the resource, regardless of auth credentials.
403 can indicate an anonymous user trying to access pages requiring login, or an authenticated user lacking the proper privileges and permissions. From an SEO standpoint, if Googlebot receives 403 on pages you want indexed, check your robots.txt rules and server-level IP blocking configurations — you may be inadvertently blocking crawlers.
5. 404 Not Found
The most well-known error code: 404 indicates the server cannot find the requested resource. This occurs when the URL path does not match any existing content — from mistyping the URL, following a broken link, or requesting a page that was deleted or moved without a redirect.
Double-check the URL for any typos when getting a 404. If it looks valid, the resource was likely moved, deleted, or does not exist. For website owners, Google will eventually drop URLs that consistently return 404 from its index. Monitor 404s in the Google Search Console Coverage report and address them by either restoring the page, implementing a 301 redirect to a relevant alternative, or removing internal links pointing to the dead URL.
6. 405 Method Not Allowed
A 405 error means the HTTP method used on the request — such as GET, POST, DELETE — is not supported for this resource. For instance, making a POST request to an endpoint that only accepts GET requests.
The 405 HTTP status code requires checking both the endpoint URI and the HTTP method being used. Make sure the API or web server supports that method for the given resource. The route may exist but the developer has not enabled that operation. The server’s response should include an Allow header listing the permitted methods.
7. 406 Not Acceptable
This response indicates the resource is present but cannot generate a response meeting the requirements sent by the client in Accept* headers. Typically, this means the server cannot return the content in a requested format like JSON or a specific language.
406 errors mean the resource exists but cannot be served in the client’s preferred format. Check the Accept headers being sent to ensure the API can return responses in those content types.
8. 407 Proxy Authentication Required
A 407 status indicates the client must authenticate with a proxy server before the request can proceed. Similar to 401 but specifically applied when sent from a proxy rather than the origin server.
To resolve 407 errors, the client will need to provide valid authentication credentials in the Proxy-Authorization header to verify access through the proxy server first. This is common in corporate network environments where all outbound traffic passes through an authenticated proxy.
9. 408 Request Timeout
This error means the server timed out waiting for a request from the client. The client took too long to send the full request and the server gave up waiting. This could be due to network issues, client delays, or an extremely large request body.
408 timeouts indicate you should check your network connectivity and request timeout settings. Increase timeout thresholds as needed to accommodate larger requests, or reduce payload size if the request is taking too long to compose.
10. 409 Conflict
A 409 status indicates a conflict occurred when trying to update a resource. This commonly happens in REST APIs when the client tries to create a duplicate entry with a unique key constraint, or when attempting to update a resource that has been modified since it was last retrieved (a concurrency conflict).
409 errors mean the request cannot be completed due to conflicts with the current state of resources on the server. Adjust the request to resolve the conflict — for example, by using the latest version of the resource — and try again.
11. 410 Gone
The 410 status means the requested resource is permanently gone from the server, with no forwarding address. Unlike 404 (which may be temporary), 410 explicitly signals that the content has been deliberately and permanently removed.
For SEO, 410 is more explicit than 404 for communicating permanent removal to Googlebot. Google tends to deindex 410 pages faster than 404 pages. Use 410 when you have intentionally deleted content and want search engines to remove it from their index quickly. Remove any internal links pointing to 410 URLs.
12. 411 Length Required
This error indicates the server cannot process the request because the Content-Length request header is missing. The content length helps the server parse message framing, so requests without it will not be accepted.
To fix 411 errors, ensure the Content-Length header is set to the correct number of bytes in the message body. This header is required for the server to know when the body ends.
13. 412 Precondition Failed
The 412 status is sent when the client provides preconditions in headers like If-Match, which evaluate to false on the server side. This causes the request to fail validation before processing — commonly used in optimistic concurrency control to prevent accidental overwrites of updated resources.
Fixing 412 errors involves adjusting your conditional request headers to match the expected state on the server. Ensure entity tags (ETags) line up with the current server data before sending updates.
14. 413 Payload Too Large
A 413 error response indicates the request entity payload is too large for the server to process. This occurs most commonly when uploading files that exceed the server’s configured size limits.
To resolve 413 errors, check your server and API upload size limits. Reduce the request payload size by trimming file sizes, compressing images, or splitting large uploads into chunks. You may also be able to configure the server (e.g., client_max_body_size in Nginx or LimitRequestBody in Apache) to accept larger payloads.
15. 414 URI Too Long
The 414 status indicates the URL requested is longer than the server can process. This prevents arbitrarily long URLs that could cause denial of service issues or buffer overflow vulnerabilities.
414 errors occur when URL length exceeds the maximum configuration on the server or intermediary proxies. To resolve this, check your URL character length and shorten it as needed. Consider moving query string parameters into POST request bodies instead.
16. 415 Unsupported Media Type
This error means the media format of the request payload is not supported by the target resource on the server — for example, sending an image payload to an API expecting JSON. The Content-Type and Accept headers may not align.
Fixing 415 errors involves double-checking that the Content-Type of your request body matches what the server endpoint expects. Also verify that Accept types align with response formats the API provides. Adjust headers to use supported formats.
17. 416 Range Not Satisfiable
The 416 status response indicates the client requested a resource range that cannot be satisfied by the server. This typically happens when Range header values exceed the actual size of the target content — for example, requesting bytes 1000–2000 of a file that is only 500 bytes long.
To resolve, ensure the Range and Content-Range header values fall within the actual length of the resource being requested. If resuming a partial download, verify the correct file size and current byte position.
18. 417 Expectation Failed
This error means the server cannot meet the requirements requested by the Expect request header field. The server does not support the expectations requested.
To fix a 417, check the Expect header value and ensure the server supports that functionality. Remove or adjust to supported expectations like 100-continue if issues arise.
19. 418 I’m a Teapot
Originally defined as an April Fools’ joke in RFC 2324, this playful status indicates the server refuses to brew coffee because it is a teapot. Servers may send this code humorously. Despite its joke origins, 418 is now an officially registered status code in the IANA registry — it was retained after a campaign by developers to preserve it.
20. 419 Authentication Timeout
The 419 status refers to an authentication timeout expiring. This is a non-standard code most commonly used by the Laravel PHP framework to indicate that a CSRF (Cross-Site Request Forgery) token has expired, typically after a form has been left open too long.
Fixing 419 errors involves having users reauthenticate or refresh the page to obtain a new CSRF token. You may also be able to extend authentication token lifetimes on the server side.
21. 421 Misdirected Request
A 421 status means the server will not process the request because it does not match the security context of the intended recipient. This often occurs in HTTP/2 environments where a connection is reused but the server cannot serve the requested domain over that connection.
To resolve 421 errors, ensure requests are directed at the appropriate domain and server context. Double-check SSL/TLS certificate configurations and routing rules if this error appears in production.
22. 422 Unprocessable Entity
This response indicates the server understands the request syntax and content type, but cannot process the contained instructions due to semantic errors. Common in REST APIs when form validation fails — the request is correctly formatted JSON, but the field values violate business logic rules (e.g., an invalid email format, a negative price value, or a missing required field).
Fix 422 errors by checking all parameters and inputs match the API’s validation rules. The server’s error response body typically lists which specific fields failed and why.
23. 423 Locked
The 423 status means the resource being accessed is locked from concurrent requests. This prevents edit collisions in shared document environments, most commonly in WebDAV implementations.
When requests receive a 423, some other client holds a lock on the target resource. Your request will be blocked until the lock expires or is released. Consider using If-Match headers to detect and handle stale locks.
24. 424 Failed Dependency
A 424 error indicates that the request failed because it depended on another request or action that also failed. For example, in a batch WebDAV operation, if one sub-request fails and another request depends on its success, the dependent request returns 424.
To resolve 424 issues, identify and fix the failing dependent request first, then retry the overall operation.
25. 425 Too Early
This status means the server is unwilling to risk processing a request that might be replayed, related to TLS 1.3 early data (0-RTT). The server is protecting against replay attacks where an attacker captures and resends an early TLS data request.
Wait and replay the request after the TLS handshake has fully completed. This prevents duplicating requests while existing ones may still be in progress on the server side.
26. 426 Upgrade Required
The 426 error indicates the server refuses to perform the request under the client’s current protocol version but would be happy to do so under an upgraded version. The server sends an Upgrade header indicating the required protocol.
To resolve 426, the client should upgrade to a newer supported HTTP version when possible and reissue the request. This is becoming more common as servers enforce HTTP/2 or HTTP/3 for security and performance reasons.
27. 428 Precondition Required
This status indicates the server requires this request to contain a conditional header like If-Match. This is used to prevent the “lost update” problem — where a client reads a resource, another client modifies it, and then the first client overwrites the newer version without realising it has changed.
Fixing 428 errors involves adding precondition headers like If-Match with the current ETag value to validate request integrity before processing.
28. 429 Too Many Requests
A 429 means the client has sent too many requests in a given time period and has exceeded the server’s rate limit. This is used by APIs and web servers to prevent overload and abuse. The Retry-After header indicates when the client may safely retry.
Resolve 429 errors by reducing request volume and implementing exponential backoff — wait, retry after the time indicated in the Retry-After header, and gradually increase the wait time if 429s continue. For API integrations, cache responses where possible to reduce redundant calls. Do not flood servers with rapid retries, as this compounds the problem.
29. 431 Request Header Fields Too Large
This 431 error indicates the request header size exceeds the server’s configured limits. The headers are too large to be processed. This can occur when cookies have grown excessively large, when too many authentication tokens are included, or when custom header values are unusually lengthy.
To fix, reduce the number and size of headers where possible to fit within server allowances. Clear unnecessary cookies or reduce JWT token sizes. You may also be able to increase server header size limits in Nginx or Apache configuration.
30. 451 Unavailable For Legal Reasons
The 451 status — a nod to Ray Bradbury’s Fahrenheit 451 — is used when the server cannot provide access to the requested resource due to legal restrictions. This may occur due to government-mandated censorship, GDPR compliance requirements, DMCA takedown orders, or court injunctions.
Unfortunately, 451 errors mean the content you are requesting has been legally blocked and the server operator cannot serve it. The resource is inaccessible due to applicable laws or policies in the user’s jurisdiction. Website owners should document legal orders that require returning 451 responses.
5xx HTTP Status Codes (Server Error)
The 5xx codes signal a server-side problem that prevented fulfilling what appeared to be a valid request. Unlike 4xx errors (which are the client’s fault), 5xx errors are the server’s responsibility. From an SEO perspective, 5xx errors are particularly damaging — they can cause Googlebot to reduce crawl frequency, and pages that return persistent 5xx responses risk being temporarily removed from Google’s index. Monitoring 5xx errors in real-time through server logs and Google Search Console is essential for any production website.
1. 500 Internal Server Error
The 500 status code is a generic catch-all indicating an unexpected server-side error occurred that prevented the request from being fulfilled. No more specific 5xx code applies.
500 errors mean something unexpected went wrong on the server side. The application may have crashed, thrown an unhandled exception, become overloaded, or encountered an edge case the developers did not plan for. Common causes include PHP fatal errors, misconfigured .htaccess files, WordPress plugin conflicts, and database connection failures.
The issue will likely require a backend investigation to determine the root cause. Check server error logs immediately — these are found in /var/log/apache2/error.log or /var/log/nginx/error.log on Linux servers, or in your hosting control panel’s log viewer. Enable WordPress debug mode (WP_DEBUG) if running WordPress to surface specific error messages.
2. 501 Not Implemented
A 501 error shows the server does not support the HTTP method used in the request. For example, the API endpoint has not been implemented to handle POST requests, only GET. Unlike 405 (which means the method is known but not allowed for this resource), 501 means the server does not recognise or support the method at all.
501 errors mean the developers have not built out the endpoint code for that operation yet. Check the API documentation for supported methods. You may need to wait for the team to add support or use an alternative method.
3. 502 Bad Gateway
This status indicates the server was acting as a gateway or proxy and received an invalid or malformed response from the upstream origin server it was trying to access on your behalf.
502 errors mean the proxy server got a bad response when trying to fulfil the request upstream. Common causes include the origin server being down or overloaded, PHP-FPM crashing, an upstream Nginx/Apache process failing, or a Cloudflare connectivity issue to your origin server. Check if the origin server is down, review upstream service health, and ensure network connectivity between your proxy and origin is intact.
4. 503 Service Unavailable
A 503 status means the server is temporarily unable to handle the client’s request. This most often occurs when the application is down for maintenance or the server is overloaded and cannot accept new connections.
503 errors mean the client should wait and retry the request later. The application is not accessible right now but should recover. Most 503s are temporary if occasional. Frequent 503s indicate capacity issues requiring scaling or optimisation. SEO best practice: always include a Retry-After header when returning 503 during planned maintenance — this tells Googlebot exactly when to return and prevents it from treating the downtime as a permanent problem.
5. 504 Gateway Timeout
This error occurs when a server acting as a proxy or gateway did not receive a timely response from the upstream origin server. The upstream server received the request but took too long to send back a response, causing the gateway’s timeout threshold to be exceeded.
504 is the most frequently searched 5xx error. Here are the most common root causes and how to fix each one:
- PHP execution time limit: Increase
max_execution_timein your php.ini file (e.g., set to 120 or 300 seconds for heavy operations). - Nginx proxy timeout: Add or increase
proxy_read_timeout,proxy_connect_timeout, andproxy_send_timeoutvalues in your Nginx configuration. - Overloaded upstream server: Check CPU and memory usage on the origin server. Scale resources, optimise database queries, or implement caching (Redis, Memcached) to reduce response times.
- Slow database queries: Use EXPLAIN on slow queries, add appropriate indexes, and consider a query cache layer.
- Cloudflare timeout: Cloudflare imposes a 100-second timeout by default. If your origin consistently takes longer, optimise the origin response or use Cloudflare Workers to handle timeouts gracefully.
- Network disruption: Check for network issues between your CDN/proxy and origin server. Review firewall rules that may be blocking or throttling connections.
6. 505 HTTP Version Not Supported
The 505 status code indicates the HTTP protocol version used in the request is not supported by the server. For example, requesting HTTP/2 when the server only supports HTTP/1.1, or (increasingly rarely) using an outdated HTTP/1.0 client against a modern server.
To resolve 505 errors, check that both the client and server applications support the same major HTTP versions. Upgrade either as needed to align on a compatible protocol version. In 2026, HTTP/2 and HTTP/3 (QUIC) support is increasingly standard.
7. 506 Variant Also Negotiates
A 506 error shows the server detected an internal configuration error in transparent content negotiation — the process by which the server selects the best representation of a resource based on client preferences. The selected variant is itself configured to use content negotiation, creating a circular reference.
This is a non-standard status not frequently encountered in production. It generally indicates a server-side misconfiguration rather than a client problem. Review your server’s content negotiation configuration to resolve circular references.
8. 507 Insufficient Storage
The 507 status code indicates the server cannot store something from the request due to insufficient storage capacity. For example, if an upload would exceed the remaining free disk space on the server.
507 errors mean the server needs more storage allocated. Increase available disk space and clean up unused files and logs. Implement upload size limits and storage quotas at the application level to prevent recurrence.
9. 508 Loop Detected
This status indicates the server encountered an infinite loop while processing the request. This can occur with recursive API calls, infinite redirect chains, or circular DAV bindings.
508 errors mean the server aborted to avoid an infinite loop consuming all resources. Simplify request logic, implement recursion depth limits, and audit any redirect rules or DAV bindings for circular references.
10. 510 Not Extended
A 510 response indicates the server requires the client to provide additional HTTP extension information to fulfil the request. The server cannot process the request without further specifications declared via the HTTP Extension Framework.
To resolve 510 issues, ensure the client request includes the full required extension headers and attributes needed for the server to fulfil it. This code is rarely encountered outside of specialised HTTP extension contexts.
11. 511 Network Authentication Required
The 511 status indicates the client needs to authenticate with the network first before gaining internet access required to make the request. This is most commonly encountered on captive portal networks — such as hotel Wi-Fi, airport hotspots, or corporate guest networks — where users must accept terms or log in before internet access is granted. It is similar to 407 proxy auth but operates at the broader network access level.
The 7 HTTP Status Codes You Must Know for SEO
Whether you are a website manager or SEO professional, it is a must for you to know about essential HTTP status codes that impact the visibility, traffic, or crawlability of your website. Here are the most important HTTP status codes that matter a great deal for search engine optimisation.
- 200 OK responses indicate pages are returning content properly, which is ideal for SEO. Google wants to see 200s to know your site is working well and pages deserve to be indexed.
- 301 redirects are the correct tool for permanent URL changes. Search engines pass the majority of link equity (PageRank) to the new 301 destination URL. Use for permanent URL restructuring, HTTPS migrations, and domain consolidations.
- 302 temporary redirects do not permanently transfer link equity — it remains with the original URL. Use these sparingly and only for genuinely temporary situations. Excessive or chained 302s can confuse search bots.
- 404 errors mean pages are not found. Googlebot will eventually deindex URLs that consistently return 404. Fix broken links, implement 301 redirects to relevant alternatives, and create helpful custom 404 pages to retain user engagement.
- 410 Gone errors signal permanent removal more explicitly than 404. Use 410 when you have deliberately deleted content and want Google to remove it from its index faster than a 404 would achieve.
- 500 Internal Server Errors suggest serious technical problems. Pages returning recurring 500s risk poor crawling, reduced crawl frequency, and potential deindexing. Investigate server logs immediately and fix root causes.
- 503 Service Unavailable errors also indicate technical issues. Always pair 503 with a Retry-After header during planned maintenance so Googlebot knows when to return. Frequent unplanned 503s could lead to temporary deindexing of affected pages.
Monitoring status codes helps diagnose site health and technical SEO issues before they escalate. Addressing errors also improves user experience, which indirectly boosts rankings through improved engagement signals.
Best Tools to Monitor HTTP Status Codes on Your Website
Proactively monitoring HTTP status codes across your entire website — not just individual pages — is what separates reactive troubleshooting from strategic technical SEO. Here are the most effective tools for ongoing status code monitoring.
- Google Search Console (Free) — The Pages (Coverage) report shows all URLs Googlebot has encountered, categorised by their status: Indexed, Not indexed, Excluded. The URL Inspection tool provides individual page status code history. Essential for understanding how Google sees your site.
- Screaming Frog SEO Spider (Free up to 500 URLs) — Crawls your entire site locally and reports the HTTP status code of every URL it discovers, including images, CSS, and JavaScript files. Invaluable for pre-launch audits and identifying broken links, redirect chains, and soft 404s.
- Ahrefs Site Audit — Cloud-based crawler that monitors your site on a schedule and alerts you to new 4xx and 5xx errors, redirect chains, and crawlability issues. Excellent for large sites where a local crawl would be impractical.
- Semrush Site Audit — Similar to Ahrefs, provides scheduled crawling and comprehensive HTTP status reporting with prioritised issue lists and historical trend data.
- Sitebulb — Desktop-based crawler with exceptional visualisation tools for redirect chains, site architecture, and crawl depth. Particularly useful for agencies conducting client audits.
How to Fix 404 Errors (Not Found)?
404 errors occur when a requested URL path does not match any existing resources on the server. There are a few common ways to resolve these “page not found” issues:
- Review site analytics and crawlers to identify the sources of 404s. Check for broken links or unexpected user behaviour redirecting to non-existent pages.
- For invalid links, make corrections to point to the proper URLs. Use redirects if pages are moved to new locations.
- If pages were intentionally removed, install 301 redirects to route users and crawlers to relevant alternative content.
- For random invalid URLs, consider implementing custom 404 error pages that provide helpful navigation and site search to aid users rather than leaving them at a dead end.
- Set up 404 monitoring in Google Search Console or your preferred SEO crawling platform to quickly detect and address new issues over time.
Addressing 404s improves user experience by preventing dead ends and directing users to functional pages. It also improves SEO by recovering wasted crawl budget and fixing broken link equity flows.
How to Fix 503 Errors (Service Unavailable)?
503 errors indicate server overload or maintenance downtime, where the application is unable to handle incoming request volume. Strategies for improving uptime and minimising SEO impact include:
- Increase computing capacity by adding server resources (CPU, RAM) to handle more concurrent load
- Optimise databases and application code to reduce resource strain per request
- Implement request throttling, full-page caching, and object caching (Redis, Memcached) to reduce demand on the origin server
- Distribute requests across multiple servers using load balancing to eliminate single points of failure
Working with a specialised technical SEO agency at this stage can help you identify deeper performance bottlenecks, server misconfigurations, and crawl inefficiencies that may be contributing to recurring 503 errors.
- Profile traffic patterns to schedule maintenance downtime during lower-traffic periods
- Set up auto-scaling groups on cloud infrastructure (AWS, GCP, Azure) to dynamically add capacity during traffic spikes
- Communicate issues transparently to users until resolved — include a status page and estimated resolution time
Frequently Asked Questions About HTTP Status Codes
What is the difference between a 301 and 302 redirect?
A 301 Moved Permanently redirect tells both browsers and search engines that a URL has permanently moved to a new location. It transfers the vast majority of link equity (PageRank) to the new URL and causes search engines to update their index. A 302 Found redirect signals a temporary move — link equity stays with the original URL and search engines continue to index the old location. Use 301 for permanent URL changes; use 302 only when the redirect is genuinely temporary.
What causes a 504 Gateway Timeout error?
A 504 Gateway Timeout occurs when a proxy or gateway server (such as Nginx, a load balancer, or a CDN like Cloudflare) does not receive a response from the upstream origin server within the configured timeout period. Common causes include PHP execution time limits being exceeded, overloaded or unresponsive origin servers, slow database queries, network connectivity issues between the proxy and origin, and Cloudflare’s 100-second upstream timeout being hit. Fixing a 504 typically involves increasing timeout thresholds, optimising slow processes on the origin server, or scaling server resources.
Do 404 errors hurt SEO?
A small number of 404 errors is normal and expected on any website — Google does not penalise sites for isolated 404 pages. However, a large volume of 404 errors wastes crawl budget, can dilute topical authority signals, and means link equity flowing to deleted pages is lost. Pages that consistently return 404 will eventually be dropped from Google’s index. Monitor 404s through Google Search Console and address them by implementing 301 redirects, restoring the content, or removing internal links pointing to the dead URLs.
What is a 503 error and is it bad for SEO?
A 503 Service Unavailable error means the server is temporarily unable to handle the request — typically due to maintenance or overload. A brief 503 during planned maintenance is not harmful for SEO if it is handled correctly: always include a Retry-After response header so Googlebot knows when to return. Persistent or frequent unplanned 503 errors are more damaging — they can cause Googlebot to reduce crawl frequency and, in extreme cases, temporarily remove pages from the index.
What HTTP status code should a successful POST request return?
In REST API design, a POST request that successfully creates a new resource should return 201 Created, not 200 OK. The response should include a Location header pointing to the URL of the newly created resource. If a POST request triggers an action but does not create a persistent resource, 200 OK is acceptable. If the action is queued for asynchronous processing, 202 Accepted is the appropriate response.
What is a soft 404 and how does it affect SEO?
A soft 404 is a page that returns a 200 OK HTTP status code to the server but displays a “page not found” or very thin content message to the user. Google’s crawlers are designed to detect these pages and may treat them as genuine 404 errors, eventually removing them from the index. To avoid soft 404s, ensure that pages with no real content return a proper 404 or 410 HTTP status code rather than a misleading 200 response.
How can I check the HTTP status code of a URL?
There are four main methods: (1) Google Search Console URL Inspection tool — shows the status code Googlebot last saw for any URL on your site; (2) Chrome DevTools Network tab — shows the real-time status code for any page you visit in Chrome; (3) curl command in terminal — curl -o /dev/null -s -w "%{http_code}" https://example.com; (4) Online status code checker tools — free web-based tools that return the status code and full redirect chain for any URL.
What is the difference between a 401 and 403 error?
A 401 Unauthorized error means the server requires authentication that was not provided or failed — the user needs to log in or provide valid credentials. A 403 Forbidden error means the server understood the request and knows who you are (or does not require authentication), but is refusing to grant access regardless. Think of 401 as “you need to identify yourself” and 403 as “I know who you are, but you’re not allowed in.”
Conclusion
HTTP status codes provide valuable information on the availability, accessibility, and health of your web pages. As a website owner or SEO professional, staying on top of HTTP status codes helps you identify and resolve problems faced by both users and search engine crawlers — before they damage your rankings or user experience.
While individual status codes may seem like minor technical details, they directly determine whether your pages are indexed, how your link equity flows, how efficiently Googlebot crawls your site, and what experience your visitors have when they land on your pages. By leveraging tools like Google Search Console, Screaming Frog, and Ahrefs to monitor status codes proactively, you can troubleshoot errors early and maintain the technical foundation that strong SEO demands.
Use the complete list and explanations in this guide as your ongoing reference — bookmark it, share it with your development team, and revisit it whenever a new error code appears on your site.