Soft 404 in Google Search Console: What It Means and How to Fix It

Google Search Console's Page indexing report has a row called soft 404, and it catches two very different situations. Here are two pages that can both show up there: an out-of-stock product page that correctly says "no longer available," and a full, well-written article that Google decided reads like an empty page. Only one of those is actually broken - and most guides jump straight to "fix your server" without telling you which one you're looking at.

Quick Answer

A soft 404 means your page returned a normal 200 OK status, but Google decided the content looks like a "not found" page anyway - usually because there isn't enough unique, substantive content for Google to treat it as a real page worth indexing. It's rarely a server bug. Google's own documentation describes it as a content judgment, not a broken response code. A noindex tag doesn't fix the underlying signal if the pattern repeats across many similar URLs - thin category pages, empty search results, near-duplicate templates - because Google reads that as a pattern across your site, not one bad page. New, programmatic, or JavaScript-heavy pages are the most common source, since what Googlebot's first pass reads can be much thinner than what a browser renders. The fix is almost always adding real content, not changing HTTP status codes.

Where You'll See This in Search Console

Open Search Console and select your property. In the left sidebar, under Indexing, click Pages. Scroll to the table headed "Why pages aren't indexed" and look for the row labeled "Soft 404." Click it to see a sample of affected URLs. You can also check a single address at a time by pasting it into the URL Inspection search bar at the top of Search Console.

What Google Actually Means by Soft 404

Google's own Page indexing report documentation defines it precisely: "The page request returns what we think is a soft 404 response. This means that it returns a user-friendly 'not found' message but not a 404 HTTP response code." Read that again slowly, because the definition is about the message, not the header. Your server can return a perfectly valid 200 OK, with no error anywhere in the response - Google is judging what a human would conclude after reading the page, not what the status line says.

The Three Real Causes

Genuinely empty or thin pages returning 200 instead of 404. Out-of-stock products, empty search-result pages, and blank category pages are the classic case - the page technically loads, but there's nothing on it. Templated pages where boilerplate outweighs unique content. If the header, sidebar, and footer make up most of the HTML and the actual unique text is a sentence or two, Google's content-to-boilerplate ratio check can read that as a not-found page even though something clearly rendered. New pages with no established topical authority, where the visible content doesn't strongly match the title and URL. This is the one that catches people off guard, because the page isn't empty at all - it just doesn't read as confidently on-topic as its title promises, and a brand-new page has no track record yet to earn Google the benefit of the doubt.

The Check Almost Nobody Runs

Most people judge a soft 404 by opening the URL in a browser and seeing it looks fine. That tells you nothing, because your browser executes JavaScript and Googlebot's indexing decision is often made from what's in the raw HTML response before any client-side rendering happens. Use Search Console's URL Inspection tool, click "View Crawled Page," and check both the screenshot and the HTML tab - not just view-source in your browser, the actual HTML Google says it fetched. If the rendered screenshot looks complete but the HTML tab is nearly empty, you've found a JavaScript-rendering gap, not a content gap - and it's a completely different fix than writing more copy.

The Mistake That Makes It Worse

The instinct is to make the report row disappear, and the fastest way to do that is to force a real 404 - delete the page, or block it in robots.txt. That does stop Google from flagging it. It also means you've given up the URL entirely, along with whatever ranking potential it had, instead of fixing the actual pattern behind it. If the same thin-template problem exists on fifty other pages, removing one doesn't touch the other forty-nine - and a robots.txt block additionally prevents Google from ever re-crawling the page to notice you've since fixed the content, since a blocked page can't be re-evaluated.

If the Page Should Genuinely Not Exist

Then stop treating this as a bug and just let it resolve. Return a real 404 or 410 for permanently gone content, and skip the soft-404 debate entirely - Google's coverage report is describing reality correctly in this case. No further action is needed, and there's no ranking penalty attached to a page that's supposed to be gone.

If the Page Should Rank

Then the fix is content, not configuration. Expand the page until it clearly, substantively covers what its title and URL promise - specific details, not padding. If the thinness is JavaScript-rendering related, make sure the meaningful content is present in the initial server response rather than waiting on client-side scripts to fill it in. Once you've made the change, run the Test Live URL check in Search Console to confirm Google now sees real content, then request indexing.

Prioritizing When You Have Many Soft 404s

A single soft 404 rarely deserves urgent attention, but dozens on the same site usually do - and not all of them are worth fixing first. Start by sorting the sample list by URL pattern instead of working through it alphabetically or by date. Group the affected addresses by directory or template - product pages, category pages, blog posts, location pages - and count how many fall into each group. The group with the most URLs and the clearest commercial intent behind it, a product category people actually search for rather than an obscure filter combination, is where fixing the underlying template pays off across the most pages at once, instead of fixing one URL and leaving the same pattern live on the other ninety.

Soft 404 vs Its Neighboring Statuses

This is exactly the pattern behind a lot of thin, mass-produced AI content: a page that technically has words on it but doesn't cover its topic with enough depth or specificity to read as a real answer. Rocketito's content generation is built against this failure mode directly - every article is written to genuinely cover its topic with real detail, tables, and specifics rather than the kind of generic filler that reads thin to both readers and Google. Run a free LLM SEO check to see how your current content actually reads before you publish more of it.

Is thin content costing you indexing? Rocketito writes full-depth, topically matched articles instead of thin stubs - the exact pattern that triggers soft 404s at scale. Check your AI visibility free. Start free trial

FAQ: Soft 404 in Search Console

If you're also seeing the neighboring status in your report, see our guide to Crawled - currently not indexed, where the page loads fine but Google still chose not to index it.