How to Diagnose a Soft 404 Page

When Google Search Console reports a soft 404, Google has treated the URL as an error page even though the server returned a successful response, commonly HTTP 200. The status describes the request: 200 means it succeeded. The page content indicates an error when it says content is missing or displays almost nothing.

Check what the URL should show, what response the server returns, and what Google sees after it renders the page. These checks help you tell a removed page from a live page that fails to load for Google. Then you can choose the right fix instead of changing status codes without knowing the cause.

What Google’s soft 404 report means

Google calls a page a soft 404 when it looks like an error page but returns a successful HTTP status. Google uses soft 404 as a label for this condition; the HTTP response still has its own status code. Google can also apply the label when a page appears blank or nearly blank. Its crawling error guidance lists an empty search result on the site and a database problem among the causes. A missing JavaScript file is another.

Start by deciding what the URL should do. It should show a real page, redirect to a relevant replacement, or return an error because the content is gone. The correct response depends on that purpose. A page that should still exist needs investigation into its content and delivery; a removed page without a suitable replacement needs an error response.

Inspect the reported URL in Search Console

Find the URL in the Page indexing report, then open it in Search Console’s URL Inspection tool. The report gives you Google’s stated reason and example URLs to investigate. Treat those examples as a starting point, rather than assuming they show every affected URL.

In URL Inspection, compare the indexed data with the live test. Indexed data describes the version Google processed previously, so it may reflect an earlier failure. The live test checks the URL as it responds now. Google also provides a rendered view and information about resources loaded during the test. The URL Inspection documentation explains both views and their limits: a passing live test does not predict Google’s canonical choice or guarantee that the page will appear in Search.

Record the response status, any redirect destination, and what the rendered page shows. Then compare that result with the page’s intended content. A 200 response paired with a “not found” message shows that the status and page content conflict. A blank render calls for a closer look at scripts, data requests, and other resources the page needs to display its main content.

Compare Google’s view with the page visitors receive

If the page looks normal in your browser but appears blank or error-like in URL Inspection, investigate what Google received during its test. Check the server, application, and CDN logs for the request and for requests to essential scripts or other resources. Look for failed requests or access blocks. Also check whether a challenge page appears instead of the content.

For pages that use JavaScript, check the rendered page and any errors in URL Inspection. Google’s JavaScript troubleshooting guidance also cautions that analytics data does not necessarily show Googlebot’s rendering activity accurately. A content delivery network (CDN) or firewall can give crawlers a different response from the one a regular visitor sees. Google’s CDN crawling guidance says to check for bot challenges and error responses.

A browser test alone cannot establish what Google saw. Compare the live rendered result with the page visitors receive, then use request logs and resource results to locate where the responses diverge.

Match the fix to the URL’s purpose

The HTTP standard defines 404 as a response for a resource with no current version available. A 410 response means the resource is no longer available and will likely remain unavailable. Google recommends either for removed content without a similar replacement. The HTTP semantics standard defines these status codes.

A custom error page can still explain what happened and help visitors find useful content. The server should return 404 or 410 for that page rather than 200. For moved content, redirect only when the destination genuinely replaces or consolidates the old page. Google warns that redirects to an unrelated homepage can be treated as soft 404s in its site-move guidance.

Avoid fixes that hide the evidence

Do not assume every soft 404 means the URL should return 404. If the page is meant to exist, changing its status could remove a valid page and leave the failure Google encountered unresolved. Check the rendered result first.

Also, do not treat 200 as proof that the page works. The server can return a successful status while the page shows an error, fails to load its main content, or remains blank. Unrelated text leaves the underlying problem unresolved on a broken page. Restore the intended content or return the status that matches the URL’s state.

Finally, do not treat an unchanged indexed result as proof that a repair failed. Indexed data may reflect an earlier crawl. Confirm the current page with a live test; after repairing it, request indexing where appropriate. Google still decides whether and when to recrawl, index, and serve the URL.

What a soft 404 means for Search and AI features

Google says it excludes pages it identifies as error pages from Search. For AI Overviews and AI Mode, Google’s documented requirement is that supporting pages be indexed and eligible to appear in Search with a snippet. Google describes the same foundational SEO requirements for these features, with no separate soft-404 optimization. Its AI features guidance also makes clear that eligibility does not guarantee that Google will serve a page.

The practical priority is to make the URL’s status and rendered content match its intended purpose. That gives Google a page it can evaluate correctly; it does not guarantee an AI citation or a particular search result.

Key Takeaways

• Check the page’s purpose first: Decide whether the URL should show content, redirect to a relevant replacement, or return an error.
• Compare status with rendered content: A 200 response does not prove that the page loaded correctly for Google.
• Use both Search Console views: Compare indexed data with the live test, and remember that the live test does not guarantee indexing or serving.
• Fix the cause, not just the label: Restore a page that should exist, redirect only to a genuine replacement, and return 404 or 410 for removed content without one.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com