Soft 404 Errors: What They Mean and How to Fix Them
A soft 404 occurs when a URL returns a success response but the rendered page tells users and Google that useful content is missing. Match the fix to the outcome: return 404/410 for gone content, 301 for a true replacement, or restore a real page and keep 200.
What is a soft 404, and how is it different from a hard 404?
A soft 404 is a mismatch between a URL’s response and its user-visible outcome. The classic case displays “not found” or an error-like page while returning HTTP 200 OK. A hard 404 returns the meaningful HTTP 404 status, whether its design is plain or polished.
The phrase does not mean “a nice-looking 404 page.” It describes a success code attached to missing-page behavior. Google also recognizes blank, near-blank, or failed-content pages as possible soft 404s in its crawl-error guidance.
A helpful custom missing-page design remains a correct hard 404 when the server returns 404.
How does Google decide a page is a soft 404?
Google evaluates both the response code and page content, so a 200 alone does not establish that a real page exists. Error messages, empty main content, broken includes, failed database output, empty internal-search results, or missing JavaScript can make a nominally successful URL look functionally missing.
Google excludes detected soft 404 pages from Search. Search Console groups examples in the Page Indexing report, but the label is a classification, not one root cause.
Not every excluded URL needs fixing. A retired product with no replacement belongs outside the index; its problem is returning 200 instead of an accurate gone status.
How should you test a suspected soft 404?
Test the final HTTP status and the fully rendered page together, because either half can conceal the failure. A source response may say 200 while the visible page says “product unavailable,” or an apparently valid template may render without its main product data after a script, API, or resource fails.
Use this sequence:
- Open the final URL anonymously and follow redirects.
- Check its HTTP response, including any app proxy.
- Compare initial HTML with rendered content and error text.
- Inspect Google’s tested-page HTML and screenshot.
Google’s URL Inspection guide says a live test shows current fetch and render eligibility, not future indexing. Test mobile, market, or language paths using different templates.
Use meaningful status codes. Google’s HTTP and network error documentation distinguishes unavailable 4xx content from temporary 5xx failure; errors should not masquerade as 200.
Which Shopify pages commonly create soft 404 symptoms?
Shopify soft 404s usually arise when commerce state and template output disagree. A product, collection, or app-backed route may keep returning a successful shell after its useful data disappears. Diagnose the actual storefront response rather than assuming Shopify’s baseline SEO behavior controls every theme or app route.
Common cases include:
- Deleted or unpublished products: An unavailable message returns
200. - Empty collections or search: A template has no meaningful results.
- Sold-out products: Useful specifications, restock context, and alternatives disappear.
- Theme or app proxies: Removed integrations leave shells or fallbacks.
- Missing JavaScript or resources: Product information never renders.
- Database or API failures: Core data is blank or error-like.
Shopify provides canonical, sitemap, robots, and SSL foundations, but its SEO overview does not protect custom output from theme, app, or code failures. Reproduce the problem without an admin session.
Which fix matches the user outcome?
Choose the response from the shopper’s real outcome, not from a desire to remove a Search Console warning. Truly gone content needs 404 or 410; a page with one clear replacement needs 301; a real page needs substantive content restored while keeping 200; a temporary outage needs repair and an honest server-error response meanwhile.
| User outcome | Correct action | Avoid |
|---|---|---|
| Gone with no replacement | Return 404 or 410 | Empty template with 200 |
| Permanently moved | 301 to the closest equivalent | Redirecting to an unrelated page |
| Page still exists | Restore useful content and keep 200 | Hiding the failure with an error message |
| Temporary system outage | Fix the dependency; use meaningful 5xx while unavailable | Permanent redirect or fake 200 |
For a real product, restore identity, specifications, availability, and relevant alternatives. For a failed render, repair the resource or data call and verify both outputs. Google’s soft 404 troubleshooting follows this outcome-based split.
Accurate responses keep URL inventory cleaner. Google’s crawl-budget guidance says soft 404s can consume crawling; current sitemaps, direct redirects, and accurate codes reduce wasted paths. Small stores should fix the mismatch without overdiagnosing crawl budget.
How should you handle custom 404 pages and redirects?
Keep the custom 404 page helpful while preserving a true 404 response. Give shoppers concise language, navigation, search, and links to useful collections, but do not return 200 simply because the page has branded design. User experience and protocol accuracy can coexist.
Use a 301 only for a clear, closest equivalent. Shopify supports genuinely moved content through its URL redirect tools, but a discontinued product belongs with its replacement, not automatically the homepage.
Never redirect every deleted product to the homepage. That erases intent and creates another mismatch. With no equivalent, a useful 404 is honest.
How should you clean discovery signals and validate?
After fixing the response, remove stale signals that keep sending shoppers and crawlers to the wrong outcome. Update internal links, navigation, sitemap membership, feeds, and redirect chains, then validate representative URLs in Search Console. A technically correct endpoint is only half-fixed if the store still promotes the old path.
Work through four checks:
- Replace links to deleted URLs using Shopify’s navigation guidance.
- Confirm preferred URLs in Shopify’s updated root sitemap.
- Retest the response and rendered mobile or market variants.
- Validate when grouped examples share the repaired cause.
Sitemaps aid discovery but cannot guarantee indexing. Validation requires recrawling and can take time, according to the Page Indexing report guide. Watch for new examples from recurring theme or app failures.
What can StoreCited verify?
StoreCited can flag visible readiness symptoms such as thin, blank, or error-like content, broken internal signals, and indexability gaps in pages it can fetch. It does not access Search Console by default, determine Google’s private classification, track every render dependency, or guarantee indexing or citation.
Use StoreCited for readiness gaps, then verify HTTP and rendered output yourself. Decisive evidence combines accurate status, matching content, clean discovery signals, and current Search Console inspection.
Get the answer for your specific store