Google Says Your Real Page Is a Soft 404—How to Fix It
Search Console can label a URL “Soft 404” even when the page opens in your browser and returns a successful response. That feels contradictory, but the label describes a mismatch: the server says the request succeeded while the rendered page looks missing, empty, broken, or too unhelpful to represent a real destination.
The fix is not to force every URL to return 200 or redirect every missing page to the homepage. First decide what the URL is supposed to be. Then make the status code, rendered content, canonical signals, internal links, and sitemap tell the same story.
What a soft 404 actually means
A true 404 returns an HTTP 404 status because the requested resource does not exist. A soft 404 usually returns 200 while displaying a “not found” message, an empty template, a failed product, a blank dynamic page, or content that Google interprets as an error.
Google’s crawl-error documentation also lists missing server includes, database failures, empty search results, and unloaded JavaScript as possible causes. Google excludes detected soft-404 pages from Search, so repeatedly requesting indexing will not repair the underlying mismatch.
Start with one exact URL, not the whole report
Choose a representative URL from Search Console and record:
the indexed or submitted URL;
its intended purpose;
the final URL after redirects;
the HTTP status returned to a clean request;
what a normal browser renders;
what URL Inspection renders for Google;
the canonical URL;
whether it appears in the sitemap and internal links.
Test logged out and in a private window. A page may look complete to an administrator while a public visitor receives an empty component, access message, expired item, or personalization fallback.
Do not diagnose from the screenshot alone. Check the response in browser developer tools or with an HTTP-status checker, then compare it with Search Console’s live test and rendered HTML. The visible page and the server response are separate pieces of evidence.
Use this three-way decision before changing anything
1. The page should exist and rank
If the URL represents a valid product, service, article, location, or category, restore enough main content for the page to satisfy its purpose. Check whether critical text depends on JavaScript that failed for Googlebot, a CMS item is unpublished, a database query returns nothing, or resources are blocked.
A working header and footer do not make an otherwise empty page useful. The main content should identify the subject, answer the expected intent, and remain available to anonymous visitors. Verify the page returns 200 only after it renders the intended content.
2. The page moved to a genuine replacement
If the old URL has a clear equivalent, use a permanent server-side 301 or 308 redirect to that specific destination. Google describes permanent redirects as a signal that the target should become canonical. Avoid redirecting every removed product, city page, or article to the homepage; an unrelated destination does not solve the user’s request and can itself be treated like a soft 404.
Update internal links and the sitemap to point directly to the replacement. If this followed a redesign or migration, Webcurry’s redesign ranking-recovery workflow covers URL mapping and redirect verification in more detail.
3. The page is gone and has no replacement
Return a real 404 or 410 status. A useful custom error page can keep the normal navigation, explain what happened, and link to popular sections, but its server response must still say the resource is missing. This is cleaner than preserving a dead URL as a 200 page with an apology.
Remove the dead URL from XML sitemaps and stop linking to it internally. A 404 is not automatically an SEO failure; it is the correct response for content that no longer exists and has no equivalent.
Why valid pages get misclassified
Thin or template-only content
A location, service, tag, or product page may contain the site shell but almost no unique main content. Boilerplate across hundreds of URLs can make an individual page resemble an empty placeholder. Strengthen only pages with a real purpose; do not pad every generated page with generic text.
JavaScript or resource failures
A browser may reuse cached files while Google’s renderer encounters a failed API call, blocked script, timeout, or missing bundle. Inspect the rendered page and resource-loading errors. If visitors see different versions after a deployment, use Webcurry’s cache-layer diagnostic before assuming the content itself is wrong.
Empty search, filter, and category pages
Internal search and faceted navigation can produce valid-looking 200 URLs with zero results. Decide whether the state is a temporary interface condition or a crawlable URL. Webcurry’s guides to website search returning no results and empty product filters after migration help separate bad catalog data from intentional empty states.
Expired products, jobs, events, or listings
Do not leave an empty detail template at the old URL. If the item may return, keep a useful page explaining availability and alternatives. If it permanently moved, redirect to the closest true replacement. If it is gone without an equivalent, return 404 or 410.
Canonical and redirect conflicts
A live URL may self-canonicalize while redirecting elsewhere, appear in the sitemap under another hostname, or receive internal links through tracking variants. Align the final response, canonical, internal links, and sitemap. If Google selects a different preferred URL, follow Webcurry’s canonical troubleshooting guide.
Platform-specific checks
Wix
For a normal page, confirm it is published, publicly accessible, and populated on the live site. For CMS dynamic pages, check that the connected collection contains the item, the slug field has a value, collection permissions allow public viewing, and the dataset is connected correctly. Wix’s dynamic-page troubleshooting guidance specifically recommends checking publication, collection items, slug values, page connections, and redirects after slug changes.
When a URL genuinely moved, use Wix’s URL Redirect Manager and test the old path. Keep the current URL in the sitemap and remove obsolete internal links. Webcurry’s Wix SEO checklist is useful for the broader indexability review.
WordPress
Check whether the page template, custom post type, taxonomy archive, page builder, or plugin returns 200 for an empty query. Clear caches after fixing the template. For deleted content, make sure the theme’s custom 404 template still sends a real 404 header. Create one-to-one redirects for moved pages through the server or a trusted redirect tool; avoid a catch-all rule to the homepage.
Shopify
Inspect product availability, market visibility, theme templates, app-generated landing pages, collection filters, and discontinued-product handling. A product hidden from every sales channel can leave links pointing to an unavailable destination. Redirect a permanently replaced product to its true successor, retain a genuinely useful out-of-stock page when the item will return, or allow a real 404 when there is no substitute.
Verify the repair before clicking “Validate fix”
Open the exact URL in a clean session.
Confirm the intended final URL and HTTP status.
Inspect the rendered main content, not only the page source.
Check the canonical and robots directives.
Verify internal links and sitemap membership match the decision.
Run Search Console’s live URL test.
Request indexing only for a page that should exist and be indexed.
Use “Validate fix” after the same pattern is corrected across the affected group.
If Google can crawl the restored content but still declines to index it, the problem has moved beyond soft-404 handling. Continue with Why Google Crawls Your Pages but Refuses to Index Them to evaluate duplication, value, internal linking, rendering, and competing signals.
Make the response match the page’s real purpose
A soft 404 is rarely fixed by one SEO field. It is resolved when the URL behaves honestly: a valuable page returns 200 with complete content, a moved page redirects to its true replacement, and a removed page returns a real not-found status.
Work from a representative URL, correct the template or routing rule behind it, and retest the rendered result. If status codes, CMS output, redirects, and Search Console still disagree, ask Webcurry for a technical SEO review focused on the exact affected URL pattern.
Comments