Soft 404 pages and how to fix them

What a soft 404 is

A soft 404 is a page that returns an HTTP 200 (success) status but displays no useful content, typically an error or an empty page. From the browser's point of view there is no failure, so the visitor sees a blank or "nothing here" page rather than a browser error. Because the server reports success, the search engine cannot flag it by status code and instead has to infer that the page is a dead end by reading the content.

A plain, real 404 (covered in the 404 reference) returns a status code the server and crawler both understand. A soft 404 hides the same situation behind a success code. Common soft 404s are not-found pages that do not set the status, empty search result pages that return 200, single-page app fallback routes that return 200 for every unknown path, and product pages that show nothing after a product is removed.

Why it hurts the index

The harm comes from what the search engine thinks exists. When a page returns 200, the engine can keep it in the index and keep treating it as a real page. That can waste crawl budget on pages that give the visitor nothing, and it can leave stale URLs indexed long after the content they replaced is gone. The crawl budget and site shape article explains how repeatedly useless pages get deprioritised, but the cleaner fix is to stop presenting them as real pages at all.

Because the soft 404 is only recognisable by content, detection is slow and noisy. Google has to render the page, decide there is nothing useful, and infer intent. That is why the Pages report in Search Console can list a URL as "Page with soft 404" only after Google has looked at it, and why fixing the status code is far more reliable than waiting for the inference to repeat.

Return a real status

The correct fix is to make the server return a real 404 status (page gone) or a 410 Gone status (page deliberately removed and never coming back) for the URLs that have nothing to show. The difference matters: a 410 tells the engine the removal is permanent, so it drops the URL faster than a 404, which the engine may re-check expecting a future return.

• For a statically hosted site, generate the not-found page so that unknown paths return the 404 status through the hosting platform's error handling, not a 200 catch-all.
• For a server-rendered site, set the response status in the framework when a record is missing rather than rendering an empty template with the default success status.
• For a single-page app, the fallback route that serves for unknown paths must not answer every route with a 200; serve a proper status where the router cannot match a page.

After changing the status codes, validate with the URL Inspection tool or a log file review, then give the URLs time to leave the index. The indexing analysis guide and the removals tool cover how to confirm a URL has dropped from the index and what to do when a legitimate template now overstates indexation. When you compare index counts later, you are comparing pages that genuinely should exist, not empty placeholders.