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

On this page: Quick jump links to help you

• What Is a Soft 404
• Soft 404 vs 404: The Difference That Matters
• What Causes It
• How to Find Them in Google Search Console
• How to Fix It
• Documented vs Widely Believed
• Keep, Fix, Redirect or Retire
• Where They Cluster, by Platform
• Crawling and Ranking Impact
• Sources
• FAQs

Few Search Console entries cause as much confusion as this one. A 404 is unambiguous: the page is gone, and everyone involved knows it. A soft 404 error is a contradiction — your server insists the request succeeded, while the page itself displays “Sorry, we couldn't find that”. Google's crawler has to reconcile those two statements, and the reconciliation is what lands in your report.

The stakes are higher than the label suggests. Pages caught this way are not indexed, but neither are they cleanly dismissed. They keep getting recrawled, they keep consuming the budget Google allocates to your site, and on a large ecommerce or publishing site they can quietly accumulate into the thousands. This guide covers what the error actually means, the six patterns that produce it, how to diagnose it, and — importantly — where the SEO industry's folklore about them diverges from what Google has put in writing.

What Is a Soft 404

The error is a mismatch between two signals a web server sends at the same time. The first signal is the HTTP status code, which is machine-readable and invisible to visitors. The second is the page content itself, which is human-readable. When the status code says 200 (success) but the content says the page does not exist, Google flags the discrepancy.

Google's Page indexing report documentation documents the condition precisely. The page “returns a user-friendly ‘not found’ message but not a 404 HTTP response code”. Note what that definition rests on: the presence of an error message combined with a success status. It is a response-shape problem before it is a content-quality problem.

Google's crawling infrastructure documentation widens the description slightly. Under the 2xx (success) family it states that “if the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error”. That sentence adds one more trigger to the definition — an empty page, with no error message at all, can be enough.

Put the two together and the documented scope is: a 200-status URL that either announces an error or has nothing meaningful on it. That is narrower than many practitioners assume, and the gap matters when you are deciding what to fix. We come back to it in the documented versus widely believed section below.

Soft 404 vs 404: The Difference That Matters

The soft 404 vs 404 comparison is worth making carefully, because the two behave nothing alike once Google has seen them.

A hard 404 is a clean signal. Google's crawling documentation is explicit about what follows: “Google doesn't index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index”. The URL leaves the index, crawl frequency gradually decreases, and the matter closes itself. A 410 (gone) is treated the same way and signals a deliberate, permanent removal.

The soft variant gets none of that resolution. The 200 status invites Google to keep treating the URL as a live page worth revisiting. It will not be indexed — Search Console files it under “Not indexed” — but it also will not be dismissed. You end up with a URL that occupies crawl attention indefinitely while returning nothing of value, which is the worst of both outcomes.

The practical rule: a real 404 is not a problem to be avoided. Google's own guidance on the page indexing report says “404 responses are not necessarily a problem, if the page has been removed without any replacement”. Teams that build elaborate machinery to prevent 404s from ever appearing usually create the soft variety instead, and trade a tidy signal for a messy one.

What Causes a Soft 404 Error

Six patterns account for the overwhelming majority of these errors in practice. The first two are documented triggers; the rest are strongly established through practitioner consensus and Google's own public commentary.

A friendly error page served with a 200

The textbook case, and the one the documentation describes directly. A CMS or application framework catches a missing route, renders a nicely designed “page not found” template, and returns 200 because the template rendered successfully. The design work is invisible to Googlebot; the status code is not. This is a configuration fault in the error handler, not a content problem.

A page with essentially no content

The second documented trigger. An empty page returning 200 can be flagged even with no error message present. Empty collection and category pages are the classic source — a filtered view with zero matching products, a tag archive with no posts, a location page for a region you no longer serve. The template loads perfectly. There is simply nothing inside it.

Redirecting removed pages to the homepage

A widely reported pattern, consistent with Google's stated position that redirects should point at the closest equivalent content. When a removed URL is redirected somewhere that does not answer the original request — most commonly the homepage — the destination can be treated as an irrelevant substitute rather than a genuine replacement. If a discontinued product has no successor, a 404 is more honest than a redirect to the front page. Our guide to 301 vs 302 redirects covers when a redirect is the right instrument and when it is not.

