HTTP responses 8 min read Updated August 2026

HTTP status codes, server errors, and real 404 pages

The response code is the server’s machine-readable account of what happened. The report checks the tested page and a deliberately nonexistent URL so that a branded error template returning 200 cannot masquerade as a healthy page.

At a glance

The body and the status code must tell the same story

Return 2xx for content that exists, a suitable 3xx when it moved, 404 or 410 when it is gone without a replacement, and 5xx only for genuine temporary server failures. A friendly error design does not replace the correct protocol status.

  • A tested report URL must finish with a successful HTML response.
  • Return a real 404 or 410 for missing content.
  • Redirect only when a close replacement actually exists.
  • Investigate recurring 5xx and network failures before SEO details.
01

Read status families by intent

  • 2xx success The request was handled. For a normal indexable page, 200 with a useful HTML body is expected.
  • 3xx redirection The client must look elsewhere. Validate permanence, destination, path preservation, and chain length.
  • 4xx client-side outcome The requested resource is unavailable or access is not allowed, such as 404, 410, 401, or 403.
  • 5xx server failure The server or gateway could not complete a valid request; repeated failures damage availability and crawling.
02

Real 404 versus soft 404

A real missing URL returns 404 or 410 even if its HTML contains navigation, search, and helpful links. A soft 404 returns 200, redirects every unknown path to the home page, or serves a thin error-like body while claiming success.

The report requests a randomized path on the same host. If the site returns a success response or an unrelated redirect, routing, cache fallback, SPA history handling, or CMS configuration is probably swallowing missing routes.

03

Triage failures before continuing an audit

DNS failures, refused connections, TLS errors, timeouts, and final 4xx or 5xx responses mean the requested page was not delivered normally. Fix availability first because metadata and content findings from an error page are not representative.

For intermittent 5xx responses, correlate timestamps with application, proxy, CDN, and origin logs. Check capacity, upstream timeouts, deployment health, and whether security rules are blocking ordinary anonymous requests.

Action checklist

Make every outcome explicit

  1. 01Confirm the tested page ends on 200 HTML without an error message.
  2. 02Request several random nonexistent URLs and verify 404 or 410.
  3. 03Remove blanket redirects from missing paths to the home page.
  4. 04Map legitimate moved URLs individually to close replacements.
  5. 05Trace recurring 5xx, TLS, DNS, and timeout failures through every layer.

Official references

The technical recommendations in this guide are aligned with these primary sources.