What an HTTP status code tells you
Every time a browser or a search engine asks for a page, the server answers twice: once with the content, and once with a code that describes what kind of answer this is. Visitors never see the code, but it decides what happens next — whether the browser shows the page, follows a redirect somewhere else, or displays an error. Search engines read it as an instruction about what to do with the address.
The codes fall into families. Replies in the two hundreds mean the request succeeded. Replies in the three hundreds mean the content is somewhere else and give the new location. Replies in the four hundreds mean the request was wrong or the page is gone. Replies in the five hundreds mean the server itself failed. The ones that matter in marketing work are a short list:
- 200 — the page exists and was returned normally.
- 301 — moved permanently; follow this new address from now on.
- 302 — moved temporarily; keep using the original address.
- 404 — not found, with no statement about whether it might return.
- 410 — gone deliberately and not coming back.
- 500 and 503 — the server broke, or is unavailable right now.
Why status codes matter
They are how you tell a search engine what to keep. A permanent redirect passes the value of an old address to its replacement; a temporary one asks the engine to hold on to the original. Get that pair the wrong way round during a site rebuild and rankings built over years sit on addresses that no longer exist.
They also expose problems no report will otherwise show. A page that looks like an error to a visitor but returns a success code is invisible to monitoring, so broken sections stay live for months. Repeated server failures during a crawl make an engine slow down and come back less often, which delays everything you publish.
Common mistakes with status codes
The most expensive is redirecting everything that moved to the homepage. It looks tidy and it destroys relevance, because the new destination does not answer the question the old page answered; engines often treat those redirects as if the page were simply missing. Redirect each address to its closest genuine equivalent instead.
Chains are the next problem: one address pointing to a second, which points to a third. Each hop wastes crawl effort and some value, and chains grow silently over successive redesigns. Then there are error pages that reply with a success code — a friendly “sorry, nothing here” page that technically claims to be a real page, so it gets crawled and sometimes indexed. Blocking a dead section in robots.txt has the same effect from the other direction: the engine cannot see the error, so it keeps the address in mind.
How to act on it
Crawl your own site regularly and sort by response, because that single view finds broken links, accidental temporary redirects and chains faster than any manual check. Google Search Console reports what the engine itself received, which is worth comparing against the crawl.
When addresses change, build a one-to-one map before anything goes live and use permanent redirects, as covered under 301 redirects. Keep the not-found page useful, with search and links onward, but make sure it genuinely reports as missing. Retire content you truly want gone with the deliberate “gone” code rather than leaving a soft error behind. Monitoring for server failures belongs in the same routine as the rest of your technical SEO checks.