# Why am I getting soft 404 errors after my website redesign?

> Soft 404s appear after a redesign when old URLs resolve to a page that has no real content, an empty template, a near-blank search result, or a generic landing page, so Google treats it as missing even though it returns a 200 status. The fix is to map each old URL to the right new page with a 301, or return a true 404 for pages you retired. WPBuildAI builds the full redirect map during a migration so old URLs land on real content, not soft 404s.

Source: https://wpbuildai.com/why-am-i-getting-soft-404-errors-after-website-redesign/
By lawrence-arya · 2026-06-12

---
Soft 404s after a redesign mean your old URLs are still resolving, but to pages with no real content: an empty template, a near-blank internal search result, or a generic landing page. The server returns a success status, so the URL looks alive, but Google sees nothing meaningful and flags it as effectively missing. The cause is almost always the same: the redesign changed the URL structure and the old addresses were never mapped to real new pages. The fix is to send each old URL to the right new page with a 301, or to return a true 404 for pages you genuinely retired. WPBuildAI builds the full redirect map during a migration, so old URLs land on real content instead of soft 404s.

## What a soft 404 actually is

The name is a contradiction on purpose. A soft 404 is a page that returns HTTP 200, the success code that means "here is your content," while delivering nothing a reader or a search engine can use. The server says the page is fine; the page says otherwise. That mismatch is the whole problem, because everything downstream, crawling, indexing, ranking, trusts the status code first. A real 404 says "this is gone" and is handled cleanly. A soft 404 says "this is fine" and then fails to deliver, which leaves search engines to detect the emptiness themselves and reclassify the page. Understanding it as a lie told by the status code is the fastest way to reason about every cause and fix below.

## Why soft 404s are worse than real ones

A real 404 is honest: it tells search engines the page is gone, and they drop it cleanly without wasting effort. A soft 404 lies, returning a 200 while showing nothing useful, so engines keep revisiting a page that will never satisfy them, burning crawl budget that should go to your real pages, and indexing stays muddled because the system cannot tell whether to keep the URL or drop it. Google's [site move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) is explicit that old URLs need to resolve to real, relevant destinations, and that redirecting everything to the homepage is itself treated as a soft 404. The dishonest status is what makes the soft version more corrosive than an honest not-found.

## What actually causes them after a redesign