Out-of-stock and expired listings

Ecommerce sites and job boards generate these constantly. A product sells out, an event passes, a listing expires — and the page collapses to a heading plus an “unavailable” notice. Functionally, that is an error message on a 200 response. Whether to keep, redirect or retire these URLs is a genuine strategic decision, not a purely technical one.

Content that only appears after JavaScript runs

If the server returns an empty shell and the real content is injected client-side, Google may evaluate the page before or without that content arriving. The rendered result looks empty, and the empty-page trigger fires. This is one of the harder cases to diagnose, because the page looks perfect in your browser. Our crawlability guide covers rendering diagnostics in more depth.

Server errors disguised as successes

An application throws an exception, the error handler catches it, renders an apology page, and returns 200. Database timeouts and failed API calls behave the same way. From Google's perspective these are indistinguishable from any other error message on a success status.

How to Find Them in Google Search Console

The soft 404 Google Search Console workflow is short, and the second step is the one most people skip.

Open the Page indexing report and look under Why pages aren't indexed. “Soft 404” appears as its own reason with an affected-URL count. Click through for the sample list — bear in mind Search Console shows a sample rather than every affected URL, so treat the count as a signal of scale rather than a complete inventory. The full range of entries in that report is covered in our guide to Google Search Console indexing statuses.

Then verify individually. Google's documented diagnostic step is to “run a live URL inspection test against the page and click View tested page to see a screenshot showing how Google renders the page”. That screenshot is the decisive evidence, particularly for JavaScript-dependent pages, because it shows what Google saw rather than what your browser shows you.

Alongside that, check the raw status code directly — our URL checker and crawlability checker both surface it. Then look for the pattern. As we note in the indexing-statuses guide, if many pages are flagged, examine them for something in common: parameter-heavy URLs, paginated content, a particular template. Fixing the pattern resolves the group; fixing URLs one at a time rarely keeps up.

How to Fix Soft 404 Errors

Google states the remedy in a single sentence: it recommends “returning a 404 response code for truly ‘not found’ pages and adding more information on the page to let us know that it is not a soft 404”. That is two branches, and the soft 404 fix you apply depends entirely on which one the URL belongs to. Everything below flows from one question — should this URL exist?

If the page should not exist: return a real 404 or 410

Correct the status code at its source. Configure the framework's error handler to send 404 rather than 200. Use 410 where removal is deliberate and permanent. Keep the friendly design and the helpful navigation — a good error page and a correct status code are not in conflict, and the entire problem is that most sites ship the first without the second. Then remove internal links pointing at the URL and drop it from your XML sitemap, because a URL you submit for indexing and then 404 sends contradictory signals.

If the page should exist: give it real content

For empty category pages, thin listings and stub pages, the answer is substance, not status codes. Add descriptive copy that stands on its own, populate the listing, or merge the page into a parent that does have content. Where several near-empty variants exist, consolidating them behind a canonical tag is usually cleaner than maintaining all of them.

If a genuine equivalent exists: redirect to it specifically

Point the old URL at the closest matching replacement — the successor product, the current version of the article, the parent category. Resist the temptation to route everything to the homepage. If no close match exists, a 404 is the more honest answer.

If it is a rendering problem: serve content server-side

Move the substantive content into the initial HTML response through server-side rendering, static generation or hydration that does not gate the main content behind client-side execution. Confirm the result with the URL Inspection screenshot rather than your own browser.

Then validate

Once fixes are live, use the Validate Fix button in the Page indexing report. Google recrawls the affected URLs and reports back. Give it time: recrawl frequency varies enormously between a high-traffic page and one Google visits twice a year. A stalled validation usually means some URLs still return the old status, not that the fix failed.

Documented vs Widely Believed

This is where the topic gets genuinely interesting, and where most published advice overreaches.

What Google documents is narrow. The error arises when a 200-status URL carries a “not found” message, an error message, or no content at all. Both documented triggers are about the page announcing — explicitly or by emptiness — that there is nothing there.

What is widely believed is considerably broader: that thin content in general triggers soft 404s, and that any page below some word count is at risk. This is inference, not documentation. Google's published definitions do not describe a thinness threshold, and no public Google source we are aware of specifies one. Thin content certainly carries its own risks — it competes poorly and may not be indexed — but “not indexed because it is weak” and “flagged this way” are different outcomes with different fixes.

