A 4xx or 5xx status code is the one signal a browser, a search engine and a crawler all read the same way: the page failed. Everything else about a page, its content, its links, its title, only matters once it has actually loaded, and a failed status code means it never did.
What this finding means
Crawl Cove's status-code check reads the HTTP status already recorded on every fetched page and flags any server error (5xx) and any client error (4xx) except the ones that now have checks of their own: a 404 is reported by status-code-404 at High, a 410 by status-code-410 at Medium, and a request the crawl has evidence was never really answered by status-code-not-checked at Low.
A real finding looks like this:
HTTP 403
or, for a server-side failure:
HTTP 500
Redirects are deliberately out of scope: a page that returns a 3xx and lands on a working page is healthy for this check. So is a transport-level failure with its own separate handling, and a small set of statuses the check has learned not to treat as the page's fault:
- 429 (rate limited): the server asked the crawler to slow down; the page itself was never actually checked, so this reads as a low-severity note, not a dead page.
- 403 from proven bot protection: where the same crawl has already shown this origin refuses the crawler under every user agent it owns, the door was shut before the page could be checked at all.
- A timeout: the server never answered in time. That is reported as a slower, separate issue, because a page that is merely slow to respond is not the same problem as one that actively rejects the request.
Every other 4xx or 5xx is reported as critical, because the server did answer, and the answer was a failure. A 404 is a High finding rather than a Critical one, because a missing page is usually a broken link to fix rather than a site that is failing.
Why it matters
Search engines treat a 4xx or 5xx response the same way a browser does: as a failure to serve the page. A page that errors loses any ranking and any links it had earned, and every visitor who follows a link to it, from a search result, a bookmark or another page on your own site, lands on a dead end instead of content. Left unfixed, a 5xx also tells crawlers your server is unreliable, which can slow how often they come back to check anything else.
How to fix it
- Open the URL directly and read the actual response, not just what renders. Dev tools' Network tab (or
curl -I) shows the real status code; a friendly error page can still be serving 200 underneath, which is a different problem (see Soft 404). - For a 4xx (client error), decide whether the page should exist. If the content moved, add a redirect to its new location. If it is genuinely gone, either restore it, replace it with a real 410, or remove the links pointing at it, on your own site and anywhere you control.
- For a 5xx (server error), this is your server failing to answer, not a missing page. Check server or application logs for the actual exception, and look for the usual causes: an unhandled error in the code serving that route, a dependency (database, API, cache) that is down or timing out, or the server being overloaded.
- Re-crawl the page once the fix is live to confirm it now returns a real 200.
False positives and edge cases
- A 429 or a bot-protection 403 is not treated as a dead page. Both mean the page was never actually checked, not that it failed, so they carry a low-severity note rather than a critical finding.
- A timeout is not the same as an error status, and is reported separately: the server may simply be slow, not broken.
- Redirects are always out of scope here, however many hops they take, provided the final destination is a working page.
- An intentional 410 for permanently removed content is reported at Medium, by its own check. A 410 is often the correct answer for a page you removed on purpose, so the fix it points at is the links and sitemap entries still pointing to it, not the page.
Related reading
For the opposite problem, a page that answers 200 when it should not, see Soft 404: What It Means and How to Fix It. For a server that is merely slow to answer rather than failing outright, see Slow Server Response Time On a Crawled Page.
Google documentation: How HTTP status codes affect Google’s crawlers
Frequently asked questions
- Is this the same as a soft 404?
- No, and they are opposite problems. A soft 404 is a page that answers 200 when it should not, hiding a missing page behind a healthy-looking status code. This check is the reverse: a page that genuinely returns a 4xx or 5xx status. See Soft 404: What It Means and How to Fix It for that separate check.
- Does this include redirects?
- No. A 3xx redirect is explicitly out of scope here; a page that redirects and then lands on a real 200 is healthy for this check. Redirect chains and loops are covered separately.
- Are 429 and 403 always reported as critical?
- No. A 429 (rate limited) or a 403 that a crawl has proven is bot protection, not a real permission problem, means the page was never actually checked, so it is reported as a low-severity note rather than a critical dead page. The page usually loads fine in a browser; only a genuine 4xx or 5xx on a request the server actually answered is reported as a failure: Critical for most, High for a 404 and Medium for a 410.
- What about a page that times out instead of returning a status?
- A timeout means the server never answered in time, not that it rejected the request. It is reported by its own check, status-code-timeout, at High severity rather than as a critical error, because the page may well load fine given longer to respond.