HTTP Status Codes Explained: What Website Owners Need to Know
Every time someone opens a web page, their browser sends an HTTP request and the server returns a three-digit status code. Most visitors never see that code when everything works, but it becomes essential when a page redirects unexpectedly, disappears from search results or displays an error.
Understanding HTTP status codes helps website owners distinguish normal behaviour from problems that need attention. The first digit identifies the broad result: informational, successful, redirected, client error or server error.
2xx Means the Request Succeeded
A 2xx response indicates that the server successfully received and handled the request. The most familiar example is 200 OK, which is the expected response for an accessible web page.
Other successful responses have more specific purposes. A 201 response commonly follows the creation of a resource through an API, while 204 means the request succeeded but there is no content to return. Website monitoring should normally expect a 200 response for public pages unless another successful code is intentional.
3xx Codes Control Redirects
Redirects tell browsers and search engines that a resource is available at another address. A 301 redirect indicates a permanent move, while 302 and 307 are commonly used for temporary redirection. A 308 preserves the original request method during a permanent redirect.
Redirects are useful after changing a URL or moving to a new domain, but long redirect chains add delay and make troubleshooting harder. After changing redirect rules, test both the original address and the final destination. The curl examples in our Linux command guide provide a quick way to inspect response headers and follow redirects.
4xx Codes Usually Point to the Request
A 4xx code means the server received the request but could not fulfil it because of something associated with the request or the requested resource. A 404 response means the resource was not found. A 403 means access is forbidden, while 401 indicates that authentication is required.
Not every 404 is an emergency. Automated scanners regularly request nonexistent files. However, internal links leading visitors to missing pages should be fixed or redirected. A sudden increase in 404 responses can reveal a broken deployment, deleted content or an incorrect URL structure.
5xx Codes Indicate Server-Side Failure
A 5xx response means the server failed while handling an otherwise valid request. A 500 code is a general internal server error. A 502 often indicates that a proxy received an invalid response from an upstream application, while 503 means the service is temporarily unavailable. A 504 points to an upstream timeout.
These errors may be caused by exhausted resources, application failures, database problems or unavailable upstream services. Check server and application logs before restarting components. Restarting may restore service temporarily while hiding the underlying cause.
Monitor the Correct Response, Not Just Availability
A server can accept connections and still return an error page. Effective monitoring should verify the expected status code, response time and, when appropriate, page content. Our guide to website monitoring beyond uptime explains why several checks are needed for a reliable picture.
Set alerts around meaningful changes rather than treating every non-200 response identically. A planned 301 redirect is different from a persistent 500 error, and a protected page may correctly return 401.
Use Status Codes as a Starting Point
The status code identifies the response category, not always the root cause. Combine it with headers, logs, DNS checks and application metrics. This approach narrows the investigation without jumping to conclusions.
For the formal definitions and complete list, consult the HTTP status code section of RFC 9110.
