A soft 404 is a page telling humans one thing and machines another. The visitor sees “Sorry, we couldn’t find that page.” The crawler receives 200 OK, meaning “here is a valid page.” That mismatch is the entire problem, and it produces a specific and avoidable mess: empty pages in Google’s index, wasted crawl budget, and a Search Console report full of URLs you cannot easily explain.
What Google Means by “Soft 404”
Google flags a URL as a soft 404 when the page content suggests it does not exist, but the server returns a success status code.
Google detects this by reading the page — looking for content patterns like “page not found,” “no results,” or a nearly empty body where a real page would have substance. It is an inference, not a certainty, which is why detection is inconsistent and why you should never rely on Google catching them.
The status appears in the Page Indexing report. Google excludes these URLs from the index, which is the right outcome — but it has spent crawl budget discovering that, repeatedly, for every affected URL.
What Causes Them
1. Error Pages Returning 200
The textbook case. A CMS or framework serves a friendly error template but never sets the status code. The page says “not found” and the header says 200 OK.
This happens most often with custom 404 templates, single-page applications where routing is handled client-side, and headless setups where the front end renders an error state without telling the server.
2. Redirecting Deleted Pages to the Homepage
Extremely common and worth understanding properly. You delete a hundred product pages and redirect them all to the homepage rather than returning 404.
Google recognises that the homepage does not answer what the original URL promised, and classifies the redirect as a soft 404. You get no link equity, and the URLs are excluded anyway — so the redirect achieved nothing except making the problem harder to diagnose. We cover the correct handling in 410 vs 404 vs 301 for deleted pages.
3. Empty Category, Search and Filter Pages
An ecommerce category with no products in stock. An internal search results page with no matches. A tag archive with no posts. These return 200 with essentially no content, which reads to Google as a page that does not really exist.
4. Thin Pages
Not strictly an error page, but a page with so little content that Google concludes there is nothing there. Placeholder pages, stubs, and auto-generated pages awaiting content all land here.
5. Content Requiring JavaScript That Fails to Render
If the HTML is nearly empty and content is injected by JavaScript, and that rendering fails or is deferred, Google may see a blank page. The server said 200; the rendered result looks like nothing.
6. Out-of-Stock Product Pages
A product page showing only “this item is unavailable” with the rest of the template stripped out. Google sees a page with no substantive content.
Finding Them
Search Console is the primary source: Page Indexing → “Soft 404.” Export the list and look for patterns rather than treating each URL individually.
Test the status code directly for anything you suspect:
curl -I https://yoursite.com/this-page-does-not-existA genuinely non-existent URL should return HTTP/2 404. If it returns 200, your error handling is broken site-wide, and that single check will tell you more than the whole report.
Crawl your site with Screaming Frog or similar and look for pages with very low word counts returning 200. That surfaces thin and empty pages Google has not flagged yet.
Check your empty states deliberately — visit a category with no products, run an internal search with nonsense terms, and see what status comes back.
Fixing Each Type
Error pages returning 200. Fix the status code at the source. Your error template should return 404. In WordPress this usually works correctly unless a plugin or theme interferes; in SPAs and headless setups it often needs explicit configuration, because the server has no way to know the client-side route was invalid. This is worth fixing first because it is a single change affecting every bad URL on the site.
Homepage redirects. Remove them. Return 404 or 410 instead. If a genuinely relevant destination exists for a given URL, redirect there specifically — but do not manufacture relevance.
Empty category pages. Decide based on permanence. Temporarily empty — keep it live with a 200, and show related products or categories so the page has real content. Permanently empty — 404 or 410 it, or noindex it if it must remain reachable for users.
Internal search results. These should generally be blocked from crawling entirely. They generate unlimited low-value URLs and are a classic crawl budget drain. Add a disallow rule — see our robots.txt guide.
Thin pages. Either add substance or remove them. A page that exists only as a placeholder is doing nothing for you. If a page is thin but Google has indexed it, that is a different situation, closer to “crawled – currently not indexed”.
JavaScript rendering failures. Test with URL Inspection → Test Live URL → View Rendered HTML. If your content is absent there, Google is not seeing it. Server-side rendering or static generation solves this properly; patching around it rarely does.
Out-of-stock products. Keep the page live and useful. Show the product details, mark it unavailable, and link to alternatives or offer restock notifications. This is better for users and avoids the soft 404 entirely. Only remove the page if the product is permanently discontinued.
Why It Is Worth Fixing
Soft 404s do not carry a penalty. The costs are indirect but real:
- Wasted crawl budget. Googlebot repeatedly fetches URLs that turn out to be nothing. On large sites this measurably delays crawling of pages that matter.
- Diagnostic noise. A report full of soft 404s makes it harder to spot genuine indexing problems.
- Missed real errors. If your error pages return 200, you have no reliable way to distinguish “this URL never existed” from “this page broke.” Monitoring becomes guesswork.
- Poor user experience. Users clicking a search result that turns out to be an empty page bounce, and that behaviour is not helping you.
For a small site, a handful of soft 404s is not urgent. For a large ecommerce catalogue with thousands, the crawl budget cost alone justifies the work.
Prevention
Build the check into your process rather than discovering problems in Search Console months later:
- Test the error status after every deploy.
curl -Ion a deliberately invalid URL. It takes seconds and catches the most damaging version of this immediately. - Design empty states to contain something useful — related items, popular categories, a search box.
- Handle deletions with a policy rather than ad hoc redirects.
- Block internal search results from crawling at launch, not after they proliferate.
- Include a status code check in your regular technical review — our SEO audit checklist covers where it fits.
Say the Same Thing to Both Audiences
Every soft 404 comes from the same root cause: the page tells humans and machines different stories. Fix that mismatch and the whole category disappears.
The single most valuable action is checking what your site returns for a URL that does not exist. If that comes back 200, you have one bug producing an unbounded number of soft 404s, and one fix resolves all of them. Everything else on this list is comparatively marginal.
If you want a technical audit that catches soft 404s, redirect problems, and crawl waste before they compound, our SEO services cover exactly that ground. Get in touch with the team at blogthememachine.com, and subscribe to our newsletter below for more technical SEO guides. Our Google Search Console tutorial is a useful companion if these reports are new to you.
