← All posts

Soft 404s: The 200-Status Pages Google Quietly Drops

200 OK ? THIN CONTENT EMPTY SOFT 404

Your product catalog has 40,000 SKUs. About 3,000 of them are out of stock and have been for six months. Each of those pages returns HTTP 200, renders your standard product template, and displays a single line of text: “This item is currently unavailable.” Google has been crawling those pages, spending resources on them, and quietly assigning them a coverage status of “Soft 404” — not a crawl error, not a broken link, just a silent conviction that your 200-response page is functionally empty. Those 3,000 pages are not indexed, and they’re absorbing crawl capacity that could be reaching your 37,000 active listings.

Soft 404s are one of the most underestimated indexation problems in large-scale sites because they produce no visible errors. Your server logs show 200s. Your uptime monitors are clean. Screaming Frog completes without red. The problem only surfaces in Search Console’s Page Indexing report, under a status that many teams interpret as an edge case rather than a systemic signal.

What Makes a Page a Soft 404

The working definition is not a Google specification but a behavior pattern: a page that tells the HTTP client “everything is fine” while delivering content that communicates “there’s nothing here.” The mismatch between the transport-layer signal (200 OK) and the content-layer signal (no real content) is what Google is detecting and penalizing.

The canonical cases:

Out-of-stock or discontinued product pages. The page loads, the template renders, but the main content area contains one sentence and a disabled “Add to Cart” button. The product name, images, description, specifications, reviews, related products — absent or stripped. From Google’s perspective, this is a shell.

Empty search results pages. /search?q=obscure-query returns 200 and renders your standard search results template with no results. These pages are often linked from nowhere, but they get crawled when bots follow link patterns or when the URL appears in a sitemap. Every unique search query that produces no results is a distinct 200-response URL with no meaningful content.

JavaScript application shells. A single-page app serves the same thin HTML scaffold at every URL. The scaffold contains your navigation, footer, and a <div id="app"></div>. The content is injected client-side after hydration. If Googlebot crawls the raw HTML before rendering — or if the JS fails — it sees a template with no body content. This is technically a render parity failure with soft-404 characteristics.

“No results” category pages. Filtered category URLs like /shoes/red/size-23/ that exist because your faceted navigation generates them, but happen to match zero products. The page returns 200 with a “0 items found” message and the template frame. Google crawls it, finds no content, soft-404s it. If your faceted navigation generates thousands of these, you have a systematic soft 404 problem tied directly to URL parameter handling.

Expired or deleted content pages. A blog post or news article was deleted from the CMS but the URL still resolves. A 200 response is returned with whatever fallback your CMS produces — maybe a “post not found” message within the standard layout, maybe a redirect to the homepage that somehow still returns 200 (a different but related problem), maybe a blank content area where the article used to be.

How Google’s Coverage Status Works

Search Console surfaces soft 404s under the “Soft 404” status in the Pages report (previously Coverage). The status reads: “This page returns an HTTP success code (200), but appears to be an error page.” Google is clear that this is its assessment, not yours — you haven’t tagged the page as an error, but Google has interpreted it as one.

A page reaching this status means Google crawled it, rendered it, assessed its content, compared it against site-wide and template-level norms, and concluded it doesn’t merit indexation. The page may also appear under “Crawled — currently not indexed” if Google is on the fence, but “Soft 404” is a firmer signal that Google has concluded the content is thin or error-like.

Importantly, soft 404s are not counted as crawl errors. They count as crawled pages. This means they consume crawl budget — every soft 404 Google visits is a crawl slot that could have been spent on a page with real content. On large e-commerce or news sites where hundreds or thousands of URLs are soft 404 candidates, the crawl budget impact is non-trivial: high-value pages get crawled less frequently because crawlers are spending capacity on confirmed empty pages.

Detection Heuristics: How to Find Them Before Google Tells You

Waiting for Search Console to report soft 404s means waiting for Google to crawl, assess, and report — a cycle that can take weeks. Running your own detection proactively surfaces problems faster and lets you fix them before they affect indexation.

Thin rendered word count against template baseline. Render your pages and measure the main content word count — not total word count including nav/footer/boilerplate, but the content area specifically. Compare each URL against the average for its template type. A product detail page with fewer than 50 words in the content area, on a site where product pages average 400 words, is a soft 404 candidate. The threshold depends on your content type, but the comparison against template baseline is the key — it normalizes for sites that run lean.

Error phrase detection in rendered body. Certain phrases are strong soft 404 signals when they appear in the content area: “not found,” “no results,” “no items match,” “this page does not exist,” “currently unavailable,” “item is out of stock,” “this product has been discontinued,” “your search returned no results,” “404” appearing in body text despite a 200 header. Scanning for these phrases in the rendered DOM is a high-precision heuristic.

Low main content ratio. Calculate the ratio of content-area text to total page text. A page where the main content block contributes less than 10–15% of total rendered text is template-heavy and content-light. This catches the JS shell case where an empty <div> sits inside a fully rendered site frame.

Rendered DOM sparseness. After rendering, if the main content area of the DOM contains fewer than a handful of meaningful elements — no headings, no paragraphs, no product data, no article body — that structural sparseness correlates with soft 404 assessment. Counting meaningful DOM nodes in the content area, not the chrome, catches empty templates that word count alone might miss if the template itself contributes words.

