Soft 404 Errors: What They Are and How to Fix Them

A soft 404 is a page that returns an HTTP 200 OK status while its content looks, to Google, like a page that is missing or empty. If you opened the Page Indexing report in Google Search Console and found a group labeled "Soft 404," this guide is for you, whether you are an in-house SEO, a technical founder, or a developer who just needs the label gone. The confusing part is that nothing is technically broken. Your server reports success, and Google overrules it. Below is what a soft 404 actually is, why it happens, how to find every one on your site, and the correct fix for each cause.

The short version

• A soft 404 is Google's judgment, not a server status code. Your server still returns 200 OK; Google decides the page should have been a 404.
• It shows up in the Page Indexing report as "Submitted URL seems to be a Soft 404" or simply "Soft 404."
• The right fix depends on the cause: return a real 404 or 410, add genuine content, apply noindex, or redirect to a true equivalent.
• You can catch the thin-200 pattern yourself with a crawl that flags pages returning 200 with little or no content, before Google ever labels them.

What is a soft 404?

A soft 404 is a page that answers a request with a 200 OK status code while showing content that reads as missing, empty, or not useful. The status code claims the page exists and loaded correctly. The content says there is nothing here. Google resolves that contradiction in favor of the content: it treats the URL as if it had returned a 404 and files it under "Soft 404" in the Page Indexing report.

The key point is that no server ever sends a "soft 404" status. There is no such HTTP response code. It is a label Google applies after Googlebot reads the page and concludes the content does not match the success the server reported. A deleted product page that now renders an empty template, still responding 200, is the classic example.

How is a soft 404 different from a real 404?

A hard 404 tells the truth, and a soft 404 does not. A hard 404 returns the correct 404 Not Found status, so Google knows the page is gone and can drop it cleanly. A soft 404 returns 200 OK for a page that has no real content, so Google has to decide for itself what the page is.

Aspect	Hard 404	Soft 404
Status code	404 Not Found (or 410 Gone)	200 OK
What Google reads	The page is gone	The page exists but is empty or thin
Crawl behavior	Stops recrawling it over time	Keeps recrawling a page that should not exist
Index impact	Removed cleanly	Clutters the index and wastes attention
Action needed	Usually none	Investigate the cause and fix it

The 200 is the whole problem. Because the server reports success, Googlebot keeps returning to a URL that carries no value, which wastes crawl budget on large sites and leaves a worthless page eligible for indexing. It also muddies diagnosis, because a soft 404 sits in a different Search Console bucket than crawled, currently not indexed, and the two call for different responses.

What causes a soft 404?

Most soft 404s trace back to five patterns, and each one is a page that renders successfully with nothing worth indexing behind it.

• Empty tag or category pages: a CMS tag with no posts, or a category stripped of its products, still renders a 200 template with a heading and an empty listing.
• "No results" pages returning 200: an internal search or filter result that says "No results found" while the server answers with success.
• JavaScript render failures: the HTML shell loads with 200 but the main content never renders for Googlebot, so the page looks blank to the crawler.
• Thin stub pages: auto-generated or placeholder pages with a title, a line of boilerplate, and nothing substantial.
• Redirects to the wrong target: a deleted page redirected to the homepage or an unrelated page, which Google can treat as a soft 404 because the destination does not answer the original request.

In my experience, empty tag and category pages are the most common source on content-heavy sites, because every CMS generates them automatically and almost nobody prunes them. A blog that creates a tag for a single post, then deletes the post, is left with a live, empty, 200-returning tag archive that no one remembers exists.

How do you find soft 404s on your site?

There are two ways, and they differ in timing. One is reactive, after Google has already decided, and one is proactive, before Google gets there.

Google Search Console: open the Page Indexing report and look for the rows labeled "Soft 404" and "Submitted URL seems to be a Soft 404." These are Google's own labels, applied in Search Console after Googlebot has crawled the page. Google's documentation on the Page Indexing report explains where each status appears and how to request validation once you have fixed the underlying pages.

A crawl of your own: a site crawler can flag pages that return 200 with thin or empty content, which is the exact pattern Google later labels a soft 404. Running your own crawl means you find these pages before they are costing you crawl attention, rather than waiting for the report to fill up. GrowthHasten's free Site Audit does this across a whole site as a deterministic check, and the mechanism is worth understanding in its own right, which is covered further down.