The distinction changes what you do. If you believe thin content causes them, you respond by padding pages with words. If you read the documentation, you check whether the page is empty or announcing an error — and if it is neither, you look elsewhere for the cause. Padding an already-populated page will not clear the error, and we have seen teams spend weeks on exactly that.

A second belief worth flagging: that these errors carry a ranking penalty. There is no documented penalty. The damage is mechanical rather than punitive — wasted crawl budget, URLs stuck outside the index, and diluted signals across pages that should have been consolidated. That is real harm, but it is not a penalty, and treating it as one leads to panicked over-correction.

How These Errors Affect Crawling and Rankings

The clearest cost is crawl budget. Google allocates a finite amount of crawling to each site, and every request spent on a URL that resolves to nothing is a request not spent on a page you want indexed. On a small site this is academic. On a site with tens of thousands of URLs, where these errors often cluster in the thousands, it is a measurable drag — and it compounds, because affected URLs keep getting revisited rather than being dropped the way a hard 404 would be.

The second cost is indexation. Pages flagged this way sit under “Not indexed”, which means they cannot rank at all. If a page you actually care about is caught by a rendering fault, you are not fighting for position — you are absent from the results entirely.

The third is diagnostic noise. A report cluttered with hundreds of these entries makes it far harder to spot the genuine indexing problems underneath, which is how real issues survive for months. Cleaning them up is as much about restoring signal as it is about the errors themselves.

For a systematic pass across an entire site, this check belongs in a broader technical audit rather than a one-off fix. Our technical SEO checklist covers where it sits in sequence, and the same sweep runs as part of our technical SEO service. If you would like the errors on your own site identified first, our free SEO audit reports them alongside the rest of your indexing picture.

Keep, Fix, Redirect or Retire: A Decision Table

Most of the difficulty in clearing these errors is not technical — it is deciding, per URL, what the right outcome is. The table below is the shortest version of that decision we have found useful. Work down it in order and stop at the first row that matches.

Situation	Correct outcome	Why
The URL never should have existed — a typo, a broken internal link, a malformed parameter	Return 404	Google removes 4xx URLs from the index and gradually stops requesting them. Fix the link that generated it.
The content existed and was deliberately removed, with no successor	Return 410	Signals a permanent, intentional removal. Handled like a 404 but states the intent more clearly.
The content moved or was replaced by something closely equivalent	301 to the specific replacement	Google treats a 301 as a strong signal that the target should be processed in its place.
The page is genuinely useful but currently empty — a category awaiting stock, a new location page	Add real content	The page should exist; the problem is that nothing is on it. Status codes cannot fix an empty page.
Several near-identical thin variants exist	Consolidate behind a canonical	Concentrates signals on one page rather than splitting them across variants that each look insubstantial.
The page has content, but only after JavaScript runs	Serve it in the initial HTML	Google may evaluate the shell. Rendering, not content, is the fault.
The item is temporarily unavailable and will return	Keep the URL, keep substantive content	An out-of-stock notice on an otherwise bare template reads as an error message. Retain specifications, imagery and alternatives.

The last row is the one teams most often get wrong. There is a real difference between “this product is out of stock” on a page that still carries the full specification, imagery, reviews and links to alternatives, and the same sentence on an otherwise empty template. The first is a useful page with a temporary caveat. The second is an error message wearing a product page's clothes.

Where These Errors Cluster, by Platform

The underlying fault is always the same mismatch, but each platform tends to produce it in a characteristic way, and knowing the pattern shortens the diagnosis considerably.

WordPress

The usual sources are empty taxonomy archives — tag, category and author pages with no posts attached — and plugin-generated routes that render a themed “nothing found” template while the theme returns 200. Search and date archives with no results behave the same way. Check how your theme's fallback template sets its status header, since a custom template that renders successfully will report success regardless of what it displays.

Shopify

Collection pages filtered down to zero products are the dominant source, followed by discontinued products and tag-filtered collection URLs that combinatorially generate far more addresses than there are products to fill them. Because these URLs are generated by the storefront rather than authored by hand, they multiply quietly and rarely appear in anyone's content inventory. Our guide to ecommerce collection pages covers how to keep them substantive.

