Soft 404 Errors: Why Google Drops Pages That Return 200

Soft 404 errors happen when a URL returns 200 OK but its content looks like an error message, an empty page or a missing resource. Google treats it as not found and keeps it out of the index. Seeing these URLs in Search Console and suspect your origin (or the proxy in front of it) is serving error pages with a success code? This guide covers how Google classifies them, where they usually come from, how to confirm the real status code and how to fix it on the origin.

What does a soft 404 in Search Console actually mean?

Search Console flags a soft 404 when the server returns a success code but the page itself looks like an error, an empty page or an error message. Quick refresher: a status code is the number the server sends before the page body, and crawlers read it before they even get to the content. According to Google’s guide to HTTP status codes, a 200 response goes on to the indexing pipeline, but that doesn’t mean it gets indexed. So the server says “success” and the page says “missing”. Google believes the page. And drops it.

Why an error page that returns 200 hurts more than a real 404

A real 4xx is clean. It tells Google the content doesn’t exist, full stop. An error page served with 200 burns crawls and leaves the signal muddy. Google treats every 4xx code except 429 the same way: indexed URLs that start returning 4xx get removed, newly discovered 404 pages aren’t processed, and crawl frequency for them drops off over time. Server errors and 429 are a different story. They make Google back off crawling for a while and keep indexed URLs around, though pages that keep failing do get dropped in the end.

So the rule in practice is pretty simple. 404 or 410 for content that’s gone, 5xx for a real outage, 200 only for a real page.

Common sources of soft 404 errors

Most soft 404s come from templates and fallbacks that render an error message but leave the default success code alone. The usual suspects:

• A custom “not found” template the CMS or framework renders with status 200.
• Empty category, tag, search or listing pages with zero items (the classic thin page soft 404).
• Upstream failure pages, like a database outage or an application exception, that the origin serves with 200.
• Error or placeholder bodies passing through a reverse proxy after the origin has already set 200. If you’re wondering about the proxy error page status code, look at what the origin sends first.
• Removed products or articles redirected to a generic page or the homepage instead of returning 404 or 410.

An extra layer between visitors and the server can hide all of this, and it’s one of the problems a proxy can mask until Search Console finally reports it.

How to confirm which status code a page really returns

Don’t trust the browser. Request the URL directly and read the status line. A friendly error page looks identical whatever code ships with it, so go layer by layer:

1. Run curl -I or curl -sS -o /dev/null -w '%{http_code}' on the flagged URL.
2. Send the same request straight to the origin, bypassing the proxy, to see which layer sets the code.
3. Use URL Inspection in Search Console to see what Googlebot actually got.
4. Check access logs for Googlebot requests and the codes they received.

Logs also help with spotting errors in server logs at scale. Compare body sizes while you’re there. Lots of small, near-identical 200 responses? That usually means a shared error template.

How to fix soft 404 errors on your origin and NGINX

Make the server send the status that matches the content: 404 or 410 for missing pages, 5xx for failures, 200 only for real content. In the application, set the code inside the not-found handler, not just in the template it renders (easy to miss, and a very common one). Empty search or listing pages should either return 404 or get real content.

On NGINX, use error_page 404 /404.html; without the =200 override, and make sure try_files ends with =404 instead of rewriting every unknown path to index.php or index.html with a success code. Content you removed on purpose deserves 410. A redirect only makes sense when the target is genuinely equivalent. Single-page apps? The server should return a real 404 for unknown routes, or at the very least a noindex tag, not a blank shell. After deploying, click Validate Fix in Search Console and keep an eye on the report over the next few crawls.

Thin and empty pages on rebuilt or expired domains

Old domains rebuilt with placeholder text or empty templates are a frequent thin page soft 404 source. For URLs with history, you’ve got two options: restore meaningful content, or let them return 404 or 410. What you shouldn’t do is leave empty shells lying around. Planning pays off when rebuilding pages on old domains, because every URL needs a clear decision.

Sites that need a regional presence can also run behind a reverse proxy with EU IPs or US addresses, and the status codes stay under your control on the origin.

Soft 404s go away once the status code tells the same story as the content. Check the real code, fix it on the origin, return 404 or 410 for pages that are gone and stop serving empty templates. That’s really it. For related topics, browse our indexing and crawling guides.

FAQ