The redesign rebuilt your URLs and the old ones were left to fend for themselves. Some now hit an empty new template that renders a shell with no content, some hit a catch-all page the new theme serves for unknown paths, and some hit an internal search results page with nothing in it. The 2024 [Web Almanac](https://almanac.httparchive.org/en/2024/) shows how many URLs a real site accumulates over the years, archives, tag pages, paginated lists, old campaign landing pages, and how easy it is to miss whole groups of them when the structure changes. The ones you miss do not vanish; they resolve to whatever the new site shows for an unmatched path, and that is the soft 404.

## How Google decides a page is a soft 404

Search engines do not take the 200 at face value forever. When a page returns success but contains little or no meaningful content, looks like an error message despite the status, or is nearly identical to many other thin pages, the engine concludes the page is effectively absent and labels it a soft 404 in the Search Console coverage report. This is a content judgement layered on top of the status code, which is why a perfectly valid-looking 200 can still be flagged. Knowing the heuristic helps you diagnose: if the destination has real, distinct content, it will not be a soft 404; if it is a thin shell or a generic page, it will, regardless of what the server claims.

## A worked example: the category that became an empty search page

Picture a blog that retired its old tag-based archives in a redesign. The URL `/tag/migration/` used to list a dozen posts. After the rebuild, the new theme has no tag archives, so that path falls through to the site's internal search, which returns "0 results" with a 200 status. To a visitor it looks like a dead end; to Google it is a soft 404, because the page exists, succeeds, and says nothing. The right fix is a 301 from `/tag/migration/` to the closest real page, perhaps a relevant category or a pillar article, so the URL resolves to content that matches what it used to offer. Multiply that by every retired archive and you have a coverage report full of soft 404s from a single overlooked group of URLs.

## How to find every soft 404

You cannot fix what you have not listed. Start with Search Console's coverage report, which names the URLs it has classified as soft 404s, then widen the net, because the report only shows what Google has recrawled so far. Crawl the old URL set, from your pre-launch inventory, analytics, and the old sitemap, and check what each one returns now: a 200 with thin content is a soft 404 in waiting even if Google has not flagged it yet. Reconcile that against your redirect rules to find the URLs with no rule at all. The goal is a complete list of old URLs and their current fate, so the fix below covers every one rather than only the handful already reported.

## How to clear them, step by step

1. **List every affected old URL** from the coverage report plus a crawl of your old URL set, so the fix is complete, not partial.
2. **Map each to its true new page** and add a 301, choosing the closest relevant destination, the same care behind [301 redirects preserving SEO](/blog/do-301-redirects-preserve-seo-when-changing-platforms/).
3. **Return a real 404 or 410** for pages that genuinely no longer have an equivalent, so engines drop them cleanly.
4. **Avoid the homepage catch-all**, since a blanket redirect there is treated as another soft 404.
5. **Validate and request reindexing** in Search Console, then watch the coverage report clear over the following crawls.

Worked in that order, you fix the cause, an unmapped URL, rather than just suppressing the symptom.

## Why redirecting everything to the homepage backfires

It is tempting to point every orphaned URL at the homepage and call it done, but Google explicitly treats an irrelevant blanket redirect as a soft 404 in its own right. The reasoning is sound: a user who wanted a specific product page does not get an equivalent by landing on the homepage, so the redirect has not actually resolved their request. The same applies to sending everything to a generic category. The redirect has to go somewhere genuinely related, or it does not count as a real destination. This is the single most common "fix" that recreates the problem it was meant to solve, which is why mapping to the closest relevant page matters more than simply having a redirect.

## When a soft 404 is the right outcome

Not every flagged URL needs rescuing. If a page is genuinely gone with no equivalent, a discontinued one-off campaign, a deleted thin post, a duplicate that should never have existed, the correct outcome is a clean 404 or 410, not a forced redirect to something unrelated. Returning a true not-found status is the honest signal that tells engines to drop the URL and stop spending crawl budget on it. The mistake is leaving it as a soft 404, a 200 with nothing on it; the fix is to make the not-found explicit. So part of clearing soft 404s is deciding, per URL, whether it deserves a redirect or an honest goodbye, rather than treating every one as something to redirect.

## Preventing them in the next migration

Soft 404s are a symptom of skipping the inventory step, so the prevention is to never skip it. Before the next launch, crawl the old site to capture every URL, reconcile it against analytics and Search Console so orphaned-but-ranking pages are included, and map each one to a real destination or an explicit 404 before a single page goes live. That way no old URL falls through to an empty template, because every one already has a defined fate. This is the same crawl-first discipline behind the [migration SEO checklist](/blog/wordpress-migration-seo-checklist/) and [mapping a site's structure first](/best-tool-to-scrape-website-structure-hierarchy/), and it is why soft 404s are entirely avoidable rather than an inevitable cost of a redesign.

## Common mistakes that recreate soft 404s

A few habits keep the coverage report full. Blanket-redirecting orphans to the homepage swaps one soft 404 for another. Fixing only the URLs Google has already flagged leaves the un-recrawled ones to surface later, so the report never fully clears. Redirecting to a thin or empty new page, rather than one with real content, just moves the emptiness. And treating the symptom in Search Console without adding the missing redirect rule means the same URLs return after the next crawl. Each mistake comes from chasing the report instead of fixing the underlying mapping, which is why the complete-inventory approach above is what actually makes them stay gone. The break also travels with others, like [analytics that stopped tracking](/google-analytics-stopped-tracking-after-website-redesign/), so audit those at the same time.

## Key points to remember

Soft 404s mean old URLs resolve to empty or thin pages that return a 200, so Google treats them as missing even though the server claims success, and that dishonest status makes them worse than real 404s. They appear because the redesign changed the URL structure without a complete redirect map. Find every one from the coverage report plus a crawl of your old URL set, then 301 each to the closest relevant page, return a true 404 or 410 for the genuinely retired, and never blanket-redirect to the homepage. Prevent them next time by inventorying every URL before launch. WPBuildAI crawls the old site and builds a complete redirect map before launch, so old URLs resolve cleanly and the soft 404s never appear; send your site URL for a fixed quote.

Not affiliated with Google, WordPress, or Lovable.