Quick answer
HTTP status codes describe what happened when a browser or crawler requested a URL. 2xx usually means success, 3xx means redirect, 4xx means the request or resource could not be served as requested, and 5xx means the server failed while handling the request. In an SEO audit, read the status together with the final URL, redirect chain, page purpose, and whether the response is intentional.
What the issue means
The first response and the final response can differ. A request for /old-page may return 301 and lead to /new-page, which returns 200. A URL can also return 404 intentionally, or return 200 with a not-found message, which is a soft-404 concern rather than a genuine 404 response.
Useful classes and examples:
| Class | Examples | Typical meaning |
|---|---|---|
| 2xx | 200, 204 | The request succeeded; a document page normally needs a usable body. |
| 3xx | 301, 302, 307, 308 | The client should use another URL or repeat the request differently. |
| 4xx | 400, 401, 403, 404, 410, 429 | The request or access to the resource failed. |
| 5xx | 500, 502, 503, 504 | The server or an upstream dependency failed. |
Why it matters for SEO
Search systems need reliable responses to retrieve and process public pages. Unexpected errors, long redirect chains, and inconsistent responses can make important content difficult to reach. An intentional 404, a protected 401, and a temporary 503 can each be correct when they match the site's purpose.
Status codes do not carry a ranking score by themselves. The practical question is whether the response helps a user or crawler reach the right content at the right URL.
How NOTABIS detects it
NOTABIS records the status and final URL for requests it crawls. An error response can produce the http-error finding; a link to that response can additionally produce broken-internal-link. Redirected pages and chains are reported separately so the requested and final responses remain visible.
The observation is specific to the request and crawl conditions. Authentication, rate limiting, edge controls, and transient failures can change the response another client receives.
How to check it yourself
Inspect the document request in browser developer tools, or use curl:
curl -sS -D - -o /dev/null https://example.com/page
curl -sS -L -D - -o /dev/null https://example.com/page
Record the initial status, every Location, the final status, response headers, and whether the body matches the status. Then search internal links and sitemaps for references to the URL.
How to fix it
Choose the response that matches the URL's purpose. Restore a page that should exist, redirect a moved page to the closest relevant replacement, remove links to content that is gone, keep authentication responses for private routes, and repair the dependency behind a 5xx. Avoid redirecting every error to the homepage or returning 200 for missing content.
Re-test the final URL and affected internal links, then re-run the audit.
When this is intentional or does not need fixing
Intentional removals, private endpoints, rate limits, and short maintenance windows can use error responses correctly. Record the reason and ensure public navigation and sitemaps do not promise content that is unavailable.
Related issues
Read HTTP error responses, redirected pages, redirect chains, and broken internal links. Google’s HTTP status-code guidance explains how response classes affect crawling and indexing. For edge-related responses, see edge and bot blocking.
Run a NOTABIS audit
Run a NOTABIS SEO audit to see the status, final URL, redirect evidence, and internal links measured for your crawled pages.