Soft 404s: when your store tells Google everything is fine and it isn't

A customer clicks a link to a product you stopped selling eight months ago. The page loads. There's a header, a footer, maybe a friendly "this item is no longer available" message. Nothing looks broken. But under the hood, your server just told Google's crawler that this dead page is alive and well, status code 200, same as any working page on your site. Do that on enough pages, over enough months, and you've quietly taught Google that your store's signals can't be trusted.

What a soft 404 actually is

A soft 404 happens when a page that should be gone (discontinued product, expired promotion, deleted collection) returns a normal 200 OK status instead of a proper 404 (Not Found) or 410 (Gone). The page might display "out of stock" or "product unavailable" text, but the HTTP status code underneath says everything is fine.

Search engines don't read your page copy the way a shopper does. Google's crawler checks the status code first. If it sees 200, it assumes the page is a legitimate, indexable part of your site, and it keeps crawling it, keeps ranking it, and keeps sending it to Google Search Console as a normal URL, even as the content grows increasingly useless.

This is different from a page that's merely thin or low quality. A soft 404 is a mismatch between what the server says (this page exists and works) and what's actually true (this page has nothing left to offer). Google's own documentation on soft 404 errors describes exactly this pattern, and it's one of the more common issues flagged in Search Console's Page Indexing report.

Why this quietly poisons crawl signals

Google allocates a finite amount of crawling attention to any given site, based on its size and how reliable its signals have been. Every soft 404 that Googlebot revisits is a page that doesn't need re-crawling, spending budget that could go to your new arrivals or updated pricing pages instead. On a store with a few dozen products this barely registers. On a store with thousands of SKUs and years of discontinued items, it adds up to a meaningful drag.

The bigger issue is trust, not budget. When Google repeatedly crawls a page that claims to be fine (200 status) but contains a "sold out" or "page not found" message in the visible text, it has to decide which signal to believe. Sometimes it gets this right and quietly demotes the page. Often it takes months, during which the page sits in the index producing a poor click-through experience: someone searches for the product, clicks your listing, and lands on a dead end. That mismatch between search intent and page reality is exactly the kind of signal that erodes a domain's broader search performance, not just the one URL.

This is closely related to the crawl-budget problems described in Google cannot buy from you if it cannot crawl you, and it compounds with other quiet leaks like redirect chains left over from a migration. None of these show up as a dramatic traffic cliff. They show up as a slow, six-month erosion that's hard to trace back to a cause.

Where soft 404s hide on Shopify, WooCommerce, and BigCommerce

Each platform handles deleted or unpublished products differently, and the defaults aren't always safe.

On Shopify, deleting a product typically returns a proper 404, but unpublishing one, or letting a product go out of stock with "continue selling when out of stock" disabled, can leave the page reachable and returning 200 while showing a sold-out state. Theme customizations that add a soft "coming back soon" message on old product URLs are a common culprit.

On WooCommerce, deleting a product to trash usually triggers a 404, but many stores instead set products to "draft" or private status to preserve reviews and history. Depending on the theme, a draft product page can still resolve with a 200 status for logged-out visitors, especially if a caching layer served a stale copy before the status change propagated.

On BigCommerce, disabling a product removes it from navigation and search but the direct URL sometimes remains live with a 200 until the product is fully deleted, which some store owners avoid doing because it breaks internal links and loses SEO history they didn't realize they could preserve with a redirect instead.

In all three cases, the safe pattern is the same: when a product is genuinely gone for good, either 301 redirect its URL to a relevant category or replacement product, or let it return a real 404/410 and remove it from your sitemap. What you want to avoid is a live URL, a 200 status, and no redirect. It's worth checking this against your sitemap health as well, since discontinued products often linger there long after they should have been dropped.

How to check for soft 404s yourself

Google Search Console's Page Indexing report has a status specifically called "Soft 404," separate from "Not found (404)" and "Crawled, currently not indexed." It's usually the fastest way to see the scope of the problem for your store. Open the report, look for that label, and review the list of affected URLs. It's normal for a store with hundreds of past products to have a handful; it's a signal worth acting on when the count climbs into the dozens or represents a meaningful share of your total indexed pages.

Manually, you can spot-check by picking a handful of known-discontinued product URLs and checking their response headers (most browsers' developer tools show this under the Network tab) to confirm whether they're returning 200 when they should return 404 or 410, or a 301 when a redirect makes more sense.

The underlying pattern to watch for: does the visible page content say "unavailable," "out of stock," or "not found," while the technical status code says 200? That mismatch is the soft 404, and it's worth fixing consistently across your catalog rather than one URL at a time.

Building it into routine seo health monitoring

Soft 404s rarely arrive as a single event. They accumulate one discontinued product, one deleted collection, one abandoned seasonal page at a time, which is exactly why they're easy to miss in day-to-day operations. Nobody schedules a monthly review of every product they stopped selling last year.

This is where seo health monitoring earns its keep as a routine check rather than an occasional audit. Cassian™ checks your store's crawlability and status codes on an ongoing basis, alongside sitemap validity, broken internal links, and the Cassian Score™ that summarizes overall store health, so a growing pile of soft 404s shows up as a flagged issue instead of a mystery six months later when organic traffic to your category pages has quietly softened. It won't rewrite your product-deletion workflow for you, but it will tell you when that workflow is leaving 200-status dead ends behind.

The quiet fix

None of this requires a redesign. It requires making sure that when a product truly leaves your catalog, your store's response code says so, either through a clean 404/410 or a sensible 301 redirect, instead of a cheerful 200 that quietly tells Google everything is fine when it isn't. Check your Search Console soft 404 report this month, clear the backlog, and it's one less slow leak eating into a store that's otherwise healthy.