Soft 404 Errors: Causes and Fixes

By Amit Patel

A soft 404 is Google’s way of saying “this page returns a success status code, but it looks like a not-found or empty page to me” — so it declines to index it. The mismatch between the 200 status your server sends and the thin or error-like content Google actually sees is the whole problem. Unlike a hard 404, nothing looks broken to a casual visitor, which is exactly why soft 404s accumulate unnoticed and quietly keep pages out of the index.

What Triggers the Soft 404 Label

Google applies “soft 404” when a page returns HTTP 200 but its content signals absence — empty results, “not found” text, near-empty templates, or a body so thin it reads as a placeholder.

Google’s systems compare what the status code promises (a real page) with what the rendered content delivers (nothing useful). When they disagree, it trusts the content and treats the URL as effectively missing. This is a content judgment layered on top of the Page indexing report, and it is distinct from a true 404: the fix is almost always either sending the correct status code or giving the page real content.

The Common Causes

Five patterns produce most soft 404s: empty search or category pages, “no results” states returning 200, thin or placeholder pages, broken pages that render an error message with a 200 code, and JavaScript that fails to load the real content for the crawler.

Faceted navigation and filtered listings are frequent offenders — a filter combination with zero products still returns a templated page and a 200. Expired listings (jobs, events, out-of-stock products) that show “no longer available” but keep a 200 status are another. And client-side rendering can create soft 404s when the crawler receives an empty shell because the content-loading script never completed, a rendering issue the crawlability guide covers in depth.

How to Fix Each Cause

Match the response to reality: if the page should not exist, return a real 404 or 410; if it should exist, give it genuine content; if it moved, 301-redirect it to the closest live equivalent.

For empty search and filter pages, either return a 404 when there are no results or (better) block those parameter URLs from crawling so they never enter the index. For expired listings, 301 to a relevant category or the nearest replacement rather than a dead-end “unavailable” page — sending them all to the homepage instead usually just creates a redirect status with no relevance. For thin pages that deserve to exist, expand them until they genuinely answer the query; if they do not deserve to exist, consolidate them into a stronger page, the same call you make with Crawled — currently not indexed. For JavaScript-dependent pages, ensure the crawler receives the real content — server-side rendering or prerendering is the reliable fix.

Confirming the Fix

Use the URL Inspection tool’s live test to see the status code and rendered content Google receives now, then validate the fix in the Page indexing report and let Google re-crawl.

The URL Inspection tool shows both the response code and the rendered HTML — confirm a real 404/410 now returns the right code, or that a repaired page now shows its full content. Then click “Validate fix” on the soft 404 group so Google re-checks the batch. Google’s guidance on soft 404 errors is explicit that the core fix is aligning status codes with content, not gaming the crawler.

Frequently Asked Questions

The Bottom Line

Soft 404s are honesty problems: your server says “here is a page” while the content says “nothing here.” Resolve the contradiction — correct status codes for gone pages, real content for pages worth keeping, sensible redirects for moved ones — and the label disappears on the next crawl. Work through them alongside the Page indexing report and the rest of the Search Console cluster to keep your index clean.