What Are HTTP Status Codes in SEO?
Organised by what each one means for your business rather than by number, because you do not care what a code denotes. You care whether a page has gone, whether somebody is arriving at it and whether anything needs doing about it.
A Code Is The Server Answering A Question
Every request for a page gets a response saying what happened. These codes are those responses. They are how machines learn the state of a page without having to read it.
What the exchange is. A question and an answer.
Something asks for an address. The server answers with a short code saying whether it worked, then usually sends the page. The code arrives before the content and is separate from it.
Why they exist. Machines cannot infer.
A person seeing a page saying nothing found understands it immediately. Software needs to be told, which is what the code does before any content is examined.
Why they matter for search. They are believed.
A crawler acts on what the code says rather than on what the page displays. If those two disagree, the code wins, which is the entire subject of block six.
How they are grouped. By outcome.
Broadly: it worked, it has moved, the request was wrong, else the server failed. Those four outcomes are what this page is organised around.
Where you meet them. Reports, mostly.
Few businesses encounter these directly. They arrive as a list in a report or in something a supplier has sent, which is why the useful question is not what each one means but which of them deserves anybody's afternoon.
Why this page has no table. A lookup is not an answer.
A list of numbers with definitions tells you what a code is called. It does not tell you whether you have a problem, which is the only reason anybody is reading this. Anybody who genuinely wants a lookup has the specification.
When A Page Is Returned Normally
The success response means the page was found and sent. It says nothing whatsoever about whether the page is any good, which is a distinction worth holding on to.
What it confirms. Delivery.
The address exists, the server had something for it and that something was sent. Almost every page on a working site answers this way, which is why it is rarely discussed.
What it does not confirm. Anything about quality.
A page with nothing useful on it, a page with an error message written into it and a page that is genuinely excellent all return the same response. The code cannot tell them apart.
Why that qualification matters. It sets up the worst case.
A page returning success while showing nothing is the most confusing situation in this whole subject, because nothing reports a problem. Block six covers it properly.
When it is worth checking. After changes.
Confirming your important pages still answer normally after a rebuild or a platform change. Quick to check and occasionally revealing.
Why it is worth naming at all. It anchors the rest.
Every other situation on this page is a departure from this one. Knowing that the normal answer says only that something was delivered makes the abnormal answers easier to place, particularly the one in block six.
What people misread. A clean report.
A site where everything returns success looks healthy in a report. That is the floor rather than the objective. It says nothing about whether the pages deserve to be found.
Permanent And Temporary Redirects
Both send a visitor somewhere else. The difference is what they claim about the future. Using the temporary one for a permanent move is a common and consequential error.
What a permanent redirect says. This has moved for good.
The old address is finished and the new one replaces it. That is a statement about intent, inviting everything to update its understanding to the new address.
What a temporary one says. Come back later.
The old address is expected to return, so the original should be remembered. Correct for maintenance, a seasonal page or a short diversion.
Why the distinction matters. Different consequences.
A permanent statement consolidates onto the new address. A temporary one asks for the old address to be retained, which means a permanent move announced temporarily leaves everything waiting for a return that never comes.
How the error happens. A default.
Some systems produce the temporary version unless told otherwise, so nobody chose it. A migration built on defaults can announce every move as temporary without anybody deciding to.
Why a migration is permanent. By definition.
A site that has moved is not coming back to its old addresses. Announcing that clearly is the whole purpose of the exercise, which our site migrations material covers in depth.
What both preserve. Less than people assume.
Neither code is a way of transferring value from one page to another. A redirect points somewhere. The destination has to genuinely correspond for anything to carry across, which is why sending everything to the home page achieves so little.
What to avoid regardless. Chains.
An address redirecting to another that redirects again. Each step is a delay and an opportunity for a link in the chain to break. Chains accumulate quietly across successive rebuilds.
When A Page Is Not There
A missing page response is not a fault and not a penalty. A site with some is entirely normal. Chasing every one to zero is wasted effort.
What it means. Nothing exists at that address.
The server was asked for something it does not have and said so. That is the correct answer to the question, which is why it is not an error in the way it sounds.
Where the count comes from. Years of history.
Reports include every address anything has ever encountered, including ones from long-dead sources and sites that no longer exist. A large number frequently reflects how long you have been publishing rather than anything wrong today.
Why sites accumulate them. Normal change.
Pages get removed, products sell out permanently, old campaigns end and somebody links to a mistyped address. Every one of those produces this response and none is a fault.
Why the count alarms people. The presentation.
Reporting lists them under errors, in numbers, which reads as a problem requiring resolution. That framing is where the wasted work begins.
What is genuinely not penalised. Having them.
A site is not marked down for having missing pages. Where a page has genuinely gone, this response is the accurate thing to return.
What the visitor experience should be. Helpful.
The response code is correct and the page shown to a person should still help: a clear explanation, navigation and a route to what they wanted. That is a design job rather than a technical one.
What actually costs you. Removing a page people wanted.
The response is not the problem. Deleting something that was earning enquiries, then leaving nothing in its place, is the problem. That is a content decision rather than a technical one.
Which ones do matter. A minority.
The ones with links pointing at them or people arriving at them, which block eight covers. Everything else is a report entry.
When A Page Has Gone Deliberately
A separate response exists for content removed on purpose. It says gone rather than not found, being a clearer statement that almost no site bothers to make.
What the difference is. Certainty.
Not found leaves open whether the address was ever valid or might return. Gone states that it existed, was removed intentionally and is not coming back.
Why that is clearer. It removes ambiguity.
A definite statement of removal is a stronger signal than an absence. Where you know content is gone for good, saying so is more accurate than letting it be inferred.
When it is worth using. Deliberate removals.
Content pruned on purpose, discontinued lines that will not return, expired listings removed by policy. Anywhere the decision to remove was actually made by somebody.
When not to bother. Everything else.
Mistyped addresses, pages that were never there and ordinary attrition. The not found response is correct for those and switching would be false precision.
Why nobody uses it. It takes a decision.
Returning it means somebody deciding a removal was permanent and configuring that deliberately. The default costs nothing and is nearly as good, which is why the default wins.
Whether it is worth your time. Mostly not.
On a site pruning content at scale it is a tidy discipline. On an ordinary business site the gain over the default is small. We would not raise it unprompted.
A Success Response With Nothing Behind It
A page returning success while showing nothing useful. It is the worst of both situations, because the visitor gets nothing and no report shows a problem.
What it is. A contradiction.
The code says here is your page and the page says there is nothing here. Machines believe the code, so the address is treated as a real page with no content on it.
Why it is worse than a missing page. Nothing flags it.
A missing page announces itself in reporting. This one reports as a success, so it can persist indefinitely with nobody aware that anything is wrong.
Where it comes from. Two usual sources.
An empty category page where everything in it has gone, plus a template that loads successfully with no content behind it. Both are working exactly as built.
The retail version. Discontinued products.
A product page for something no longer sold, still loading, showing a template and no product. Common on stores where removal was never part of anybody's process.
What the visitor experiences. Confusion.
They arrived at something that looks like a page and offers nothing, with no explanation of what happened. Worse than being told the page has gone.
What to do about it. Decide what the page is.
Either it has content and should show it, else it has none and should say so plainly with the right response. The middle state is the only wrong answer.
When The Server Fails
A server error means the site is failing rather than the page missing. Repeated ones can affect crawling. This is a hosting problem rather than a search one.
What it means. Something broke.
The request was valid and the server could not fulfil it. That is a fault in the site or its hosting rather than a statement about the address.
Why it is different in kind. It is not about one page.
A missing page is a fact about an address. A server error suggests the site cannot reliably respond, which affects everything rather than one thing.
What repeated ones do. Reduce confidence.
Something repeatedly finding a site unable to respond will approach it more cautiously. That is a sensible response to unreliability rather than a punishment.
Where the cause usually is. Capacity or code.
A server overwhelmed by traffic or sharing resources with something else, else a fault in the site's own software. The hosting pillar covers why cheap hosting fails here more often.
Why it is not an SEO problem. The fix is elsewhere.
Nothing about content, structure or markup addresses a server that cannot respond. That is a hosting and development matter. Treating it as a search issue delays the actual fix.
What it looks like to a visitor. A broken site.
Unlike a missing page, which reads as a specific thing being unavailable, this reads as the business being unreliable. Somebody meeting it at a busy moment is unlikely to return later to check whether it was temporary.
What deserves attention. Patterns.
Occasional isolated failures happen everywhere. Failures clustering at particular times, else affecting whole sections, indicate something worth investigating properly.
Which Missing Pages Are Worth Fixing
Two questions separate the ones worth acting on from the rest. Everything failing both can be left alone, which is usually the majority of the list.
Does anything link to it. The first filter.
An address with links pointing at it is receiving something you would otherwise lose. Those are worth redirecting to whatever is now most relevant.
Is anybody arriving at it. The second.
An address people still reach, from a bookmark, an old email or printed material. Those are costing you visits from people who wanted you specifically.
What fails both. The bulk of the list.
Addresses that were mistyped once, generated by something that no longer exists or crawled from a source long gone. Nobody is affected and nothing is lost.
What fixing means. A judgement about relevance.
Sending the old address to the closest current equivalent. Where nothing is genuinely equivalent, leaving it missing is better than sending somebody somewhere unrelated.
The mistake worth naming. Redirecting everything to the home page.
A common shortcut that takes somebody who wanted a specific thing and gives them a front door. It looks tidy in a report and it disappoints every person it touches.
What a redirect cannot rescue. A page nobody wanted.
Redirecting an address that was already receiving nothing moves nothing. The exercise only recovers what was genuinely arriving, which is why sorting the list matters more than working through it.
How to work through a list. Sorted, not exhaustively.
Ordered by links and by arrivals, the top of the list is a short afternoon and the rest can be ignored. That is the whole method.
Which Ones Actually Need Action
Six situations, in the order they deserve your attention. No definitions repeated, just what to do.
Server failures, repeatedly. Act now.
The only genuinely urgent item here. Take it to whoever manages your hosting, with the times and pages affected, since it is their problem to diagnose.
Success responses with nothing behind them. Act soon.
Nothing will report these, so they need finding deliberately. Decide whether each page should have content or should say it has gone.
Permanent moves announced temporarily. Act soon.
Particularly after a migration or a platform change. Correcting the announcement is usually a single configuration change rather than a project.
Missing pages with links or arrivals. Act when convenient.
Worth an afternoon, ordered by which are receiving most. Redirect to the closest genuine equivalent and stop when the list stops mattering.
Redirect chains. Act during other work.
Worth shortening when you are already changing something. Rarely worth a dedicated project unless the chains are long.
Pages gone deliberately. Optional.
Stating that removed content has gone for good rather than merely missing is a tidy discipline on a site pruning at scale. On an ordinary business site the default is nearly as good and this can be skipped entirely.
Everything else. Leave it.
Missing pages nobody links to or visits, isolated one-off failures and the long tail of any error report. Leaving these alone is a decision rather than neglect.
Most of that
error list can
be left alone.
A missing page is not a fault and not a penalty. The ones worth acting on have links pointing at them or people arriving at them, which is usually a short afternoon rather than a project. We will tell you which, plus where to stop.
What we prioritise, in order:
Chasing an error count to zero is billable work with no outcome attached.
Every guide.
One practice.
How search finds and stores a site, what your own files are telling it, addresses and duplication, status codes, mobile, hosting and what a real audit contains.
