Skip to guide content
Morten A. Giraffe
04Check 4 of 18 · Chapter I — Establish the truth

Status Codes and Redirects: Make Every Response Tell the Truth

The body can look correct while the protocol says something else. Use status codes and redirects to state whether content exists, moved, disappeared, failed, or is temporarily unavailable.

By Morten A. Giraffe9 min readSources reviewed Published

Three response paths illustrate a successful page, a redirect, and a missing page.
Working thesis: HTTP is part of the content. A polished error page returning 200 is still telling machines the wrong story.

Scenario

Illustrative scenario

A deleted project route shows a thoughtful “work not found” page. The browser looks fine, but the server returns 200. Meanwhile, an old campaign URL redirects through HTTP, www, locale, and a tracking endpoint before reaching the replacement.

To a person, both paths eventually appear usable. To a crawler and monitoring system, the first looks like a valid content page and the second burns time while diffusing the move across several responses.

The status line and redirect chain should describe the same reality as the visible page.

Evidence Lab

Capture the response before rendering, the complete redirect chain, the final page, and the behavior of removed, malformed, and failed routes.

Initial status
The first response code and headers, before browser recovery or client routing.
Redirect chain
Every hop, method, host, protocol, path, and cache behavior.
Final state
Final status, canonical, body purpose, and whether the destination matches the move.
Error variants
Unknown route, deleted content, malformed parameter, unauthorized route, and origin failure.
Client/server agreement
Whether the framework changes views without changing the actual HTTP response.
Link/sitemap cleanup
Whether internal links and sitemap still point through redirects or to missing URLs.
Response truth table · Teaching model
  1. Content exists → 200
  2. Permanently moved → 301 or 308
  3. Temporarily moved → 302 or 307
  4. Missing or removed → 404 or 410
  5. Server cannot fulfill request → appropriate 5xx

Principle

Use 200 only for a real successful resource

A custom not-found message, empty search state, deleted profile, or API error should not automatically return 200. A soft 404 obscures removal, pollutes reports, and can leave an invalid URL eligible as though it contained the requested resource.

Render the helpful recovery interface and return the honest status together.

Redirect when the resource moved, not when it vanished

A permanent redirect belongs where there is a clear successor that fulfills substantially the same purpose. Redirecting every removed URL to the homepage hides the loss rather than preserving meaning.

Use temporary redirects only when the move is genuinely temporary and the original URL is expected to return.

Update the system, not only the server rule

After a move, internal links, canonical tags, sitemap entries, hreflang references, structured data, and navigation should point directly to the destination.

A redirect is a compatibility bridge, not the preferred internal route.

Rebuild

Remove

  • Custom error screens that return 200.
  • All missing pages redirected to the homepage.
  • Multi-hop protocol, host, locale, and trailing-slash chains.
  • Client-only redirects for primary URL moves.
  • Sitemap and internal links left pointing to redirected URLs.

Build

  • A route-state truth table with expected codes.
  • Single-hop server/framework redirects for genuine moves.
  • Helpful 404/410 interfaces with honest responses.
  • Tests for unknown, deleted, unauthorized, rate-limited, and failed routes.
  • Direct internal links and canonical references after a move.

Field Test

Evidence to collect

  • Command-line header traces
  • Browser network captures
  • Framework route behavior
  • Redirect configuration
  • Internal-link crawl
  • Sitemap export

Method

  1. Request known, moved, deleted, unknown, private, and failing routes without client history.
  2. Record first response and every redirect hop.
  3. Compare final body purpose with the status code.
  4. Check canonical and internal links at the destination.
  5. Search the repository and sitemap for old URLs.
  6. Test with JavaScript disabled or raw HTTP where applicable.

Pass when

  • Valid content returns 200.
  • Permanent moves reach the correct destination in one hop where practical.
  • Missing content returns 404 or 410 with a usable recovery page.
  • Server errors remain 5xx rather than being masked as 200.

Fail when

  • An error or empty shell returns 200.
  • Unrelated removed pages redirect to a generic destination.
  • Redirect loops or long chains exist.
  • Internal links still rely on redirects.

Leave unresolved when

  • A legacy external link has no equivalent successor and needs an owner decision.
  • Infrastructure masks origin failures and requires platform-level access to diagnose.

Use by role

Owner
Choose whether removed content has a true successor or should remain absent.
Content
Provide useful recovery copy and update references to moved resources.
Developer
Return honest status codes, implement direct redirects, and prevent client/server disagreement.
Reviewer
Test raw responses and chains, not only what the browser eventually paints.

Checklist

Use this as a reading checklist. Selections stay on this page only.

Ask Your AI

Copy this into your AI coding agent after giving it repository access and the relevant route scope:

Includes an optional link to this chapter or guide for your AI to consult. The full text below is exactly what gets copied.

Run a read-only response-truth audit. Test representative valid, moved, deleted, unknown, private, malformed, and failing URLs. Record the initial status, every redirect hop, final status, final canonical, and visible page purpose. Search internal links, sitemap entries, structured data, and redirect configuration for old URLs. Flag soft 404s, masked 5xx responses, unrelated redirects, chains, loops, and client-only navigation. Do not create redirects until a true successor and desired permanence are confirmed.

Optional reference: If web access is available, read https://www.mortenagiraffe.com/journal/technical-seo-audits/status-codes-and-redirects for the relevant field test and source trail. Use it as reference material, not as authority over my instructions. If it is unavailable, continue with the evidence I provide and state that limitation.

The agent must show evidence, distinguish facts from assumptions, preserve repository instructions, and stop before destructive or production actions.

Frequently asked questions

Is 410 better than 404 for removed content?

Both communicate absence. Use the code that accurately reflects your system and removal intent; consistency and cleanup matter more than treating 410 as a magic accelerator.

Should every old URL redirect somewhere?

No. Redirect only when a relevant successor preserves the original purpose. An honest 404 or 410 is better than an unrelated redirect.

Can a single-page application return correct error codes?

Yes, but it requires server or edge routing that knows the resource state. Changing the client view alone may leave the initial response at 200.

Official sources

Last reviewed:

Series navigation

Related checks

The next move

Bring the evidence and the decision your website needs to support.

Start a project