Which fix does each soft 404 need?

The fix is not the same for every cause, and applying the wrong one creates a new problem. This table maps each situation to the correct response.

Situation	What is happening	Correct fix
Page is genuinely gone, with no replacement	A dead URL returning 200	Return 404 or 410
Empty tag or category with no value	Auto-generated archive, no listings	noindex, or return 404/410 if it should not exist
"No results" search or filter page	A 200 response with an empty list	Return 404, or noindex; never leave it at a bare 200
JavaScript render failure on a real page	Content missing from what Googlebot sees	Fix rendering so the content is in the response; keep 200
Thin stub with a genuine purpose	A real page with too little content	Add substantial content; keep 200
Deleted page with a close equivalent	Content moved or merged	301 redirect to the genuine equivalent

The one-line rule for 404 vs 410 vs 301: use 301 when a real equivalent exists for the reader, 410 when the page is gone for good and nothing replaces it, and 404 as the safe default whenever you are not certain the removal is permanent.

How do you fix each type of soft 404?

Every fix comes down to one of four moves, chosen by what the page should be rather than what it currently is.

Return the right status code: if the page should not exist, stop returning 200 for it. Configure the server or CMS to send a genuine 404 or 410 so Google can remove it. This is the correct response for dead URLs and for empty pages that have no reason to stay live.

Add real content: if the page should exist and rank but is thin, the fix is content, not a status change. A stub category page becomes a real page once it has a description, genuine listings, or supporting detail that answers why someone landed there.

Apply noindex where the page should stay but not rank: some pages need to exist for users yet have nothing to offer search, such as certain filtered views. Add a noindex directive so the page stays available to visitors while leaving Google's index. Do not reach for noindex on a page you actually want to rank; fix its content instead.

Redirect only to a genuine equivalent: when content has moved or merged, send the right redirect status code to the page that now answers the request. The common mistake here is redirecting every deleted URL to the homepage, which Google frequently treats as a soft 404 of its own, because the homepage does not answer the original query.

Should you return a 404 or a 410?

Either one clears a soft 404, so the choice matters less than people assume. A 410 Gone signals that the removal is permanent, and Google can process it slightly faster than a 404. A 404 Not Found is the safe default and says only that the page is not there right now.

The decision that actually matters is to stop returning 200 for a page with no content. Reach for 410 only when you are confident the page is gone for good and will not return. If there is any chance the content comes back, or if you simply cannot be sure, use 404. Google's reference on HTTP status codes sets out how it handles each response, and both 404 and 410 ultimately remove the URL from the index.

Do soft 404s hurt SEO?

Not as a direct penalty, but they still cost you. Google does not demote a site for having soft 404s. What they do is waste crawl budget on pages that should not exist, and the affected pages will not rank, because Google has already decided they are empty. On a small site the waste is negligible. On a large one it is real, because every recrawl of a dead URL is attention not spent on a page you care about.

There is a second, quieter cost. If your own navigation points at pages that have silently become soft 404s, you are sending readers and link equity into dead ends. Clearing those is part of the same work as fixing broken internal links. Treat soft 404s as a clarity problem to resolve, not an emergency to panic over: fix them so Google spends its time on your real content.

How do you catch soft 404s before Google does?

Run a crawl of your own that checks for the exact signal Google checks: a 200 response paired with thin or empty content. That is the mechanism behind GrowthHasten's Site Audit, and the design decision behind it is the point. When we built the check for this, I made it deterministic on purpose: it reads the markup already parsed, flags every page that returns 200 with little or no meaningful content, and returns the same finding on the same page every time. A thin-200 page is reported as a fact, not guessed at.

One honest distinction matters here. Our crawl detects the thin-200 pattern, which is what precedes a soft 404. It does not assign Google's "Soft 404" coverage label; that label is Google's, and it lives in the Page Indexing report after Googlebot has made its own judgment. Catching the pattern early simply means you fix the page on your schedule instead of discovering it on Google's.

The durable approach is a habit rather than a one-time sweep: treat status-code honesty as part of publishing, not cleanup. Make the Page Indexing report a monthly check, and before you delete or unpublish anything, decide what its URL should return. This week, open the Page Indexing report, find any group labeled "Soft 404," and resolve the first one end to end: confirm the cause, choose the correct status code or fix, and request validation.