Cross-referencing with GSC soft 404 export. If you already have soft 404 signals in Search Console, pull the URL list and map it back to your URL structure. Soft 404s tend to cluster by URL pattern: /search?q=*, /products/discontinued/*, /category/filter-combo/*. Identifying the pattern reveals the systemic cause rather than chasing individual URLs.

VisibilityIQ flags soft 404 candidates by comparing the rendered main-content volume against template-derived baselines, scanning the content area for known error-phrase patterns, and cross-referencing against GSC coverage data to distinguish Google-confirmed soft 404s from at-risk pages that haven’t been formally assessed yet.

The Correct Responses

Soft 404s require different treatments depending on what the page actually is.

Permanently removed pages: 404 or 410. If the content is gone and isn’t coming back — discontinued products with no successor, deleted articles with no redirect target, closed user accounts — return the correct HTTP status. A 404 says “I don’t know this resource.” A 410 says “this resource was intentionally removed.” Google processes 410s faster for deindexation. Either is correct; both are better than 200 with empty content. Do not serve a styled error page with 200 status.

Temporarily unavailable content: noindex or preserve content. Out-of-stock products are the nuanced case. If the item will return, consider two options: keep the page with enough content to justify 200 status (product description, specifications, reviews, related alternatives), or add <meta name="robots" content="noindex"> while the item is out of stock and remove it when inventory returns. The former is better for SEO continuity — a page that stays indexed through a stock-out preserves its ranking position. The latter is defensible for products that are out of stock for extended periods. What is not defensible is a 200 with one line of content and no noindex.

Duplicate or empty search/filter pages: block or consolidate. Parameterized URLs that generate empty result sets should either not be crawlable or should redirect. Adding <meta name="robots" content="noindex, follow"> on empty search results pages prevents indexation without disrupting navigation. For faceted navigation, the correct long-term fix is canonical consolidation and thoughtful parameter handling in robots.txt — blocking parameters that produce empty sets from crawl entirely. The accidental noindex post covers the risk of over-blocking with noindex, which is worth reading before applying noindex at template scope.

JS shell pages: fix the render. If the soft 404 is caused by a JavaScript application serving thin HTML before hydration, the fix is server-side rendering of the content, or at minimum ensuring Googlebot receives a fully rendered page via dynamic rendering. A 200 response with an empty <div id="root"> is a soft 404 from Google’s perspective regardless of what the client-side app eventually fills in. Content that only exists in the browser DOM after JavaScript execution is not reliably indexed.

301 to a relevant page. For removed pages where a natural successor exists — a product replaced by a newer model, a category consolidated into a broader one, an article merged into a comprehensive guide — a 301 redirect to the most relevant surviving URL is the right choice. It signals to Google that the original URL’s intent is satisfied elsewhere, preserves any inbound link equity, and removes the soft 404 from the crawl surface entirely.

Content Freshness and Decay as a Soft 404 Pathway

Soft 404 is not only an out-of-stock or missing-content problem. Pages that had meaningful content and have decayed — through content deletion, database record cleanup, outdated structured data with no corresponding body content, or template changes that removed content sections — can shift from indexed to soft 404 status over time without any explicit action.

A product page that had 500 words of description in 2022, survived a site redesign where the description was truncated to a paragraph, and is now returning 200 with 80 words may be living on borrowed indexation. Google’s assessment is dynamic — it recrawls, reassesses, and can reclassify pages as soft 404s months after they were previously indexed. Content decay detection that monitors indexed pages for post-publication content reduction catches this before it results in deindexation.

Monitoring at Scale

Individual URL investigation doesn’t scale to thousands of pages. The operational approach is pattern-based.

Export your full soft 404 list from Search Console. Categorize by URL pattern — which templates, which query parameters, which URL path segments concentrate the soft 404 status. Prioritize the patterns that affect the highest-traffic URL types first: active product categories with filter combinations that generate empty results are usually a higher priority than obscure search queries from years ago.

Set crawl-side detection on your own site at regular intervals. A crawl that renders pages, extracts main-content word count, and compares against template baselines will surface new soft 404 candidates faster than Search Console will report them. You want to fix these before Google confirms them.

Track the soft 404 count in Search Console over time. A rising count is a sign that either your content freshness is degrading or your URL surface is expanding faster than your content — both systemic problems. A falling count after you’ve applied fixes is the confirmation that your changes are being picked up. The typical lag between fix and GSC status update is two to six weeks depending on how frequently Google recrawls your site.

Soft 404s are not a signal to dismiss as informational. They are pages that Google has visited, assessed, and decided are not worth indexing — and they are using crawl capacity that your real content needs.

Frequently asked questions

What is a soft 404 and how is it different from a regular 404?
A soft 404 is a page that returns HTTP status 200 but presents content that is effectively empty, erroneous, or useless — like an out-of-stock product page with no meaningful body, an empty search results page, or a 'no items found' message. A real 404 returns HTTP status 404, which tells crawlers the resource doesn't exist. Soft 404s are more damaging because they consume crawl budget without signaling the missing content clearly.
How does Google detect soft 404s?
Google uses a combination of signals including rendered word count, content-to-template ratio, presence of error phrases in the body text, low link density, and comparison against other pages it has crawled from the same site. If a page's main content is substantially thinner than what the same template produces on other URLs, or if it contains phrases like 'not found,' 'no results,' or 'this page does not exist,' Google flags it as a soft 404 candidate.
Should I return a 404 or a 410 for permanently removed pages?
For pages that are permanently gone and will never return, HTTP 410 (Gone) is the more precise signal — it tells crawlers the resource was intentionally removed, not just temporarily unavailable. Google processes 410s faster than 404s for deindexation purposes. Reserve 404 for genuinely missing or unknown resources. Both are preferable to returning 200 with a soft 404 error page.