Silent soft 404s caused 90% traffic loss after site migration

What happened

A Search Engine Land case study published May 12 documents how a publisher lost roughly 90% of organic traffic after a migration triggered widespread soft 404 classification by Google. Pages returned HTTP 200 status codes but contained thin or generic content that Google’s systems flagged as “not found.” The deindexing happened silently over months.

The core problem: pages that looked fine to the site’s own monitoring were being treated as soft 404s by Google’s content-quality classifiers. By the time the traffic collapse became obvious, thousands of URLs had already dropped from the index.

Why it matters

Soft 404s are invisible to basic monitoring. Your server returns 200, your uptime checks pass, and your analytics show no errors. Meanwhile, Google evaluates content density and page-quality signals to determine whether a 200-status page contains meaningful content. When those classifiers decide a page looks empty or generic, Google deindexes it without any HTTP-level warning.

The HTTP 200 status code signals that the request succeeded, with the response payload depending on the request method used. When a page returns 200 but shows a boilerplate template with no real content, Google sees a semantic mismatch. The status code says “success” while the page says “nothing here.”

The lag between deindexing and traffic loss makes this worse. Google may start flagging pages as soft 404s before the traffic impact becomes visible in analytics. The lag can vary significantly. By the time you notice a drop, Google has already deprioritized your crawl budget and moved on.

Site migrations are the most common trigger. A CMS platform change that alters URL structure can leave old URLs serving generic “product not found” templates at 200 status. A template redesign that strips byline metadata or reduces visible text can push existing indexed pages into soft 404 territory. A subdomain consolidation with broken internal linking can starve new URLs of crawl frequency.

E-commerce sites with large catalogs, publishers reorganizing URL schemes, and multi-domain properties doing consolidation are all at high risk. For the specific case of out-of-stock or empty category pages triggering soft 404s, see our earlier coverage. The pattern is consistent: pages appear functional, but Google’s quality evaluation drops them from the index.

What to do

Check Search Console’s indexing reports first. The Pages report in Google Search Console shows URLs classified as “Crawled - currently not indexed” and “Soft 404.” A spike in either category after a migration is your earliest signal. Don’t wait for traffic dashboards to confirm what GSC already shows.

Audit content on affected URLs manually. Open the flagged pages in a browser and compare them to pages Google is still indexing. Look for missing product details, stripped metadata, thin text surrounded by heavy navigation chrome, or generic error messages served with a 200 status. Google’s soft 404 detection looks at content signals, not just status codes.

Fix the content gap before resubmitting. Adding unique, substantive content to flagged pages is a prerequisite for recovery. Resubmitting URLs through Search Console without fixing the underlying quality issue won’t help. If old URLs serve empty templates, either redirect them to the correct new URL with real content or return a proper 404/410 status code.

Return honest status codes for dead pages. If a page no longer has content, serve a 404 or 410 instead of a 200 with a generic template. Google handles real 404s predictably. Soft 404s create ambiguity that works against you. Before returning 404/410 at scale, audit whether affected URLs carry significant inbound links or ranking history. For URLs with link equity worth preserving, a 301 redirect to the best matching live page is preferable to a 404.

Monitor beyond status codes. Many crawl tools check HTTP status codes and response headers but don’t apply content-quality scoring the way Google does. Even tools with JavaScript rendering won’t replicate Google’s quality classifiers. This is why GSC’s indexing data is an essential complement, not replacement, for crawl monitoring. Run a weekly check comparing indexed page counts against your expected page inventory.

Watch out for

Redirects don’t fix soft 404s automatically. If you 301 from a soft 404 page to a destination that also has thin content, you’ve moved the problem to a new URL. Google evaluates the destination page’s content independently. The redirect target should be the most topically relevant page with substantive content, not just any non-thin page. Redirecting unrelated URLs to the homepage or a generic category page is explicitly called out in Google’s 404 documentation as problematic. Google recommends returning proper 404/410 status codes for non-existent pages rather than redirecting them to unrelated destinations. Map each redirect target to the most relevant live page instead.

JavaScript rendering can trigger soft 404 risks. If your pages rely heavily on client-side JavaScript to populate main content, the initial HTML Googlebot sees may be thin. CSR-heavy stacks, React SPAs, headless CMS frontends, and similar architectures, are especially vulnerable: the HTML shell may pass status-code checks but fail content-quality evaluation. (For a related failure mode, see our coverage of Next.js streaming metadata issues.) Use the URL Inspection tool to compare the rendered version against what Googlebot actually receives, and consider server-side rendering for critical content.

Recovery is slow even after fixes. Recovery typically takes weeks, not days. Google may deprioritize crawl budget for URLs it previously classified as low-quality. After fixing content issues, submitting an updated sitemap and requesting indexing in GSC signals to Google that content has changed, but does not guarantee faster re-crawling or reindexing.