HTTP Error Audit Example: 400 and 500 Errors Across 50 Pages

Nine errors across fifty pages reads like a single problem with a single severity. It is not. Three of these errors are costing money this minute, three are broken links dressed up as status codes, and three are working exactly as intended. Sorting them by what they actually mean is the entire job of reading this report.

Start by discarding the instinct that a low error count is the goal. It is trivially easy to reach zero: redirect every 404 to the homepage. That would remove the errors from the report and leave you with a site that lies to visitors, wastes their clicks, and produces soft-404 signals that Google will see through anyway. A 404 on a URL that genuinely does not exist is the correct answer, not a failure.

The three questions that matter for each error: is a real user hitting this, is something on your site linking to it, and does a better destination genuinely exist? Almost everything else in a status-code audit is noise.

Three server errors, all on the checkout path: 500 on payment, 502 on confirm, 503 on the thank-you page. Everything else in this report can wait a week. This cannot wait an hour, because every visitor who reached the point of paying you is being turned away by a server that will not answer.

The three codes tell you where to look and they are not interchangeable. A 500 is the application itself throwing — an unhandled exception in your own code. A 502 is a gateway or proxy that reached your application and got an invalid response, or none: the upstream process is down, crashed, or timing out. A 503 says the service is unavailable, and it is the only one of the three that can be deliberate, which is why it is also the one that gets forgotten in place after a maintenance window.

That all three appear together on consecutive checkout steps points at a single failure with three faces — most often a payment integration or a dependent service that has fallen over, taking the pages that call it with it. Read the application log for the 500 first; it will usually name the exception, and the other two will follow from the same cause.

One crawl consequence worth knowing, though it is a distant second to the revenue: sustained 5xx responses cause Googlebot to reduce its crawl rate, on the sensible assumption that a struggling server should be left alone. A long outage therefore degrades how often your whole site is fetched, and recovery of crawl rate lags the fix.

Two deleted products return 404 and both are linked from the product listing page. The listing page is the defect. A 404 is the honest answer for a URL that no longer exists; a page that keeps linking to it is a page that has not been updated, and every visitor who clicks that link is being sent nowhere by you.

So the first action is to remove or update the links. Then decide, separately, what should happen to the URLs.

Redirecting a dead product to the homepage is the tempting shortcut and the wrong one: it is not a relevant destination for the visitor, and Google frequently treats such redirects as soft 404s regardless. The 410 already in your sitemap is a smaller version of the same inconsistency — it correctly says the page is gone while the sitemap continues to nominate it for crawling. Remove it from the sitemap and the two statements agree.

A crawler reporting 403 on /account/orders has discovered that a logged-out client cannot read a logged-in user's orders. That is the system working. The same goes for a 429 on an API endpoint that rate-limits automated submissions — it is a defence, and it fired.

Both are worth two minutes of thought before dismissal. If the account pages are linked from public navigation, a crawler will keep fetching them and getting refused, which is wasted crawl and a slightly confusing experience for a logged-out visitor who clicks. Either accept that or exclude the private area in robots.txt — bearing in mind that a robots.txt disallow prevents crawling but does not prevent a URL being indexed without content if enough pages link to it, and that anything genuinely sensitive must be protected by authentication, which it already is.

The 429 deserves a check of a different kind: confirm that the limit only ever fires for automated clients and never for a real person submitting a review. Rate limiters that are slightly too aggressive fail silently, because the user who was blocked does not file a bug report — they leave.

The four redirects in this report are working. The advice to point internal links at the final destination is right, and the reason usually given for it is wrong, so it is worth stating clearly.

Redirect hops do not leak link equity. Google has said that no PageRank is lost through a 301 or a 302, and the difference between those two codes concerns which URL gets indexed, not how much value is transferred. The "each hop loses 15%" figure that circulates in SEO advice describes an old model and does not describe current behaviour.

What chains genuinely cost you is real: latency, since every hop is another round trip for a person on a phone; crawl budget, since every hop is a fetch that could have gone to a page you want indexed; and fragility, since Google abandons a chain after roughly ten hops and chains grow silently over years of site changes until one day the destination is unreachable and nobody notices.

So: update the internal links to point straight at /products/, keep the redirect in place as a safety net for external links you do not control, and collapse any chain longer than one hop when you find it. Do it for the users and the crawler, not for a fictional evaporating equity.