Soft 404 Errors: When a Missing Page Still Returns 200

A visitor opens an old product link and sees “Sorry, we could not find that page.” Your uptime monitor stays green because the server returned HTTP 200. The page is reachable, but the response does not match the missing content.

Google describes a soft 404 as a page whose content indicates an error even though the server does not provide an appropriate missing-page response. This can also involve pages that appear empty or fail to load their main content. Google's crawling-error guidance explains the different repair paths.

Confirm the mismatch on an exact URL

Open the reported address directly and inspect the main document request in the browser's Network panel. Record the requested URL, final URL, HTTP status, and visible content. Check the document rather than a missing image or another background request.

Then compare three cases: a valid page, a deliberately invented URL, and the affected URL. If all three return the same generic application shell, you have a useful clue about the routing layer. If only one content record fails, the problem may be in publication state or a page-specific data request.

A screenshot alone cannot establish the HTTP status. A status check alone cannot establish that the main content is present. Keep both pieces of evidence together.

Decide what the URL should mean

The right repair depends on the content's intended future:

• If the content is gone and has no suitable replacement, return a genuine 404 or 410 response.
• If it moved, direct visitors to the relevant replacement.
• If the page should still exist, restore its content and investigate the failure that made it look missing.

These are different outcomes. Do not redirect every deleted page to the homepage just to remove errors from a report. Visitors following a specific link need either a relevant destination or an honest explanation that the resource is unavailable.

For example, an obsolete service page may have a clear successor that answers the same question. A discontinued event from several years ago may not. Make that editorial decision before implementing redirect rules.

Inspect the error template and route fallback

A custom error page can be attractive and helpful while still sending the wrong status. Ask the developer to verify how the template is returned, not merely what it looks like. Review catch-all routes and CMS fallbacks that turn unknown paths into successful responses.

For JavaScript applications, also inspect whether the main content request fails after a successful document load. A broken API response may leave only a spinner or an empty shell. The repair then needs to address content delivery rather than relabeling an otherwise valid page as permanently missing.

Save an example for each failing route family. Fixing one manually selected URL does not establish that the catch-all behavior is correct.

Retest the route family

After the change, confirm that the missing URL has the intended status and a useful visitor-facing message. Test a valid sibling page to make sure it still returns its content. Follow any replacement redirect and inspect the final page too.

Remove dead internal links and update sitemap entries where appropriate. These are supporting cleanup steps; removing an entry from the sitemap does not repair an incorrect HTTP response.

Keep a short record of the decision for deleted content. When a future editor asks why a URL returns 410 or redirects to a particular resource, the reason should be available without reconstructing an old release.

Search Console observations can take time to reflect a repair. Verify the public response first, then track the report separately. If the server still returns 200 for the missing page, waiting for the report to refresh will not solve the underlying problem.

For the wider distinction between a reachable site and correct public behavior, read what uptime monitoring misses.