Soft 404 in Google Search Console: What It Actually Means (And How to Fix It)

If you've opened the Page Indexing report and found a batch of URLs sitting under Soft 404, the first reaction is usually confusion: the page loads fine in your browser, it returns a normal 200 OK, and nothing about it looks like a 404. So why is Google calling it one?

The short answer: a soft 404 isn't about your server's status code at all. It's Google's judgment call that a page behaves like a missing or broken page even though it technically isn't one — and that judgment call is usually right more often than site owners expect.

What "Soft 404" Actually Means in Search Console

A real 404 happens when your server tells the browser (and Googlebot) "this page doesn't exist" via an HTTP status code. A soft 404 is different: your server responds 200 OK as if the page is fine, but Google's crawler decides the content on that page reads like a missing, empty, or "nothing here" page anyway.

Google isn't reading your status code and overriding it out of spite. It's pattern-matching the page's actual content against what dead or empty pages typically look like — thin bodies, generic "no results found" text, empty product/category templates, or pages that just redirect visually via JavaScript without a real server-side redirect.

Why Google Calls a 200-Status Page a "404"

This distinction exists because status codes are easy to fake or misconfigure, but content is harder to fake. A few concrete patterns trigger it:

• Empty or near-empty templates — category pages, tag archives, or search-result pages that render a layout but no actual content when nothing matches.
• "Item not found" pages that still return 200 — common on e-commerce or directory-style sites when a product is delisted but the URL isn't removed or redirected.
• Client-side redirects — a page that uses JavaScript (window.location) to send users elsewhere, but Googlebot briefly sees the original page's thin content before the redirect fires.
• Placeholder or "coming soon" pages left live long after they should have been replaced or removed.

The Most Common Causes of Soft 404s

For blogs specifically, the most frequent triggers are usually one of these:

| Pattern | Why it triggers a soft 404 | |---|---| | Deleted post left live with no content | Server returns 200, but the page body is essentially blank | | Tag or category archive with zero posts | Template renders, but there's nothing to show | | Search results page for a query with no matches | Same shell template, no unique content | | Migrated URL redirecting via JavaScript only | Googlebot reads the pre-redirect page as the "real" content |

None of these are server errors. That's exactly why status-code monitoring alone won't catch them — you need to actually look at what each flagged URL renders.

How to Confirm It's Really a Soft 404 (Not a Coverage Bug)

Before changing anything, verify the report is pointing at a real problem:

1. Open the specific URL Search Console lists under Soft 404 in a normal browser tab (not a cached view).
2. Check whether the page has genuine, unique content or is effectively empty.
3. If it looks completely normal and content-rich, use the URL Inspection tool to see exactly what Googlebot rendered — a JavaScript-dependent redirect or a rendering delay can make a real page look empty to the crawler even though a human never notices.
4. Cross-check the URL against your CMS: was this post deleted, unpublished, or merged into another page recently?

How to Fix a Soft 404, Status by Status

The fix depends on what the page is supposed to be now:

Page should no longer exist — Return a real 404 or, better, a 410 Gone status instead of a soft-looking 200 page. This tells Google clearly and immediately that the URL is gone, rather than leaving it to infer that from thin content.

Page moved or was merged into another URL — Use a proper server-side 301 redirect to the replacement page. A JavaScript-only redirect is not enough; Googlebot needs the HTTP-level signal.

Page is a legitimately empty archive (e.g., an empty tag page) — Either add a noindex meta tag so Google stops evaluating it for indexing at all, or exclude empty archive pages from your sitemap so they aren't submitted as if they were content pages.

Page is temporarily thin but will have content soon — If it's genuinely a work in progress, keep it unindexed with noindex until it has real content, then remove the tag once it's ready.

Soft 404 vs. Real 404 vs. Noindex: Why the Difference Matters

It's worth being precise about these three, because mixing them up leads to the wrong fix:

• A real 404 tells Google "this doesn't exist" at the protocol level — clean and unambiguous.
• A soft 404 tells Google "this returns 200, but reads like it doesn't exist" — Google is essentially overriding your status code with its own judgment.
• A noindex tag tells Google "this exists and is fine, just don't index it" — a deliberate exclusion, not an error state.

Leaving a page as a soft 404 when you actually meant one of the other two states is what causes it to sit in the report indefinitely instead of resolving.

Keeping Soft 404s From Creeping Back

Soft 404s tend to reappear in the same few places: content-management workflows that unpublish posts without redirecting them, faceted navigation that generates empty filter combinations, and site migrations that rely on client-side routing instead of server redirects. A quick internal-linking audit can also help here — pages that are still linked to internally after being deleted are far more likely to get re-crawled and re-flagged, so cleaning up stale internal links matters as much as fixing the page itself. The same is true of the broader "Discovered" vs. "Crawled" status confusion, where Google's index-coverage judgment call — not your server config — decides the outcome.

Since none of this shows up as a server error in the usual sense, it's easy to go weeks without noticing a batch of soft 404s piling up, especially if you're only watching uptime or status-code monitors. Traffic Monitor pulls the Page Indexing report automatically and flags status changes — including new soft 404s — so you don't have to manually revisit the Search Console coverage tab to catch them early. It's the same underlying report that also surfaces issues like duplicate pages without a user-selected canonical, so a single coverage sweep tends to catch several of these classification issues at once. If your Search Console data has felt slow or inconsistent while you're trying to track this down, it's also worth ruling out a reporting delay before assuming the fix didn't work.

Once you've resolved the underlying cause — a real 404, a 301, or a noindex tag, depending on the case — request indexing (or removal) once and let it recrawl rather than repeating requests on an unchanged page. Soft 404 is Google's way of saying "I looked, and this isn't really a page" — the fix is always to make that statement either true or false on purpose, instead of leaving it accidental.