Google describes a soft 404 as a missing URL that returns a non-404 response, often 200 with homepage or generic error content. On S3, CloudFront, and React sites, a custom error response can rewrite every missing path to index.html while keeping a 200 status and homepage canonical.
Use this for WordPress headless sites, React apps, S3 and CloudFront hosting, custom prerenderers, catch-all routers, and Search Console reports that show Soft 404 or Duplicate without user-selected canonical.
Quick answer
Test several random missing paths at the CDN and origin. A truly missing document should return 404 or 410 with a useful error page and no homepage canonical. Redirect only when a clear replacement exists, and keep missing URLs out of the sitemap and internal links.
What to check first
- Generate random missing paths under the homepage, blog, service, asset, API, and legacy .html namespaces so cached known errors do not hide the rule.
- Capture status, final URL, cache status, content type, title, canonical, robots meta, body fingerprint, content length, and CloudFront request ID for each path.
- Request the S3 or application origin directly where safe and compare its response to CloudFront custom error and function behavior.
- Check React routing, prerender lookup, Lambda or edge rewrite logic, S3 error documents, and CloudFront custom error response-code settings.
- Return 404 or 410 for missing content, 301 only for a real replacement, then remove bad URLs from sitemap and internal links and retest Search Console samples.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Probe random namespaces | Generate random missing paths under the homepage, blog, service, asset, API, and legacy .html namespaces so cached known errors do not hide the rule. | Random missing document paths return 404 or 410 at the public CDN. |
| Compare edge and origin | Capture status, final URL, cache status, content type, title, canonical, robots meta, body fingerprint, content length, and CloudFront request ID for each path. | The error page does not declare the homepage or another unrelated URL as canonical. |
| Find the fallback owner | Request the S3 or application origin directly where safe and compare its response to CloudFront custom error and function behavior. | Published clean URLs still return 200 with their own title, canonical, schema, and rendered content. |
| Return the correct status | Check React routing, prerender lookup, Lambda or edge rewrite logic, S3 error documents, and CloudFront custom error response-code settings. | Sitemap and internal links contain no known missing or duplicate path variants. |
Why this usually happens
- Single-page apps often rewrite unknown paths to index.html so client routing can decide what to display.
- CloudFront can change an origin 403 or 404 into a 200 custom error response.
- A prerender miss can fall through to the homepage shell and inherit its canonical tag.
- Sitemaps or internal links can keep sending crawlers to a path that the application never published.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
for path in missing-page-8472 blog/missing-3811 services/missing-2290; do
curl -sS -D "/tmp/${path//\//_}.headers" -o "/tmp/${path//\//_}.html" "https://example.com/$path"
done
grep -Eio '<title>[^<]*|rel="canonical"[^>]*|name="robots"[^>]*' /tmp/missing*.html
# Expected missing document status: 404 or 410
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Probe random namespaces
- Compare edge and origin
- Find the fallback owner
- Return the correct status
- Clean links and recheck
Decision rule
Use 301 only when the missing URL has a specific replacement that satisfies the same intent. Otherwise return 404 or 410 while still showing a useful navigation page.
What to tell the client or owner
Share the sampled paths, public and origin responses, status and cache headers, body fingerprints, canonical and robots tags, CloudFront error settings, rewrite or function code, corrected behavior, sitemap check, and Search Console samples.
Production verification checklist
- Random missing document paths return 404 or 410 at the public CDN.
- The error page does not declare the homepage or another unrelated URL as canonical.
- Published clean URLs still return 200 with their own title, canonical, schema, and rendered content.
- Sitemap and internal links contain no known missing or duplicate path variants.
Mistakes to avoid
- Do not redirect every missing URL to the homepage.
- Do not fix only the visual message while leaving HTTP 200.
- Do not apply an HTML fallback to missing images, JavaScript, CSS, or API routes.
- Do not remove a legitimate canonical from published pages while correcting the error template.
Questions teams ask during testing
Will normal 404 responses hurt SEO?
Google says missing URLs should return 404 or 410. The problem is not an honest missing response, but wasting crawl time or confusing indexing with 200 homepage content on nonexistent paths.
Can a custom 404 page still be helpful?
Yes. The server can return 404 while the page offers search, navigation, and relevant links. The HTTP status and user experience are separate decisions.
When HandL WP should help
HandL WP can trace soft 404s through WordPress, React routing, prerendering, S3, CloudFront, and canonical generation, then verify that valid pages still render correctly.
If this is active on a production site, fix soft 404 and canonical responses.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references