Cloudflare Pages returns 200 for pages that don't exist
Deploy a static site to Cloudflare Pages, then request a URL that doesn't exist:
curl -o /dev/null -w '%{http_code}' https://example.com/definitely-not-a-real-page
200
Not 404. 200 — and the body is your homepage.
I found this on a site I'd deployed the same day, while running a routine crawl audit. Every nonexistent path returned a healthy 200 with full homepage content.
Why it matters more than it looks
A wrong status code sounds cosmetic. It isn't, because search crawlers use status codes to decide what exists.
With a soft 404, a crawler that finds a stale or mistyped link gets a 200 and real content. So it indexes it. Every typo'd inbound link, every old URL, every path a crawler invents becomes another indexed page carrying your homepage's exact content.
The result is a site that looks, from the outside, like an unbounded pile of duplicate pages. That is one of the clearest low-quality signals there is — and for a new domain with no authority to spare, it's a self-inflicted wound.
It also breaks your own monitoring. Any uptime or link check that asserts on status codes will pass forever, including when everything is broken.
The fix
Add a 404.html at the root of your build output. That's it.
Pages looks for that file when a request matches nothing. Find it, and Pages serves it with a correct 404 status. Miss it, and you get the fallback behaviour above.
# after deploying
curl -o /dev/null -w '%{http_code}\n' https://example.com/nonexistent # want: 404
If you generate your site with a script, generate the 404 page too — don't hand-place a file that a clean rebuild will quietly drop. That's the version of this bug that comes back six months later.
The related trap on the same platform
While you're in there: _redirects on Pages matches paths, not hostnames. A rule copied from
another host's docs like this one:
https://www.example.com/* https://example.com/:splat 301!
is silently inert. It doesn't error, doesn't warn, doesn't redirect. If you're using it to fold
www into your apex domain, that consolidation isn't happening.
Hostname redirects need a platform-level Redirect Rule. Failing that, rel="canonical" on every
page is the working remedy — it tells search engines which hostname is authoritative even when both
serve content.
How to catch this class of bug
Both of these fail quietly and successfully. Nothing errors. The dashboard is green. You find them only by asserting on the thing you actually care about:
# these should be part of your deploy check, not a one-off
curl -o /dev/null -w 'missing page: %{http_code}\n' https://example.com/nonexistent
curl -o /dev/null -w 'www: %{http_code} -> %{redirect_url}\n' -L https://www.example.com/
A deploy that "succeeded" is not evidence that the site behaves correctly. Test the behaviour, not the deploy.
Related notes
- A TLS handshake failure usually means the service was never provisioned
TLS errors against a managed cloud endpoint are rarely certificate problems. Usually the subdomain was never provisioned for your account. - Sieve rules don't run on imported or fetched mail
Your Sieve filter is correct and still does nothing. Sieve fires on delivery — mail pulled from another provider bypasses it entirely. - Your launchd agent can't reach the LAN, and macOS won't tell you why
A LaunchAgent gets "All connection attempts failed" on your own network while the same code works in a shell. macOS enforces this per binary.