404 Page Returns Wrong HTTP Status Code

Start here

Before you fix it: what this check means

Scavo requests a made-up address on your site and checks whether the server marks it as missing. A useful error page should also return a missing-page status, normally 404 or 410. Scavo generates a guaranteed-unknown probe URL on your domain and sends a request to it.

Why this matters in practice: checking the reported setting helps you keep the site working as intended.

Use this as evidence, not a final verdict. This result covers what the scan could observe at that time, not every page or visitor situation. Check the live site first. Open the published page and ask your developer to inspect the reported request or setting Make one controlled change. Set server/router fallback to 404 for unknown public routes. Re-scan the same URL and compare the finding; check the feature yourself as well.

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 (quick version)

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 as 200 (soft-404 pattern).
Fail: missing URL returns 200 directly.
Fail: missing URL probe returns 5xx.
Warning: probe returns 401/403 or 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 -I and 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.

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__/test

Expected: HTTP/1.1 404 (or 410).

How to verify

Run unknown-path tests on apex and www hosts.
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

Need help debugging edge vs origin behavior for soft-404 issues? Send support your CDN + app stack details.

404 Page Returns Wrong HTTP Status Code