HTTP Status Codes Website Owners Should Monitor

Every time a browser or search crawler requests a page from your server, the server responds with a three-digit status code. Under RFC 9110, valid status codes are integers from 100 to 599; the first digit defines the response class, and the remaining two digits have no categorization role. Understanding these classes is the foundation for reading server logs and search diagnostics.

How HTTP Status Codes Are Organized#

RFC 9110 divides status codes into five standardized classes:

• 1xx (Informational): an interim response communicating connection status or progress before the final response.
• 2xx (Successful): the request was successfully received, understood, and accepted.
• 3xx (Redirection): further action must be taken by the user agent to fulfill the request.
• 4xx (Client Error): the request contains bad syntax or cannot be fulfilled due to a client-side issue.
• 5xx (Server Error): the server failed to fulfill an apparently valid request.

The IANA HTTP Status Code Registry lists the assigned codes and the RFCs that define them. RFC 9110 also requires clients to recognize the class indicated by the first digit: an unrecognized code such as 471 is treated as the x00 code of its class, here 400 Bad Request.

Successful Responses: 2xx#

• 200 OK means the request succeeded.
• 201 Created means the request was fulfilled and one or more new resources were created.
• 204 No Content means the server fulfilled the request and sends no additional message body.

According to Google's crawling documentation, content returned with 2xx codes may be considered for indexing, which is not guaranteed; 204 is an exception because it supplies no content to process. If a page returns 200 but its content represents an error or an empty page, Search Console reports it as a soft 404 — a pattern worth reviewing when URLs that should not exist still return success codes.

Redirection Responses: 3xx#

• 301 Moved Permanently signals that the target resource has been assigned a new permanent URI.
• 302 Found signals that the resource resides temporarily under a different URI.
• 304 Not Modified tells the client that a conditional request evaluated to false and its cached representation remains valid.
• 307 Temporary Redirect requires the user agent to preserve the HTTP method when redirecting. 308 Permanent Redirect signals a new permanent URI.

Google's crawlers follow up to 10 redirect hops by default, ignore the content at redirecting URLs, and process the destination URL's content instead. Google treats 301 and 308 as strong signals to process the redirect target, and 302 and 307 as weak signals. A 304 response tells the crawler that content has not changed since the last crawl.

Client Errors: 4xx#

• 400 Bad Request means the server cannot process the request due to what it perceives as a client error, such as malformed syntax or invalid framing.
• 401 Unauthorized means the request lacks valid credentials; RFC 9110 requires the server to send a WWW-Authenticate challenge header.
• 403 Forbidden means the server understood the request but refuses to fulfill it.
• 404 Not Found means the origin server found no current representation, or declines to disclose that one exists.
• 410 Gone means access to the resource is no longer available at the origin server and this condition is likely to be permanent.

Per Google's guidance, content from 4xx URLs, except 429, is ignored and not indexed. URLs already indexed that begin returning these 4xx codes are gradually removed from the index, and crawling frequency decreases. The overload handling for 429 is covered below.

Server Errors: 5xx#

• 500 Internal Server Error means the server encountered an unexpected condition that prevented it from fulfilling the request.
• 502 Bad Gateway means a gateway or proxy received an invalid response from an upstream server.
• 503 Service Unavailable means the server is temporarily overloaded or in maintenance; it may include a Retry-After header.
• 504 Gateway Timeout means a gateway or proxy did not receive a timely response from an upstream server.

Google additionally treats 429 Too Many Requests as a server error signaling overload. For 5xx and 429 responses, crawlers temporarily slow their crawl rate. Indexed URLs are temporarily retained but dropped if server errors persist, and crawl rates recover gradually once 2xx responses return.

Questions to Check on Your Own Setup#

• Does your hosting platform or web server give you access to raw access logs or real-time status code reporting?
• Have you reviewed Search Console for unexpected 4xx errors, soft 404s, or sustained 5xx spikes?
• Are your redirect chains kept under the 10-hop default across desktop and mobile versions of your site?
• During planned maintenance windows, is the server configured to return 503 with a Retry-After header rather than a generic 500?
• If you use a reverse proxy or CDN, have you checked its logs to distinguish invalid upstream responses (502) from upstream timeouts (504) before investigating the cause?