Start here
Before You Fix It: What This Check Means
Not-found status quality prevents soft-404 index pollution and user dead-end confusion. In plain terms, this checks whether missing URLs are clearly marked as missing instead of looking like valid pages. Scavo generates a guaranteed-unknown probe URL on your domain and sends a request to it.
Why this matters in practice: operational drift here often causes hard-to-debug regressions across environments.
How to use this result: treat this as directional evidence, not final truth. This result reflects what was observable at scan time and should be verified in your own production context. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Set server/router fallback to 404 for unknown public routes. Finally, re-scan the same URL to confirm the result improves.
Background sources
TL;DR: Your "not found" page returns HTTP 200 (OK) instead of 404, telling search engines that broken links are real pages.
When a deleted or broken URL returns HTTP 200, search engines index it as a real page — polluting your index with dead content and wasting crawl budget. This is called a "soft 404" and Google specifically warns against it. Your 404 page should return a proper 404 status code while still showing a helpful message to users.
What Scavo checks (plain English)
Scavo generates a guaranteed-unknown probe URL on your domain and sends a request to it.
Exact logic:
Pass: final status is 404 or 410.Warning: missing URL redirects to homepage and ends as200(soft-404 pattern).Fail: missing URL returns200directly.Fail: missing URL probe returns5xx.Warning: probe returns401/403or unresolved redirect status.Info: probe could not be completed from scanner environment (blocked/error).
Scavo stores probe URL, final URL, status code, redirects followed, and probe errors in details.
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for not_found_status, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
not_found_status - Category:
TECHNICAL
Why fixing this matters
Search engines and monitoring systems rely on HTTP status codes, not only page visuals. If unknown URLs return 200, crawl quality drops and broken routes are harder to detect.
Common reasons this check fails
- SPA or framework fallback serves app shell for all unknown paths.
- CDN/proxy rule rewrites unknown paths to
/. - Error template renders correctly but status code is not set.
- Legacy redirect rules catch every unmatched route.
If you are not technical
- Ask your developer to test a fake URL with
curl -Iand share output. - Confirm unknown URLs return 404 or 410, not 200.
- Keep branded error page if you want, but status must stay not-found.
- Re-run scan after fix.
Technical handoff message
Copy and share this with your developer.
Scavo flagged 404 response handling (not_found_status). Please ensure unknown URLs return HTTP 404 or 410 at the final response (after CDN/proxy/app routing), and remove fallback behavior that returns 200 for missing paths. Re-run the scan after deploy.If you are technical
- Set server/router fallback to 404 for unknown public routes.
- Remove blanket redirects from unknown paths to homepage.
- Verify final status at edge and origin.
- Keep custom 404 UI but preserve 404/410 status code.
Quick test
curl -I https://your-domain.example/__scavo_not_found_probe__/testExpected: HTTP/1.1 404 (or 410).
How to verify
- Run unknown-path tests on apex and
wwwhosts. - Confirm CDN and app produce same final not-found behavior.
- Test both desktop and mobile user-agent paths if routing differs.
- Re-run Scavo and confirm
Pass.
What this scan cannot confirm
- It does not validate every route pattern on your site.
- WAF/CDN geo rules may cause region-specific differences not seen in one run.
- It does not assess UX quality of the 404 page itself.
Owner checklist
- [ ] Assign ownership for not-found behavior (edge + app).
- [ ] Add route smoke tests for random unknown URLs.
- [ ] Include status-code assertions in deploy checks.
- [ ] Review redirect rules whenever routing changes.
FAQ
What's a soft-404 in plain terms?
A URL that should be “not found” but still returns 200 OK. Humans see an error-like page, crawlers see a valid page.
Should removed pages use 404 or 410?
Both can be valid. Use 410 when removal is explicit/permanent and you want to signal gone status clearly.
Why does redirecting unknown URLs to home cause warnings?
Because it hides genuine missing-page signals and can confuse crawl/index systems.
Can a firewall cause false positives here?
Yes. If probe requests are blocked (403, bot challenge), Scavo may return warning/info and you should verify directly from origin/ops tooling.
Sources
- Google Search Central: HTTP status codes and network errors
- RFC 9110: HTTP Semantics
- MDN: 404 Not Found
- MDN: 410 Gone
Need help debugging edge vs origin behavior for soft-404 issues? Send support your CDN + app stack details.
