What a status code tells you
When a browser, crawler, or API client requests a URL, the server returns headers and usually a response body. The three-digit status code is the broad result of that request. The first digit groups it as informational, successful, a redirect, a client-side problem, or a server-side problem.
The code is only one part of the evidence. A 200 response may still contain an error message in the page, and a 500 response may be caused by a small configuration mistake. Read the URL, response headers, timing, and body together before deciding what to change.
The 2xx family means success
The most familiar successful response is 200 OK: the server handled the request and returned a representation of the resource. A 201 Created is common after an API creates a record, while 204 No Content means the request succeeded but there is no body to return.
A successful code does not guarantee that a page is useful or that an API returned the fields your application expects. For a website, inspect the rendered page and canonical URL. For an API, validate the response shape and confirm the operation really completed.
The 3xx family changes the next step
Redirects tell a client to use another URL or another representation. A 301 is a permanent redirect, while a 302 is traditionally temporary. A 307 and 308 preserve the request method more strictly, which can matter for forms and APIs.
Redirects are useful when a page moves, a host is consolidated, or HTTP is sent to HTTPS. Problems begin when redirects form a chain, loop, or send every retired page to an unrelated homepage. Test the old URL and confirm it reaches the final destination in one clear hop.
The 4xx family needs a request review
A 400 Bad Request usually means the server could not understand the request. A 401 indicates missing or invalid authentication, while 403 means the server understood the request but will not allow it. A 404 means the requested resource was not found, and 405 means the method is not allowed for that endpoint.
These codes are not always the visitor’s fault. A broken internal link creates a 404, an expired session can create a 401, and an incorrect permission rule can create a 403. Reproduce the request, check the exact path and method, and review the application or server logs.
The 5xx family points to the server
A 500 Internal Server Error is a general application failure. A 502 usually means a gateway received an invalid response from an upstream service, while a 503 suggests the service is unavailable or overloaded. A 504 means a gateway waited too long for an upstream response.
For a site owner, start with recent deployments, PHP or application logs, database connectivity, resource limits, and upstream services. Check whether the error affects every URL or only one feature. A single failing integration needs a different response from a host-wide outage.
Use the browser and command line as witnesses
A browser is useful because it shows what a normal visitor experiences, but it may hide intermediate redirects or cache behavior. Test with a fresh private window and inspect the network panel when you need the exact request sequence, response headers, and timing.
Run the same URL through the Server Status Checker or URL Redirect Checker for a quick external view. Compare results from more than one network when a problem may involve DNS, a CDN, or a regional edge. Save the response headers and time so another person can reproduce the finding.
Fix the cause, not the symptom
If a page returns 404 because the URL was intentionally retired, add a useful redirect or a clear 410 when no replacement exists. If the page should exist, restore the correct route or fix the internal link. Sending every error to the homepage hides the problem and gives visitors a confusing destination.
If a 500 follows a code change, roll back only when that is an approved recovery action and keep the error evidence. Then fix the underlying issue, test the route, and verify adjacent features. A quiet error page is not the same as a healthy application if failures are being swallowed.
Build a small response checklist
For each important URL, record the expected status, final URL, HTTPS behavior, page title, canonical, and a basic page-size or performance check. Revisit the list after migrations, domain changes, framework updates, and hosting changes.
Good monitoring alerts on meaningful changes rather than every normal request variation. Watch for a rise in 404s, redirect loops, 5xx responses, slow upstream calls, and failed forms. Status codes become most useful when they are connected to an owner and a clear next action.
Remember caches and intermediaries
The server you think you are testing may not be the component that produced the response. A CDN, reverse proxy, browser cache, load balancer, or security layer can redirect, cache, challenge, or replace an origin response. Check response headers for cache clues and compare a fresh request when the result seems inconsistent.
After fixing an origin problem, confirm that the public edge has received the new response. A stale error can remain visible after the application is healthy, while an aggressively cached success can hide a new failure. Record the host, path, time, and cache headers whenever you report an intermittent status issue.
Make error pages useful
A visitor who reaches a 404 or temporary 503 still deserves a clear explanation and a sensible next action. Keep the message short, preserve the site navigation, offer a search or relevant link, and avoid exposing stack traces, database details, or internal filenames. A helpful error page turns a dead end into a recovery path.
For APIs, return a predictable error shape with a status, a safe message, and a request identifier when support staff need to trace the event. Do not put secrets or sensitive diagnostics in the public response. The goal is to give a user or developer enough information to proceed without turning the error into another security problem.
Put this into practice
Use the free GigaTools toolkit
Run a check, review the result, and make one useful improvement at a time.
Quick answers
Frequently asked questions
Is a 404 always bad?
No. A 404 is appropriate when a resource does not exist, but important pages should not return it accidentally. Review internal links, external references, and whether a relevant replacement should receive a redirect.
What is the difference between 301 and 302?
A 301 communicates a permanent move, while a 302 is generally used for a temporary change. Choose based on intent and test that the redirect reaches the correct final URL.
Why can a page show an error with status 200?
Some applications return a normal success code while displaying an error inside the page. That is a soft error and can confuse visitors, monitoring systems, and crawlers.