HTTP Status Codes ExplainedComplete Reference Guide
This page provides a complete reference of HTTP status codes used by web servers and APIs. HTTP status codes are critical for web reliability and monitoring, as they indicate the result of HTTP requests and help identify availability issues, errors, and redirections.
This reference guide covers all standard HTTP status codes from 1xx informational responses to 5xx server errors, including detailed explanations, RFC references, examples, and best practices. Essential resource for web developers, API developers, webmasters, and DevOps engineers.
What Are HTTP Status Codes?
HTTP status codes are three-digit numeric codes returned by web servers to communicate the result of an HTTP request. These status codes are standardized by the Internet Engineering Task Force (IETF) in RFC 7231 and RFC 7235, providing a universal language for web communication between clients and servers.
Every HTTP response includes a status code that tells the client whether the request was successful, needs redirection, encountered a client error, or experienced a server error. Understanding HTTP status codes is essential for web developers, API developers, webmasters, and anyone working with web technologies.
HTTP Status Code Categories
HTTP status codes are organized into five main categories:
- 1xx Informational Responses: Provisional responses indicating the server received the request and is continuing to process it.
- 2xx Success Responses: The request was successfully received, understood, and accepted.
- 3xx Redirection Messages: The client must take additional action to complete the request.
- 4xx Client Error Responses: The request contains bad syntax or cannot be fulfilled by the server.
- 5xx Server Error Responses: The server failed to fulfill a valid request.
This comprehensive HTTP status codes reference guide covers all standard codes with detailed explanations, RFC references, real-world examples, best practices, common mistakes to avoid, and SEO impact considerations.
Table of Contents
Informational Responses
(4)Indicates a provisional response, informing the client that the initial part of the request has been received and has not yet been rejected.
Successful Responses
(10)Indicates that the request was successfully received, understood, and accepted.
Redirection Messages
(9)Indicates the client must take additional action to complete the request.
Client Error Responses
(29)Indicates the request contains bad syntax or cannot be fulfilled by the server.
Server Error Responses
(11)Indicates the server failed to fulfill a valid request.
Informational Responses
Indicates a provisional response, informing the client that the initial part of the request has been received and has not yet been rejected.
The server has received the request headers and the client should proceed to send the request body.
Used when the client needs to send a large request body and wants to confirm the server will accept it.
- •Use Expect: 100-continue header for large request bodies
- •Client should timeout if 100 response is not received within reasonable time
- •Server should respond quickly to avoid client timeout
- •Use for request bodies larger than 1MB
- •Sending request body before receiving 100 response
- •Server not responding to Expect header
- •Using for small request bodies unnecessarily
- •Not handling timeout scenarios
The 100 (Continue) status code indicates that the initial part of a request has been received and has not yet been rejected by the server. The server intends to send a final response after the request has been fully received and processed. This status code allows the client to determine whether the request body should be sent without waiting for the server to process the entire request.
The client must wait for a 100 (Continue) response before sending the request body. If the client receives a 100 response, it should continue sending the request body. If the client receives any other status code, it should not send the request body.
The server must send a 100 (Continue) response if it receives an Expect: 100-continue header and intends to process the request. The server should not wait indefinitely for the request body after sending 100.
POST /upload HTTP/1.1 Host: example.com Content-Length: 1000000 Expect: 100-continue
HTTP/1.1 100 Continue
- •Uploading large files where you want to confirm server acceptance before sending data
- •Preventing wasted bandwidth if server will reject the request
- •Optimizing large POST/PUT requests
- •Streaming large request bodies
The requester has asked the server to switch protocols and the server has agreed to do so.
Upgrading from HTTP/1.1 to HTTP/2 or switching to WebSocket protocol.
- •Always include Connection: upgrade header
- •Specify exact protocol version in Upgrade header
- •Handle protocol switch failures gracefully
- •Use for protocol upgrades, not content negotiation
- •Not including Connection: upgrade header
- •Switching to unsupported protocol
- •Not handling protocol switch errors
- •Using for content type negotiation (use Accept header instead)
The 101 (Switching Protocols) status code indicates that the server understands and is willing to comply with the client's request, via the Upgrade header field, for a change in the application protocol being used on this connection. The server must generate an Upgrade header field in the response that indicates which protocol(s) it is willing to switch to.
The client must send an Upgrade header indicating the desired protocol. After receiving 101, the client must switch to the new protocol immediately. The connection remains open and the protocol changes.
The server must send an Upgrade header indicating the protocol it will switch to. The server must switch protocols immediately after sending the 101 response. The response must include Connection: upgrade header.
GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
- •Upgrading HTTP/1.1 to HTTP/2
- •Switching to WebSocket protocol for real-time communication
- •Protocol negotiation for enhanced features
- •Upgrading to TLS/SSL
The server has received and is processing the request, but no response is available yet.
Used for long-running requests that may take a while to complete.
- •Send 102 responses periodically during long operations
- •Include progress information if possible
- •Eventually send final status code
- •Use for operations taking more than 30 seconds
- •Never sending final response after 102
- •Sending 102 for quick operations
- •Client timing out on 102 responses
- •Not implementing proper timeout handling
The 102 (Processing) status code is an informational status code used in WebDAV to indicate that the server has received and is processing the request, but no response is available yet. This prevents the client from timing out and thinking the request was lost.
The client should continue waiting for the final response. The client should not timeout based on receiving 102 responses.
The server should send periodic 102 responses to keep the connection alive during long-running operations. The server must eventually send a final status code.
- •WebDAV operations that take significant time
- •Long-running file operations
- •Batch processing requests
- •Operations requiring multiple steps
Used to return some response headers before final HTTP message.
Allows the browser to preload resources while the server prepares the full response.
- •Include Link headers with rel=preload
- •Only hint at critical resources
- •Send 103 before final response
- •Use for resources needed for above-the-fold content
- •Sending 103 after final response
- •Hinting at too many resources
- •Not including proper Link header syntax
- •Using for non-critical resources
The 103 (Early Hints) informational status code indicates to the client that the server is likely to send a final response with the header fields included in the informational response. This allows the client to preload resources while the server is still processing the request.
The client can use the Link header in the 103 response to preload resources. The client should continue waiting for the final response.
The server can send one or more 103 responses with Link headers before sending the final response. This enables resource hints for performance optimization.
GET /page HTTP/1.1 Host: example.com
HTTP/1.1 103 Early Hints Link: </style.css>; rel=preload; as=style Link: </script.js>; rel=preload; as=script HTTP/1.1 200 OK Content-Type: text/html <html>...</html>
- •Preloading critical CSS and JavaScript
- •DNS prefetching for external resources
- •Preconnecting to third-party domains
- •Optimizing page load performance
Successful Responses
Indicates that the request was successfully received, understood, and accepted.
The request has succeeded. The meaning of success depends on the HTTP method used.
GET: The resource has been fetched and transmitted in the message body. POST: The resource describing the result of the action is transmitted in the message body.
- •Use for successful requests that return content
- •Include appropriate Content-Type header
- •Include caching headers (ETag, Cache-Control) when applicable
- •Provide meaningful response body
- •Use consistent response format across API
- •Consider using 201 Created for resource creation
- •Consider using 204 No Content when no body is needed
- •Using 200 OK when 201 Created is more appropriate for POST
- •Using 200 OK when 204 No Content is more appropriate
- •Not including Content-Type header
- •Returning 200 OK with error message in body
- •Not including caching headers when appropriate
- •Inconsistent response formats
The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. For GET requests, the payload is a representation of the target resource. For POST requests, the payload is a representation of the result of the action. For PUT and PATCH requests, the payload is typically a representation of the updated resource.
The client should process the response body according to the Content-Type header. The client may cache the response if appropriate headers are present. The client should handle the response based on the request method used.
The server should include appropriate Content-Type header. The server may include caching headers (ETag, Last-Modified, Cache-Control). The server should provide a meaningful response body for the request method.
GET /api/users/123 HTTP/1.1 Host: api.example.com Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
ETag: "abc123"
Cache-Control: public, max-age=3600
{"id": 123, "name": "John Doe", "email": "[email protected]"}- •Successful GET request returning resource data
- •Successful POST request returning created/updated resource
- •Successful PUT/PATCH request returning updated resource
- •Successful DELETE request with confirmation message
- •Standard success response for most operations
- •API endpoints returning data successfully
200 OK responses are essential for SEO. Ensure all important pages return 200. Fast 200 responses improve page speed metrics. Proper caching headers reduce server load and improve performance.
The request has been fulfilled and has resulted in one or more new resources being created.
After successfully creating a new user account or uploading a file, the server returns 201 with the location of the new resource.
- •Always include Location header with URI of created resource
- •Use absolute URI in Location header
- •Include created resource in response body when possible
- •Use for POST requests that create resources
- •Can use for PUT requests that create new resources
- •Provide resource identifier in response
- •Include timestamps for created resources
- •Using 200 OK instead of 201 Created for resource creation
- •Not including Location header
- •Using relative URI in Location header
- •Not including created resource in response
- •Using 201 for updates (use 200 or 204)
- •Using 201 when resource already exists (use 200)
The 201 (Created) status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI.
The client should use the Location header to access the newly created resource. The client should not assume the resource is immediately available. The client may follow the Location header to retrieve the resource.
The server should include a Location header pointing to the newly created resource. The server should include the created resource in the response body when possible. The server should use absolute URI in Location header.
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"name": "Jane Doe", "email": "[email protected]"}HTTP/1.1 201 Created
Location: https://api.example.com/api/users/456
Content-Type: application/json
{"id": 456, "name": "Jane Doe", "email": "[email protected]", "createdAt": "2025-01-15T10:30:00Z"}- •Creating new resources via POST
- •User registration
- •File uploads
- •Creating database records
- •Resource creation in REST APIs
- •Account creation
- •Document creation
201 responses are typically not relevant for SEO as they apply to API operations. However, ensure proper handling of resource creation for better API usability.
The request has been accepted for processing, but the processing has not been completed.
The request is valid but will be processed asynchronously, such as sending an email or processing a video.
- •Use for requests that will be processed asynchronously
- •Include Location header pointing to status endpoint
- •Provide job ID or tracking identifier
- •Document how to check processing status
- •Consider including Retry-After header
- •Provide clear messaging about async nature
- •Implement status polling endpoint
- •Using 202 when processing is synchronous (use 200 or 201)
- •Not providing a way to check status
- •Not including Location header
- •Client expecting immediate results
- •Not documenting async behavior
- •Using 202 for all POST requests
The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation.
The client should not expect immediate results. The client may poll a status endpoint if provided. The client should handle the asynchronous nature of the operation. The client should not assume the request will succeed.
The server should accept the request for processing. The server may include a Location header pointing to a status endpoint. The server should process the request asynchronously. The server should provide a way to check status.
POST /api/videos/process HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"videoId": "12345", "format": "mp4"}HTTP/1.1 202 Accepted
Location: https://api.example.com/api/jobs/789
Content-Type: application/json
{"jobId": "789", "status": "processing", "message": "Video processing started"}- •Asynchronous processing requests
- •Background job submission
- •Email sending operations
- •Video/image processing
- •Long-running operations
- •Batch processing
- •Webhook triggers
- •Scheduled tasks
202 responses are typically not relevant for SEO as they apply to API operations. However, proper async handling improves API usability and performance.
The request was successful but the enclosed payload has been modified by a transforming proxy.
The response comes from a cache or proxy that modified the original response.
- •Use when response has been modified by proxy
- •Include Warning header when applicable
- •Preserve important information during transformation
- •Document transformation behavior
- •Consider using 200 OK if transformation is transparent
- •Using 203 unnecessarily
- •Not indicating modifications
- •Losing important information during transformation
- •Not including Warning headers
- •Using when response is unchanged
The 203 (Non-Authoritative Information) status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's 200 (OK) response by a transforming proxy. This status code allows the proxy to notify recipients when a transformation has been applied.
The client should be aware the response may have been modified. The client should check Warning headers if present. The client should treat the response as potentially modified.
The server (proxy) should indicate modifications made. The server may include Warning headers. The server should preserve important information when transforming.
GET /api/data HTTP/1.1 Host: example.com
HTTP/1.1 203 Non-Authoritative Information
Content-Type: application/json
Warning: 214 Transformation applied
{"data": "modified by proxy"}- •Responses modified by transforming proxies
- •Content delivery networks modifying content
- •Proxy servers applying transformations
- •Response compression or optimization
- •Content filtering or sanitization
203 responses are rarely used in modern web development. Most proxies and CDNs maintain transparency and return 200 OK. Not typically relevant for SEO.
The server successfully processed the request and is not returning any content.
Used for DELETE requests or form submissions where no response body is needed.
- •Use for successful DELETE operations
- •Use for PUT/PATCH requests when no response body is needed
- •Response body must be empty
- •Can be used for form submissions that don't need a response
- •Include ETag header if resource state changed
- •Consider including Location header if resource moved
- •Including a response body (must be empty)
- •Using 200 OK when 204 No Content is more appropriate
- •Using for POST requests (use 201 or 200 instead)
- •Client assuming resource was deleted on any 204 response
- •Not including relevant headers (ETag, Location)
The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.
The client should not change its document view. The client should not assume the resource was deleted unless it was a DELETE request. The client should not display a new document. The client may update cached headers if present.
The server must not send a message body in the response. The server may include entity-header fields. The server should include ETag header if the resource state changed. The server must send Content-Length: 0 if no headers are present.
DELETE /api/users/123 HTTP/1.1 Host: api.example.com Authorization: Bearer token
HTTP/1.1 204 No Content ETag: "new-etag-value"
- •Successful DELETE operations where no response body is needed
- •PUT/PATCH requests that update a resource without returning it
- •Form submissions that don't need to display a result
- •Batch operations where individual results aren't important
- •Updating resources where the client already has the current state
The server successfully processed the request, asks that the requester reset its document view.
Used to clear form fields after a successful submission.
- •Use for form submissions that should clear the form
- •Response body must be empty
- •Use when user should be able to submit the form again
- •Consider using 200 or 204 if form clearing is not needed
- •Including response body (must be empty)
- •Using when form should not be cleared
- •Not supported by all browsers consistently
- •Using 200 OK when 205 is more appropriate
The 205 (Reset Content) status code indicates that the server has successfully fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server.
The client should reset the form or document view that caused the request. The client should clear form fields. The client should not navigate away from the page.
The server must not send a message body. The server should use this for form submissions where the form should be cleared.
- •Form submissions where form should be cleared after success
- •Resetting user input after successful processing
- •Clearing document state after action completion
The server is delivering only part of the resource due to a range header sent by the client.
Used for resuming interrupted downloads or streaming video content.
- •Always include Content-Range header
- •Include Accept-Ranges: bytes in all GET responses
- •Support multiple range requests when possible
- •Handle If-Range header for conditional range requests
- •Use proper Content-Type header
- •Not including Content-Range header
- •Sending wrong byte range
- •Not supporting Range requests at all
- •Incorrect Content-Range format
- •Not including Accept-Ranges header
The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges found in the request's Range header field.
The client should use the Content-Range header to determine which part was received. The client can request additional ranges. The client should handle multiple 206 responses for multipart ranges.
The server must include Content-Range header indicating which bytes were sent. The server must include Content-Type header. The server should include Accept-Ranges header in all responses. The server must send only the requested byte range.
GET /large-file.zip HTTP/1.1 Host: example.com Range: bytes=0-1023
HTTP/1.1 206 Partial Content Content-Type: application/zip Content-Range: bytes 0-1023/1048576 Content-Length: 1024 Accept-Ranges: bytes [binary data]
- •Resuming interrupted downloads
- •Streaming video or audio content
- •Downloading large files in chunks
- •Implementing progressive download
- •Bandwidth optimization for large resources
Conveys information about multiple resources, for situations where multiple status codes might be appropriate.
Used in WebDAV when multiple operations are performed and some succeed while others fail.
The members of a DAV binding have already been enumerated in a previous reply to this request.
Used in WebDAV to avoid repeatedly listing the same internal members of a collection.
The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.
Used for Delta Encoding in HTTP, allowing efficient updates of cached resources.
Redirection Messages
Indicates the client must take additional action to complete the request.
The request has more than one possible response. The user agent or user should choose one of them.
Rarely used. The server offers multiple representations of the resource.
The URL of the requested resource has been changed permanently. The new URL is given in the response.
When a website changes its domain name or restructures URLs, old URLs redirect to new ones permanently.
- •Always include a Location header with the new URL
- •Use for permanent URL changes (domain migration, URL restructuring)
- •Search engines will transfer SEO value to the new URL
- •Browsers may cache the redirect permanently
- •Using 301 for temporary redirects - use 302 or 307 instead
- •Creating redirect chains (A→B→C) - redirect directly to final destination
- •Not including the Location header
- •Using 301 for POST requests - use 308 Permanent Redirect instead
301 redirects pass SEO value (PageRank, link equity) to the new URL. Use for permanent moves. Avoid redirect chains as they can dilute SEO value.
The URL of the requested resource has been changed temporarily. Further changes in the URL might be made in the future.
Temporary redirect, commonly used after form submissions to prevent duplicate submissions.
- •Use for temporary redirects only
- •Include Location header
- •Consider using 307 Temporary Redirect for better HTTP method preservation
- •Use after POST requests to prevent duplicate form submissions
- •Using 302 for permanent redirects - use 301 instead
- •Using 302 for POST requests - use 307 or 303 instead
- •Ambiguous behavior with HTTP methods - prefer 307 or 303 for clarity
302 redirects don't pass SEO value. Search engines treat them as temporary and may not update their index. Use 301 for permanent moves.
The server sent this response to direct the client to get the requested resource at another URI with a GET request.
After a POST request, redirecting to a GET request to display the result page.
- •Use after POST/PUT/DELETE to redirect to GET
- •Always include Location header
- •Use for POST-Redirect-GET pattern
- •Prevents duplicate form submissions
- •Redirect to a page that displays the result
- •Use absolute URI in Location header
- •Using 303 for GET requests (use 301, 302, 307, or 308)
- •Not including Location header
- •Client not changing method to GET
- •Using 302 when 303 is more appropriate
- •Redirecting to same URL causing loops
- •Not handling redirect properly in client
The 303 (See Other) status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which is intended to provide an indirect response to the original request. A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request.
The client must change the HTTP method to GET when following the redirect. The client should not resend the original request body. The client should follow the Location header to the new URI.
The server must include a Location header. The server should use 303 after POST to prevent duplicate submissions. The server should redirect to a GET endpoint that displays the result.
POST /api/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"productId": 123, "quantity": 2}HTTP/1.1 303 See Other Location: https://api.example.com/orders/456
- •Redirecting after POST to prevent duplicate submissions
- •Form submissions redirecting to success page
- •POST-Redirect-GET pattern
- •Redirecting to result page after action
- •Preventing browser back button issues
- •RESTful resource creation redirects
303 redirects are commonly used for POST-Redirect-GET pattern, which prevents duplicate form submissions. Important for form handling and user experience. Search engines typically follow 303 redirects.
This is used for caching purposes. It tells the client that the response has not been modified, so the client can continue to use the same cached version of the response.
The browser uses cached content because the resource has not changed since the last request.
- •Include ETag or Last-Modified headers in responses
- •Client should send If-None-Match or If-Modified-Since headers
- •Response body must be empty
- •Use for conditional GET requests to save bandwidth
- •Including a response body (must be empty)
- •Not implementing conditional requests properly
- •Missing ETag or Last-Modified headers
304 responses improve site performance and reduce server load, which can indirectly benefit SEO through better page speed metrics.
Defined in a previous version of the HTTP specification to indicate that a requested response must be accessed by a proxy.
Deprecated and rarely used. Was meant to indicate the client should use a specific proxy.
- •Do not use - this status code is deprecated
- •Use 301 or 302 redirects instead if proxy configuration is needed
- •Using this deprecated status code
- •Confusing with 301/302 redirects
This response code is no longer used; it is just reserved. It was used in a previous version of the HTTP/1.1 specification.
No longer in use, kept for historical reasons.
The server sends this response to direct the client to get the requested resource at another URI with the same method that was used in the prior request.
Similar to 302, but preserves the HTTP method (POST stays POST, GET stays GET).
- •Use for temporary redirects that must preserve HTTP method
- •Always include Location header
- •Prefer over 302 when method preservation is critical
- •Use for API endpoints that need method preservation
- •Indicate temporary nature clearly
- •Using 307 for permanent redirects (use 308)
- •Not including Location header
- •Client changing method when it shouldn't
- •Using 302 when 307 is more appropriate
- •Not handling redirect loops
The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent must not change the request method if it performs an automatic redirection to that URI. Since the redirection might be altered on occasion, the client ought to continue to use the effective request URI for future requests.
The client must preserve the HTTP method when following the redirect. POST requests must be resent as POST. The client should not automatically follow redirects for non-safe methods unless explicitly configured.
The server must include a Location header. The server should use 307 instead of 302 when method preservation is important. The server should indicate this is a temporary condition.
POST /api/data HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"key": "value"}HTTP/1.1 307 Temporary Redirect Location: https://api-backup.example.com/api/data
- •Temporary server maintenance redirects
- •Load balancing redirects
- •Temporary URL changes that preserve method
- •API endpoint temporary relocation
- •Preserving POST/PUT/DELETE methods during redirect
307 redirects don't pass SEO value like 301. Search engines treat them as temporary. Use 301 for permanent moves.
This means that the resource is now permanently located at another URI, specified by the Location: HTTP Response header.
Similar to 301, but preserves the HTTP method. Used for permanent redirects that maintain the request method.
- •Use for permanent redirects that must preserve HTTP method
- •Always include Location header with absolute URI
- •Prefer over 301 when method preservation is critical
- •Use for API versioning and endpoint migration
- •Ensure redirect is truly permanent
- •Using 308 for temporary redirects (use 307)
- •Not including Location header
- •Using 301 when 308 is more appropriate for APIs
- •Creating redirect chains
- •Not updating all references to old URI
The 308 (Permanent Redirect) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. The request method and request body are not altered when reissuing the original request to the new URI.
The client must preserve the HTTP method when following the redirect. The client should update bookmarks and caches. The client should use the new URI for future requests.
The server must include a Location header with the new permanent URI. The server should use 308 instead of 301 when method preservation is important. The server should indicate this is a permanent condition.
PUT /old-api/resource HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"data": "value"}HTTP/1.1 308 Permanent Redirect Location: https://api.example.com/new-api/resource
- •Permanent API endpoint relocation preserving methods
- •Permanent URL restructuring for REST APIs
- •Domain migration preserving all HTTP methods
- •Permanent redirects for POST/PUT/DELETE endpoints
308 redirects pass SEO value like 301, but also preserve HTTP methods. Important for API endpoints. Search engines will update their index.
Client Error Responses
Indicates the request contains bad syntax or cannot be fulfilled by the server.
The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, invalid request message framing).
Invalid JSON in request body, missing required parameters, or malformed HTTP headers.
- •Include error details in response body explaining what was wrong
- •Use for validation errors, malformed requests, or missing required fields
- •Provide clear error messages to help developers debug
- •Use appropriate Content-Type (e.g., application/json for JSON APIs)
- •Include field-level error information when possible
- •Follow consistent error response format
- •Log 400 errors for monitoring and debugging
- •Returning 200 OK with an error message - use 400 instead
- •Not providing helpful error messages
- •Using 400 for authentication errors - use 401 Unauthorized
- •Using 400 for authorization errors - use 403 Forbidden
- •Using 400 when resource doesn't exist - use 404 Not Found
- •Generic error messages that don't help debugging
- •Not including error details in response body
The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
The client should not repeat the request without modification. The client should fix the request syntax or structure before retrying. The client should check the error message in the response body for details.
The server should include a message body explaining the error. The server should use appropriate Content-Type header. The server should provide specific details about what was wrong with the request.
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"name": "John", "email": invalid-email}HTTP/1.1 400 Bad Request
Content-Type: application/json
{"error": "Invalid JSON syntax", "message": "Unexpected token 'invalid' at position 25", "field": "email"}- •Invalid JSON syntax in request body
- •Missing required request parameters
- •Malformed HTTP headers
- •Invalid request message framing
- •Validation errors in form submissions
- •Type mismatches in request data
- •Invalid query parameter formats
Too many 400 errors can indicate site issues. Ensure proper URL structure and avoid broken links. 400 errors from search engine crawlers may indicate crawlability problems.
The request has not been applied because it lacks valid authentication credentials for the target resource.
User tries to access a protected resource without logging in or with expired/invalid credentials.
- •Include WWW-Authenticate header indicating authentication scheme
- •Use for missing or invalid authentication credentials
- •Return 403 Forbidden if user is authenticated but lacks permission
- •Provide clear error message about authentication requirement
- •Don't reveal whether username exists (security)
- •Use consistent authentication error messages
- •Support multiple authentication schemes when possible
- •Using 401 for authorization errors - use 403 Forbidden instead
- •Not including WWW-Authenticate header
- •Confusing authentication (who you are) with authorization (what you can do)
- •Revealing whether user exists in error messages
- •Different error messages for same authentication failure
- •Not supporting standard authentication schemes
The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response must send a WWW-Authenticate header field containing at least one challenge applicable to the target resource.
The client should retry the request with appropriate authentication credentials. The client should use the authentication scheme indicated in the WWW-Authenticate header. The client may prompt the user for credentials.
The server must include a WWW-Authenticate header indicating the authentication scheme. The server should not reveal whether the user exists or the password is wrong (security best practice). The server should use consistent error messages.
GET /api/protected HTTP/1.1 Host: api.example.com
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", charset="UTF-8"
Content-Type: application/json
{"error": "Unauthorized", "message": "Authentication required"}- •Missing authentication token or credentials
- •Expired authentication token
- •Invalid authentication credentials
- •Authentication token format is incorrect
- •User not logged in attempting to access protected resource
- •Session expired
401 errors are typically not relevant for SEO as they apply to authenticated resources. However, ensure public pages don't return 401 unnecessarily.
Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme.
Rarely used. Originally intended for payment systems, but not commonly implemented.
The server understood the request but refuses to authorize it. Unlike 401, the client's identity is known to the server.
User is logged in but doesn't have permission to access a specific resource or perform an action.
- •Use when user is authenticated but lacks permission
- •Different from 401 - user is known but not authorized
- •Provide clear message explaining why access is forbidden
- •Consider returning 404 Not Found to hide resource existence if security requires it
- •Log authorization failures for security monitoring
- •Don't reveal sensitive system information
- •Use consistent error messages
- •Using 403 for authentication errors - use 401 Unauthorized
- •Using 403 when resource doesn't exist - use 404 Not Found
- •Revealing sensitive information in error messages
- •Not explaining why access is forbidden
- •Using 403 for rate limiting - use 429 Too Many Requests
- •Confusing with 401 Unauthorized
The 403 (Forbidden) status code indicates that the server understood the request but refuses to fulfill it. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it should describe the reason for the refusal in the response payload.
The client should not retry the request with the same credentials. The client may need different permissions or roles. The client should check the error message for explanation.
The server should provide a clear explanation of why access is forbidden. The server may choose to return 404 instead to hide resource existence for security. The server should log authorization failures.
DELETE /api/admin/users/123 HTTP/1.1 Host: api.example.com Authorization: Bearer user-token
HTTP/1.1 403 Forbidden
Content-Type: application/json
{"error": "Forbidden", "message": "Insufficient permissions. Admin role required."}- •User authenticated but lacks required permissions
- •User role doesn't allow the requested action
- •Resource access restricted to specific users
- •IP address blocked or blacklisted
- •Geographic restrictions
- •Time-based access restrictions
- •Resource ownership validation failed
403 errors can indicate access control issues. For public content, ensure proper permissions. Consider using 404 for resources that should be hidden from unauthorized users.
The server cannot find the requested resource. In the browser, this means the URL is not recognized.
The most common error. Occurs when a URL doesn't exist, a file was deleted, or the URL was mistyped.
- •Use for resources that don't exist
- •Provide helpful 404 pages with navigation options
- •Log 404 errors to identify broken links
- •Consider redirecting old URLs to new ones instead of 404
- •Include search functionality on 404 pages
- •Suggest similar or popular content
- •Return consistent 404 format for APIs
- •Using 404 for authentication errors - use 401
- •Using 404 for authorization errors - use 403
- •Not providing helpful error pages
- •Too many 404s can hurt SEO
- •Not logging 404 errors
- •Returning 200 OK with error message instead of 404
- •Not redirecting moved content (use 301)
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent.
The client should not retry the request without modification. The client should check if the URL is correct. The client may display a helpful error page if provided by the server.
The server should provide a helpful 404 page with navigation options. The server should log 404 errors to identify broken links. The server may choose to return 404 instead of 403 to hide resource existence.
GET /nonexistent-page HTTP/1.1 Host: example.com
HTTP/1.1 404 Not Found Content-Type: text/html <html><body><h1>404 - Page Not Found</h1><p>The requested page could not be found.</p></body></html>
- •Resource doesn't exist at the requested URL
- •File was deleted or moved without redirect
- •URL was mistyped or contains errors
- •API endpoint doesn't exist
- •Resource ID doesn't exist in database
- •Hiding resource existence for security (instead of 403)
Excessive 404 errors can negatively impact SEO. Use 301 redirects for moved content. Monitor and fix broken links regularly. Search engines may reduce crawling frequency if too many 404s are encountered. Implement proper 404 handling and redirects.
The request method is known by the server but is not supported by the target resource.
Trying to POST to an endpoint that only accepts GET requests, or DELETE on a read-only resource.
- •Always include Allow header with supported methods
- •Provide clear error message
- •Document supported methods in API documentation
- •Use for method restrictions, not missing resources (use 404)
- •Log unsupported method attempts
- •Not including Allow header
- •Using 405 when resource doesn't exist (use 404)
- •Using 405 for authentication (use 401)
- •Not documenting supported methods
- •Generic error messages
The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource. The origin server must generate an Allow header field containing a list of the target resource's currently supported methods.
The client should check the Allow header to see which methods are supported. The client should not retry with the same method. The client may try a different HTTP method.
The server must include an Allow header listing supported methods. The server should provide clear error message. The server should log unsupported method attempts.
DELETE /api/readonly-resource HTTP/1.1 Host: api.example.com
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
{"error": "Method Not Allowed", "message": "DELETE method is not supported for this resource"}- •Trying to POST to a read-only endpoint
- •Attempting DELETE on a protected resource
- •Using unsupported HTTP method for endpoint
- •REST API method restrictions
- •Resource doesn't support the requested operation
The server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers.
Client requests JSON but server can only provide XML, or language preferences cannot be met.
- •Include Vary header for content negotiation
- •Indicate available content types in error
- •Use for strict content negotiation
- •Consider returning default representation instead
- •Using 406 when 415 Unsupported Media Type is more appropriate
- •Not indicating available content types
- •Too strict content negotiation
- •Not including Vary header
The 406 (Not Acceptable) status code indicates that the target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request, and the server is unwilling to supply a default representation.
The client should check what content types are available. The client may retry with different Accept headers. The client should handle gracefully.
The server should indicate what content types are available. The server may include Vary header. The server should provide helpful error message.
GET /api/data HTTP/1.1 Host: api.example.com Accept: application/xml
HTTP/1.1 406 Not Acceptable
Content-Type: application/json
Vary: Accept
{"error": "Not Acceptable", "message": "Server can only provide application/json, not application/xml"}- •Client requests unsupported content type
- •Language negotiation fails
- •Content encoding not supported
- •API version negotiation fails
Similar to 401 Unauthorized, but it indicates that the client must first authenticate itself with the proxy.
The proxy server requires authentication before forwarding the request to the destination server.
- •Include Proxy-Authenticate header
- •Use standard proxy authentication schemes
- •Provide clear authentication requirements
- •Support multiple authentication schemes
- •Not including Proxy-Authenticate header
- •Confusing with 401 Unauthorized
- •Not supporting standard proxy auth schemes
- •Poor error messages
The 407 (Proxy Authentication Required) status code is similar to 401 (Unauthorized), but it indicates that the client needs to authenticate itself in order to use a proxy. The proxy must send a Proxy-Authenticate header field containing a challenge applicable to that proxy for the target resource.
The client should authenticate with the proxy using the scheme indicated in Proxy-Authenticate header. The client should retry the request with proxy authentication.
The server (proxy) must include Proxy-Authenticate header. The server should indicate the authentication scheme required.
- •Corporate proxy requiring authentication
- •VPN proxy authentication
- •Secure proxy access
- •Network-level authentication
The server did not receive a complete request message within the time that it was prepared to wait.
The client took too long to send the request, or the server timed out waiting for the request body.
- •Set appropriate timeout values
- •Close connection on timeout
- •Log timeout occurrences
- •Provide helpful error messages
- •Consider supporting chunked transfer encoding
- •Confusing with 504 Gateway Timeout
- •Not closing connection
- •Timeout values too short or too long
- •Not logging timeouts
The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. A server should send the "close" connection option in the response, since 408 implies that the server has decided to close the connection rather than continue waiting.
The client should retry the request. The client may need to send the request faster or in smaller chunks. The client should handle connection closure.
The server should close the connection. The server should log timeout occurrences. The server may include timeout information in response.
- •Client takes too long to send request body
- •Slow network connections
- •Large file uploads timing out
- •Request transmission delays
The request could not be completed due to a conflict with the current state of the target resource.
Trying to create a resource that already exists, or updating a resource that was modified by another user.
- •Include conflict details in response body
- •Use ETags for optimistic concurrency control
- •Provide actionable error information
- •Document conflict resolution strategies
- •Use for state conflicts, not validation errors
- •Using 409 for validation errors (use 400 or 422)
- •Not providing conflict details
- •Not using ETags for concurrency control
- •Generic conflict messages
- •Not documenting conflict scenarios
The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request.
The client should check the current state of the resource. The client may need to resolve the conflict before retrying. The client should handle conflicts gracefully.
The server should include information about the conflict in the response body. The server may include ETag or Location headers. The server should provide actionable error information.
PUT /api/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
If-Match: "old-etag"
{"name": "Updated Name"}HTTP/1.1 409 Conflict
Content-Type: application/json
ETag: "new-etag"
{"error": "Conflict", "message": "Resource was modified by another user. Current version has ETag: new-etag"}- •Creating resource that already exists
- •Updating resource with stale ETag
- •Concurrent modification conflicts
- •Unique constraint violations
- •Version control conflicts
- •Optimistic locking failures
The target resource is no longer available at the origin server and this condition is likely to be permanent.
A resource that existed previously has been permanently removed and will not be available again.
- •Use when resource is permanently removed
- •Different from 404 - resource definitely existed
- •Consider including alternative location if available
- •Provide helpful message explaining removal
- •Use for resources that won't be restored
- •Update all references to removed resource
- •Using 410 for temporarily unavailable resources (use 503)
- •Using 410 when unsure if permanent (use 404)
- •Not providing helpful information
- •Using 404 when 410 is more appropriate
- •Not removing cached references
- •Client retrying 410 requests
The 410 (Gone) status code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) ought to be used instead.
The client should not retry the request. The client should remove any cached references. The client should update bookmarks or links. The client should not attempt to access the resource again.
The server should indicate the resource is permanently gone. The server may include a Location header if an alternative is available. The server should provide helpful information about why the resource is gone.
GET /api/products/old-product-123 HTTP/1.1 Host: api.example.com
HTTP/1.1 410 Gone
Content-Type: application/json
{"error": "Gone", "message": "This product has been permanently removed and is no longer available"}- •Permanently deleted resources
- •Removed content that won't be restored
- •Discontinued products or services
- •Permanently removed user accounts
- •Content that was intentionally removed
- •Resources that expired and won't return
410 Gone tells search engines the resource is permanently removed. Search engines will remove it from their index faster than 404. Use 410 for permanently deleted content to help with SEO cleanup.
The server refuses to accept the request without a defined Content-Length header.
The server requires a Content-Length header but the client didn't provide one in the request.
- •Use when Content-Length is required
- •Provide clear error message
- •Consider supporting chunked transfer encoding
- •Document Content-Length requirements
- •Use for security-sensitive endpoints
- •Requiring Content-Length unnecessarily
- •Not supporting chunked transfer encoding
- •Poor error messages
- •Not documenting requirements
- •Using when chunked encoding is acceptable
The 411 (Length Required) status code indicates that the server refuses to accept the request without a defined Content-Length. The client may repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request message.
The client should include a Content-Length header with the request body size. The client should retry the request with the header. The client should calculate the body length before sending.
The server should require Content-Length for requests with body. The server should provide clear error message. The server may support chunked transfer encoding as alternative.
POST /api/upload HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"data": "value"}HTTP/1.1 411 Length Required
Content-Type: application/json
{"error": "Length Required", "message": "Content-Length header is required for this request"}- •Server requires Content-Length for request body
- •Upload endpoints requiring explicit length
- •Servers that don't support chunked encoding
- •Strict content length validation
- •Preventing request body size attacks
411 errors are typically not relevant for SEO as they apply to API operations. However, proper handling improves API usability.
One or more conditions given in the request header fields evaluated to false when tested on the server.
If-Match or If-None-Match headers don't match the current resource state, or ETag validation fails.
- •Use for conditional request failures
- •Include current ETag in response
- •Provide clear error message
- •Use ETags for optimistic locking
- •Document conditional header requirements
- •Handle all conditional headers properly
- •Not evaluating conditional headers
- •Not including current ETag
- •Using 412 for validation errors (use 400 or 422)
- •Not documenting conditional requirements
- •Generic error messages
- •Not supporting conditional requests
The 412 (Precondition Failed) status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the server. This response code allows the client to place preconditions on the current resource state and thus prevent the request method from being applied if the target resource is in an unexpected state.
The client should check the current resource state. The client should fetch the latest version and retry. The client should handle precondition failures gracefully.
The server should evaluate all conditional headers. The server should return 412 if any condition fails. The server may include current ETag in response.
PUT /api/users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
If-Match: "old-etag"
{"name": "Updated"}HTTP/1.1 412 Precondition Failed
ETag: "new-etag"
Content-Type: application/json
{"error": "Precondition Failed", "message": "Resource was modified. Current ETag: new-etag"}- •Optimistic concurrency control
- •Preventing lost updates
- •ETag validation failures
- •Conditional requests failing
- •Resource state changed since last fetch
- •Version control conflicts
412 errors are typically not relevant for SEO as they apply to API operations. However, proper conditional request handling improves API reliability and prevents data conflicts.
The server is refusing to process a request because the request payload is larger than the server is willing or able to process.
Uploading a file that exceeds the server's maximum file size limit, or request body is too large.
- •Set reasonable size limits
- •Document maximum payload sizes
- •Include size limit in error message
- •Consider supporting chunked uploads
- •Use for security and resource protection
- •Provide clear error messages
- •Size limits too restrictive or too permissive
- •Not documenting size limits
- •Not including limit in error message
- •Not supporting chunked uploads for large files
- •Generic error messages
- •Not protecting against DoS
The 413 (Payload Too Large) status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server may close the connection to prevent the client from continuing the request.
The client should reduce the payload size. The client may split the request into smaller parts. The client should check size limits before sending. The client should handle the error gracefully.
The server should indicate the maximum allowed size. The server may close the connection. The server should provide helpful error message with size limits.
POST /api/upload HTTP/1.1 Host: api.example.com Content-Type: multipart/form-data Content-Length: 10485760 [large file data]
HTTP/1.1 413 Payload Too Large
Content-Type: application/json
{"error": "Payload Too Large", "message": "Maximum request size is 5MB", "maxSize": 5242880}- •File uploads exceeding size limits
- •Request body too large
- •API payload size restrictions
- •Protecting against DoS attacks
- •Resource quota limitations
- •Memory protection
413 errors are typically not relevant for SEO as they apply to API operations. However, proper size limit handling improves API usability and security.
The server is refusing to service the request because the request-target is longer than the server is willing to interpret.
The URL is too long, often due to too many query parameters or a very long path.
- •Set reasonable URI length limits
- •Document maximum URI length
- •Suggest using POST for long data
- •Provide helpful error messages
- •Consider URL shortening for long paths
- •Use POST instead of GET for large queries
- •URI length limits too restrictive
- •Not documenting limits
- •Not suggesting POST alternative
- •Poor error messages
- •Using GET for large amounts of data
- •Not handling long URLs gracefully
The 414 (URI Too Long) status code indicates that the server is refusing to service the request because the request-target is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information.
The client should shorten the URI. The client may use POST instead of GET for long data. The client should reduce query parameters. The client should handle the error gracefully.
The server should indicate the maximum URI length. The server should provide helpful error message. The server may suggest using POST for long data.
GET /api/search?q=very+long+search+query+with+many+parameters+and+additional+data+that+makes+the+uri+extremely+long HTTP/1.1 Host: api.example.com
HTTP/1.1 414 URI Too Long
Content-Type: application/json
{"error": "URI Too Long", "message": "Maximum URI length is 2048 characters. Consider using POST for long queries."}- •URLs exceeding server limits
- •Too many query parameters
- •Very long path segments
- •GET requests with excessive data
- •URL encoding issues
- •Improper GET to POST conversion
414 errors can occur with very long URLs. Search engines typically handle long URLs, but extremely long URLs may cause issues. Use POST for long query data instead of GET. Keep URLs concise for better SEO.
The origin server is refusing to service the request because the payload is in a format not supported by this method on the target resource.
Sending XML when the server only accepts JSON, or uploading an unsupported file format.
- •Indicate supported media types in error
- •Use for content type mismatches
- •Different from 406 (client Accept header)
- •Document supported media types
- •Provide clear error messages
- •Include Accept header in response
- •Using 415 for Accept header issues (use 406)
- •Not indicating supported types
- •Confusing with 400 Bad Request
- •Not documenting supported types
- •Generic error messages
- •Not validating Content-Type
The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the payload is in a format not supported by this method on the target resource. The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.
The client should check the Content-Type header. The client should use a supported media type. The client should check API documentation for supported types. The client should handle the error gracefully.
The server should indicate supported media types. The server should provide clear error message. The server may include Accept header showing supported types.
POST /api/users HTTP/1.1 Host: api.example.com Content-Type: application/xml <user><name>John</name></user>
HTTP/1.1 415 Unsupported Media Type
Content-Type: application/json
Accept: application/json
{"error": "Unsupported Media Type", "message": "Server only accepts application/json, not application/xml"}- •Sending unsupported content type
- •File uploads with wrong format
- •API expecting different format
- •Content-Type mismatch
- •Unsupported encoding
- •Media type negotiation failure
415 errors are typically not relevant for SEO as they apply to API operations. However, proper content type handling improves API usability and prevents errors.
None of the ranges in the request's Range header field overlap the current extent of the selected resource.
Requesting a byte range that is beyond the size of the resource, or invalid range specification.
- •Include Content-Range header with current length
- •Indicate valid byte range
- •Provide clear error message
- •Support Range requests properly
- •Document range request behavior
- •Handle invalid ranges gracefully
- •Not including Content-Range header
- •Not indicating current resource size
- •Poor error messages
- •Not supporting Range requests
- •Incorrect Content-Range format
- •Not validating range before processing
The 416 (Range Not Satisfiable) status code indicates that none of the ranges in the request's Range header field overlap the current extent of the selected resource or that the set of ranges requested has been rejected due to invalid ranges. For byte ranges, failing to overlap the current extent means that the first-byte-pos of all of the byte-range-spec values were greater than the current length of the selected representation.
The client should check the resource size. The client should request valid byte ranges. The client should handle the error gracefully. The client may request the full resource instead.
The server must include a Content-Range header indicating the current length of the selected representation. The server should provide clear error message. The server should indicate valid range.
GET /large-file.zip HTTP/1.1 Host: example.com Range: bytes=1000000-2000000
HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */500000
Content-Type: application/zip
{"error": "Range Not Satisfiable", "message": "File is only 500000 bytes, requested range is beyond file size"}- •Byte range beyond file size
- •Invalid range specification
- •Range requests for non-existent bytes
- •Resume download with wrong range
- •Streaming with invalid ranges
- •Partial content requests failing
416 errors are typically not relevant for SEO as they apply to file downloads and streaming. However, proper range request handling improves user experience for large file downloads.
The expectation given in the request's Expect header field could not be met by this server.
The server cannot meet the requirements of the Expect request-header field.
- •Respond to Expect header quickly
- •Indicate why expectation failed
- •Support Expect: 100-continue when possible
- •Document Expect header support
- •Provide clear error messages
- •Handle gracefully without request body
- •Not responding to Expect header
- •Not indicating failure reason
- •Not supporting Expect: 100-continue
- •Poor error messages
- •Waiting for request body after failure
- •Not documenting support
The 417 (Expectation Failed) status code indicates that the expectation given in the request's Expect header field could not be met by at least one of the inbound servers. The server must send a 417 status code if it cannot meet the requirements of the Expect header field.
The client should not send the request body if Expect: 100-continue fails. The client may retry without Expect header. The client should handle the error gracefully.
The server should respond to Expect header promptly. The server should indicate why expectation failed. The server should not wait for request body if expectation fails.
POST /api/upload HTTP/1.1 Host: api.example.com Content-Length: 1000000 Expect: 100-continue
HTTP/1.1 417 Expectation Failed
Content-Type: application/json
{"error": "Expectation Failed", "message": "Server cannot meet Expect: 100-continue requirement"}- •Expect: 100-continue not supported
- •Server cannot meet Expect requirements
- •Proxy rejecting Expect header
- •Expectation negotiation failure
- •Server limitations preventing expectation
417 errors are typically not relevant for SEO as they apply to API operations with Expect headers. However, proper Expect header handling improves API reliability for large uploads.
This code was defined in 1998 as one of the traditional IETF April Fools' jokes. It's not expected to be implemented by actual HTTP servers.
A humorous response code from RFC 2324. Some servers use it for fun or as an easter egg.
The request was directed at a server that is not able to produce a response.
The request was sent to a server that is not configured to produce responses for the combination of scheme and authority.
The request was well-formed but was unable to be followed due to semantic errors.
Validation errors in form submissions, missing required fields, or invalid data format that passes syntax checks.
- •Include detailed validation errors
- •Use for semantic validation, not syntax errors
- •Provide field-level error information
- •Use consistent error response format
- •Document validation rules
- •Return all validation errors at once
- •Using 422 for syntax errors (use 400)
- •Not providing detailed error information
- •Using 422 for authentication (use 401)
- •Generic error messages
- •Not including field-level errors
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415 Unsupported Media Type status code is inappropriate), and the syntax of the request entity is correct (thus a 400 Bad Request status code is inappropriate) but was unable to process the contained instructions.
The client should fix the semantic errors in the request. The client should check validation error details in response. The client should not retry without modification.
The server should include detailed validation errors in response body. The server should indicate which fields failed validation. The server should provide actionable error information.
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"email": "invalid-email", "age": -5}HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json
{"error": "Validation Failed", "errors": {"email": "Invalid email format", "age": "Age must be positive"}}- •Validation errors in request data
- •Business logic validation failures
- •Semantic errors that pass syntax checks
- •Missing required fields
- •Invalid data relationships
- •Constraint violations
The resource that is being accessed is locked.
Used in WebDAV when trying to modify a resource that is currently locked by another user or process.
The request failed because it depended on another request and that request failed.
In WebDAV, when a request depends on another request that failed, this status is returned.
Indicates that the server is unwilling to risk processing a request that might be replayed.
The server is not willing to process the request because it might be a replay attack.
The server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol.
The server requires the client to upgrade to a newer version of the HTTP protocol.
The origin server requires the request to be conditional.
The server requires a conditional request header (like If-Match) to prevent the "lost update" problem.
The user has sent too many requests in a given amount of time ("rate limiting").
API rate limit exceeded, too many login attempts, or exceeding request quota within a time window.
- •Include Retry-After header indicating when to retry
- •Use for rate limiting and DDoS protection
- •Provide clear error message about rate limit
- •Consider implementing exponential backoff on client side
- •Not including Retry-After header
- •Using 503 Service Unavailable instead - 429 is more specific
- •Not providing clear rate limit information
The server is unwilling to process the request because its header fields are too large.
The total size of the request headers exceeds the server's limit, often due to too many or too large cookies.
The server is denying access to the resource as a consequence of a legal demand.
Content blocked due to government censorship, DMCA takedown, or legal restrictions in a specific region.
Server Error Responses
Indicates the server failed to fulfill a valid request.
The server encountered an unexpected condition that prevented it from fulfilling the request.
Application crash, database connection failure, unhandled exception, or server configuration error.
- •Use for unexpected server errors
- •Log detailed error information server-side
- •Don't expose sensitive error details to clients
- •Implement proper error handling and monitoring
- •Use 503 Service Unavailable for planned maintenance
- •Implement error tracking (e.g., Sentry, LogRocket)
- •Provide user-friendly error messages
- •Monitor 500 error rates and set up alerts
- •Exposing sensitive error details (stack traces, database errors)
- •Using 500 for client errors - use 4xx codes
- •Not logging errors for debugging
- •Using 500 for maintenance - use 503 instead
- •Not implementing proper error handling
- •Generic error messages that don't help debugging
- •Not monitoring 500 error rates
The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. This error response is a generic "catch-all" response. Usually, this indicates the server cannot find a better 5xx status code to response.
The client may retry the request after a delay. The client should not assume the request will succeed on retry. The client should handle 500 errors gracefully.
The server should log detailed error information for debugging. The server must not expose sensitive error details to clients. The server should implement proper error handling to prevent 500 errors.
GET /api/data HTTP/1.1 Host: api.example.com
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
{"error": "Internal Server Error", "message": "An unexpected error occurred. Please try again later."}- •Unhandled exceptions in application code
- •Database connection failures
- •Server configuration errors
- •Out of memory errors
- •Third-party service failures
- •Unexpected null pointer exceptions
- •Application crashes
Frequent 500 errors can significantly hurt SEO. Search engines may reduce crawling frequency or remove pages from index. High 500 error rates indicate site reliability issues. Implement proper error handling and monitoring.
The server does not support the functionality required to fulfill the request.
The server doesn't recognize the request method or lacks the ability to fulfill the request.
- •Use when method is not supported at all
- •Different from 405 - method not recognized vs not allowed
- •Include Allow header with supported methods
- •Provide clear error message
- •Document supported methods
- •Use for unimplemented functionality
- •Using 501 for method not allowed (use 405)
- •Not including Allow header
- •Confusing with 500 Internal Server Error
- •Not documenting supported methods
- •Generic error messages
- •Using 501 for temporary issues (use 503)
The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.
The client should not retry the request. The client should check if the method is supported. The client may check the Allow header if provided. The client should handle gracefully.
The server should indicate that the method is not implemented. The server may include an Allow header listing supported methods. The server should provide clear error message.
PATCH /api/resource HTTP/1.1 Host: api.example.com
HTTP/1.1 501 Not Implemented
Allow: GET, POST, PUT, DELETE
Content-Type: application/json
{"error": "Not Implemented", "message": "PATCH method is not supported by this server"}- •Server doesn't support the HTTP method
- •Method not implemented in server code
- •Legacy server not supporting newer methods
- •API endpoint doesn't support the method
- •Server configuration doesn't allow the method
- •Method not available for the resource
501 errors are typically not relevant for SEO as they apply to API operations. However, proper method support improves API usability and prevents errors.
The server, while acting as a gateway or proxy, received an invalid response from an upstream server.
A reverse proxy or load balancer received an invalid response from the backend server.
- •Monitor upstream server health
- •Implement proper error handling in gateway
- •Log upstream errors for debugging
- •Provide user-friendly error messages
- •Implement retry logic with backoff
- •Use health checks for upstream servers
- •Not monitoring upstream server health
- •Exposing upstream error details
- •Not implementing proper gateway error handling
- •Confusing with 500 Internal Server Error
- •Not logging gateway errors
The 502 (Bad Gateway) status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.
The client may retry the request. The client should handle 502 errors gracefully. The client should not assume the request will succeed on retry.
The gateway/proxy should log the invalid response from upstream. The gateway should provide user-friendly error message. The gateway should monitor upstream server health.
GET /api/data HTTP/1.1 Host: api.example.com
HTTP/1.1 502 Bad Gateway
Content-Type: application/json
{"error": "Bad Gateway", "message": "Upstream server returned an invalid response"}- •Reverse proxy received invalid response from backend
- •Load balancer got malformed response
- •Upstream server returned invalid HTTP
- •Gateway timeout before receiving complete response
- •Backend server crashed mid-response
- •Network issues between gateway and upstream
502 errors indicate infrastructure issues. Frequent 502s can hurt SEO. Ensure proper gateway configuration and upstream server health monitoring.
The server is currently unable to handle the request due to a temporary overload or scheduled maintenance.
Server is down for maintenance, overloaded with requests, or temporarily unavailable.
- •Include Retry-After header for planned maintenance
- •Use for temporary unavailability (maintenance, overload)
- •Different from 500 - indicates temporary condition
- •Provide user-friendly maintenance page when possible
- •Set appropriate Retry-After value
- •Monitor service availability
- •Use for planned maintenance windows
- •Using 503 for permanent errors - use 500
- •Not including Retry-After header
- •Using 500 Internal Server Error for maintenance
- •Not providing maintenance page
- •Setting Retry-After to unreasonable values
- •Using 503 for client errors
The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server may send a Retry-After header field to suggest an appropriate amount of time for the client to wait before retrying the request.
The client should retry the request after the delay indicated in Retry-After header. The client should implement exponential backoff if Retry-After is not provided. The client should handle 503 errors gracefully.
The server should include Retry-After header indicating when to retry. The server should provide a user-friendly maintenance page. The server should use 503 for planned maintenance, not 500.
GET /api/data HTTP/1.1 Host: api.example.com
HTTP/1.1 503 Service Unavailable Retry-After: 3600 Content-Type: text/html <html><body><h1>Service Temporarily Unavailable</h1><p>We are currently performing maintenance. Please try again in 1 hour.</p></body></html>
- •Planned server maintenance
- •Server overloaded with requests
- •Temporary service unavailability
- •Database maintenance
- •Deployment in progress
- •Rate limiting at infrastructure level
- •DDoS protection activated
503 errors tell search engines to retry later. Better than 500 for temporary issues. Include Retry-After header for planned maintenance. Search engines will retry crawling after the specified delay.
The server, while acting as a gateway or proxy, did not receive a timely response from an upstream server.
The upstream server took too long to respond, causing the gateway to timeout.
- •Set appropriate timeout values
- •Monitor upstream response times
- •Include Retry-After header when appropriate
- •Implement proper timeout handling
- •Use health checks for upstream servers
- •Consider async processing for long operations
- •Timeout values too short or too long
- •Not monitoring upstream performance
- •Confusing with 408 Request Timeout
- •Not including Retry-After header
- •Not implementing proper timeout handling
The 504 (Gateway Timeout) status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request.
The client may retry the request. The client should implement exponential backoff. The client should handle timeout errors gracefully.
The gateway should set appropriate timeout values. The gateway may include Retry-After header. The gateway should monitor upstream response times.
GET /api/slow-endpoint HTTP/1.1 Host: api.example.com
HTTP/1.1 504 Gateway Timeout
Retry-After: 30
Content-Type: application/json
{"error": "Gateway Timeout", "message": "Upstream server did not respond in time"}- •Upstream server taking too long to respond
- •Database queries timing out
- •Slow backend processing
- •Network latency between gateway and upstream
- •Upstream server overloaded
- •Long-running operations exceeding timeout
504 errors indicate performance issues. Frequent 504s can negatively impact SEO. Optimize upstream server performance and set appropriate timeouts.
The server does not support the HTTP protocol version used in the request.
The server doesn't support the HTTP version specified in the request (e.g., HTTP/3 when only HTTP/1.1 is supported).
- •Use when HTTP version is not supported
- •Include Upgrade header suggesting supported versions
- •Provide clear error message
- •Document supported HTTP versions
- •Use for version negotiation failures
- •Different from 426 Upgrade Required
- •Not indicating supported HTTP versions
- •Not including Upgrade header
- •Confusing with 426 Upgrade Required
- •Not documenting supported versions
- •Generic error messages
- •Not handling version negotiation properly
The 505 (HTTP Version Not Supported) status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, except for this error message.
The client should not retry with the same HTTP version. The client may try a different HTTP version. The client should check the Upgrade header if provided. The client should handle gracefully.
The server should indicate the HTTP version is not supported. The server may include an Upgrade header suggesting supported versions. The server should provide clear error message.
GET /api/data HTTP/3.0 Host: api.example.com
HTTP/1.1 505 HTTP Version Not Supported
Upgrade: HTTP/1.1
Content-Type: application/json
{"error": "HTTP Version Not Supported", "message": "Server only supports HTTP/1.1, not HTTP/3.0"}- •Client using HTTP/2 or HTTP/3 when server only supports HTTP/1.1
- •Server doesn't support the requested HTTP version
- •Legacy server not supporting newer HTTP versions
- •HTTP version negotiation failure
- •Server configuration limiting HTTP versions
- •Protocol version mismatch
505 errors are rare in modern web development. Most servers support HTTP/1.1 at minimum. Ensure server supports standard HTTP versions for better compatibility and SEO.
The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation.
A misconfiguration in content negotiation where the server cannot properly serve the requested variant.
The method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request.
The server is out of disk space or storage quota has been exceeded.
The server detected an infinite loop while processing the request.
In WebDAV, when a request creates an infinite loop in the server's processing logic.
Further extensions to the request are required for the server to fulfill it.
The server requires additional extensions to process the request that the client didn't provide.
The client needs to authenticate to gain network access.
Used by intercepting proxies to control access to the network, such as in public Wi-Fi hotspots requiring login.
Why HTTP Status Codes Matter for Monitoring
HTTP status codes are fundamental signals for monitoring web services and APIs. They indicate availability, detect failures, and provide critical information about the health of web infrastructure.
Monitoring tools rely on HTTP status codes to determine service availability. Status codes like 200 OK indicate successful responses, while 4xx and 5xx codes signal errors that require attention. Understanding these codes helps identify issues before they impact users.
For comprehensive monitoring of HTTP status codes and web availability, consider using external monitoring tools that verify reachability and track status code patterns over time.
References & Additional Resources
Learn more about HTTP status codes from authoritative sources and related monitoring tools.
Official References
Related UptimeMatrix Services
Monitor your HTTP status codes in real-time with our comprehensive monitoring platform.
Frequently Asked Questions About HTTP Status Codes
Common questions about HTTP status codes, their meanings, and best practices
What are HTTP status codes?
HTTP status codes are three-digit numbers returned by web servers to indicate the result of an HTTP request. They are grouped into five categories: 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error). Each status code provides information about whether a request was successful, redirected, or encountered an error.
What does HTTP status code 200 mean?
HTTP status code 200 OK means the request was successful. It is the most common success response, indicating that the server successfully processed the request and returned the requested resource. This status code is used for successful GET, POST, PUT, PATCH, and DELETE requests. Learn more about HTTP 200 OK.
What is the difference between 301 and 302 redirect?
301 (Moved Permanently) is a permanent redirect that tells search engines to update their index and transfer SEO value to the new URL. 302 (Found) is a temporary redirect that doesn't pass SEO value. Use 301 for permanent URL changes and 302 for temporary redirects. Modern best practice also includes 307 (Temporary Redirect) and 308 (Permanent Redirect) which preserve HTTP methods. Learn more about HTTP 301 redirects and HTTP 302 redirects.
What does HTTP 404 Not Found mean?
HTTP status code 404 Not Found means the server cannot find the requested resource. This is the most common error code, occurring when a URL doesn't exist, a file was deleted, or the URL was mistyped. Unlike 403 Forbidden, 404 indicates the resource doesn't exist, while 403 means the resource exists but access is denied. Learn more about HTTP 404 Not Found.
What is HTTP status code 500?
HTTP status code 500 Internal Server Error indicates the server encountered an unexpected condition that prevented it from fulfilling the request. This is a generic server error that can occur due to application crashes, database connection failures, unhandled exceptions, or server configuration errors. It's different from 502 Bad Gateway (upstream server error) and 503 Service Unavailable (temporary overload or maintenance). Learn more about HTTP 500 Internal Server Error.
How many HTTP status codes are there?
There are over 60 standard HTTP status codes defined in various RFCs. The most commonly used codes are in the 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error) ranges. This reference guide covers all standard HTTP status codes including informational (1xx), success (2xx), redirection (3xx), client error (4xx), and server error (5xx) codes with detailed explanations.
What HTTP status code should I use for API errors?
For API errors, use 400 Bad Request for validation errors or malformed requests, 401 Unauthorized for missing or invalid authentication, 403 Forbidden for authenticated users without permission, 404 Not Found for non-existent resources, 422 Unprocessable Entity for semantic validation errors, 429 Too Many Requests for rate limiting, and 500 Internal Server Error for unexpected server errors. Always include detailed error messages in the response body.
Do HTTP status codes affect SEO?
Yes, HTTP status codes significantly affect SEO. 200 OK responses are essential for indexing. 301 redirects pass SEO value to new URLs. 404 errors can hurt SEO if excessive. 410 Gone tells search engines content is permanently removed. 503 Service Unavailable with Retry-After tells search engines to retry later. Proper status code usage helps search engines understand your site structure and improves crawlability. Each status code entry in this guide includes SEO impact information.