Headless and JavaScript frameworks

Here the fault is almost always rendering rather than routing. A client-rendered application typically returns 200 with an empty container for every route it recognises, including routes that will resolve to nothing once the data loads. The remedy is server-side rendering or static generation for anything you want indexed, plus an error route that genuinely sets a 404 status rather than merely displaying one.

Custom applications

Framework-level exception handlers are the recurring culprit: a middleware layer catches an unhandled error, renders an apology page, and returns 200 because rendering the apology succeeded. Audit every code path that produces an error page and confirm what status header accompanies it. This is a five-minute check that frequently resolves a four-figure error count.

Sources

The definitions and recommended fixes quoted above are taken directly from Google's own documentation, not from secondary commentary:

• Page indexing report — Search Console Help. Source of the “user-friendly ‘not found’ message but not a 404 HTTP response code” definition, the recommended fix, and the URL Inspection diagnostic step.
• How HTTP status codes affect Google's crawlers — Google crawling infrastructure documentation, last updated 4 February 2026. Source of the empty-page trigger, the 4xx de-indexing behaviour, and the strong-versus-weak redirect signal distinction.

Where this page describes something as widely believed rather than documented, that is a deliberate distinction and is flagged in the text.

Soft 404 FAQs

What does soft 404 mean?

The soft 404 meaning is a URL that behaves like a missing page for humans but like a working page for search engines. Google's documentation describes it as a page that “returns a user-friendly ‘not found’ message but not a 404 HTTP response code”. The word “soft” refers to the status code being wrong rather than the page being wrong — the server says 200 when it should say 404.

What is the difference between a soft 404 and a 404?

A 404 returns a 4xx status code, and Google removes such URLs from the index and gradually stops crawling them. The soft variant returns 200, so Google keeps treating the URL as live: it will not index the page, but it will not drop it either, and it keeps spending crawl budget revisiting it. The hard 404 resolves itself; the soft one does not.

Why does Search Console say submitted URL seems to be a soft 404?

The phrase “submitted URL seems to be a soft 404” means the URL was submitted for indexing through your XML sitemap, and Google then judged the page to be an error page or empty despite the 200 status. Submitting it is what makes it noteworthy: you have explicitly asked Google to index a URL that resolves to nothing. Either fix the page so it has real content, or remove it from the sitemap and return a proper 404.

How do you fix a soft 404 in Google Search Console?

Search Console reports the error but the fix happens on your site. Identify the affected URLs in the Page indexing report, run URL Inspection on a sample and use View tested page to see how Google renders each one, then decide per URL whether it should exist. Return a real 404 or 410 for pages that should not, add genuine content to pages that should, and redirect to a specific equivalent where one exists. Then click Validate Fix and allow time for recrawling.

Are soft 404 errors bad for SEO?

They are harmful but not punitive. There is no documented ranking penalty attached to them. The damage is mechanical: affected pages cannot rank because they are not indexed, crawl budget is consumed by URLs that resolve to nothing, and a cluttered report obscures genuine indexing problems. On a small site the impact is minor; at scale it is worth clearing systematically.

How long does it take for the error to clear?

It depends entirely on crawl frequency. Google must recrawl the URL before it can register the change, so a frequently crawled page may update within days while a rarely visited one can take weeks. Use Validate Fix to prompt the recheck, and do not stack further changes on top because the first appears slow — that usually creates new problems rather than accelerating the old fix.

Can this error happen on a page that has content?

Yes, and it is one of the most common surprises. The usual cause is rendering: the server returns a near-empty shell and the content arrives only after JavaScript executes, so Google evaluates an empty page even though your browser shows a complete one. The other cause is an error message sitting inside an otherwise populated template, such as an out-of-stock notice. Use the URL Inspection screenshot to see which applies.

Should you redirect a soft 404 to the homepage?

Generally no. A redirect should point at the closest equivalent content, and the homepage almost never answers the request the original URL served. Redirecting removed pages to the front page is a widely reported way of producing exactly the problem you were trying to avoid. If a genuine replacement exists, redirect to that specific page; if it does not, return a 404 and let the URL retire cleanly.