What Is a Soft 404?

A soft 404 is a page that tells the visitor there is nothing here and tells the server everything is fine. The browser receives a 200 code, the user reads "product unavailable" or "no results found", and the two statements contradict each other.

Google resolves the contradiction in favour of the content. When it detects that a 200 response carries no real content, it treats the page as non-existent: it drops out of the index and gets flagged in Search Console. The name says it: a soft 404, one the server declined to declare.

It should be kept apart from an honest 404 error, which is not a problem but the correct answer. A vanished page returning 404 is exactly what should happen; the fault appears when it vanishes and pretends to still be there.

The most frequent case does not even look like an error at first: redirecting everything gone to the homepage. It loads, answers 200 and is full of content, so nobody notices anything. To Google it is a soft 404 all the same, because the user wanted something specific and got something else.

The name misleads slightly, because it sounds like a mild variant of an error. It actually describes a mismatch: between what the HTTP response asserts and what the page contains. Everything else follows from that, including why Google bothers to detect it.

A search engine cannot rely on the code alone, because anyone can set it wrongly by accident. If it took the 200 at face value, the index would fill with pages announcing that there is nothing. So it checks the content, and so the fix never consists of hiding the symptom but of making code and content say the same thing.

The four usual sources show up in almost any audit, and none of them was created on purpose.

Catalogs running empty. An e-commerce category with no products, a filter with no matches, a tag left without articles. The template keeps working and returns 200, but all it contains is the notice that there is nothing.

Lazy redirects. Everything unfindable goes to the homepage or a catch-all category instead of an equivalent destination. It usually gets installed with good intentions, to "not lose the user", and achieves the opposite.

Error pages built in JavaScript. The server delivers an empty document with 200 and the message appears once the script runs. To anyone measuring in the browser everything looks right; the crawler sees a 200 without content first.

Content too thin to count. A product page with only a title and a price, no description and no images, can end up classified the same way. Here the border with thin content blurs, and the remedy is identical: give real content or withdraw the page.

A fifth source deserves its own mention because hardly anyone looks for it: internal search result pages. Many sites leave them indexable, and it takes one person linking a search with no results for the crawler to discover it. Every combination of terms generates a distinct URL, and almost all of them are empty.

The remedy here is not technical but a matter of decision: that these URLs should not exist for search engines. A rule in robots.txt or a noindex resolves the case entirely, and frees crawl budget for what matters along the way.

The damage is not that the page fails to rank, because an empty page should not rank. The damage is what it costs to find that out.

Every soft 404 consumes crawl budget: the crawler requests the page, receives 200, processes it in full and only then concludes there was nothing. An honest 404 is settled with a short response and the system stops coming back. In a catalog with thousands of filter combinations that difference decides which real pages go un-indexed.

They also pollute the diagnosis. A coverage report full of soft 404s hides the real problems, and the team gets used to a red dashboard. That is the worst possible situation: where everything is flagged, nobody looks.

For the visitor, finally, it is a matter of honesty. A well-made error page with search and links to nearby categories rescues the visit. A redirect to the homepage forces a fresh start and usually ends in the bounce rate.

One consequence shows up outside the technical report: soft 404s spoil the statistics. A page answering 200 counts as a normal visit in any web analytics tool, so traffic to empty pages mixes in with useful traffic. Average conversion drops without anyone knowing why.

A declared 404, by contrast, can be filtered, measured and prioritised: you see how many visits land there, where they come from and what they wanted. That difference turns an invisible problem into a task list sorted by impact.

The rule is short: let the code tell the truth about the content. From there three paths follow, depending on the case.

If the page is gone and there is no equivalent, return 404, or 410 if the removal is permanent. The 410 tells Google no re-check is needed, freeing crawling sooner.

If an equivalent destination exists, a direct 301 redirect to it, not to the homepage, and without a chain in between. Equivalent means it serves the same intent, not that it sits in the same section.

If the page should stay alive but happens to be empty, give it real content: related products, an explanation of the category, a search box. A catalog category that empties seasonally need not disappear, but it does have to offer something.

Then the check: the report in Search Console lists the flagged pages, and it pays to review one of each type by hand plus a direct request — the same symptom can have different causes in different templates.

A note on the order of work. Before touching templates, group the flagged URLs by pattern rather than reviewing them one by one. In a catalog, twenty thousand soft 404s are usually three misplaced rules; fixing those three clears the whole list, while going page by page never ends.

And a warning about checking afterwards: the report takes time because it depends on Google re-crawling. A list still full three days after the fix does not mean the fix failed, it means nothing has been re-checked yet — just as with the field metrics in Search Console.

• Redirecting everything missing to the homepage because "that way nobody is lost": they are lost anyway, and a soft 404 is created on top.
• Treating a 404 as an error that must disappear from the report. It is the correct answer when something no longer exists.
• Checking only in the browser, where the error message appears via JavaScript and everything looks normal, instead of inspecting the response code directly.
• Fixing the templates while internal links keep pointing at the empty URLs, so the crawler keeps arriving there.
• Leaving filter combinations indexable that are almost always empty, instead of deciding which ones deserve to exist at all.