Writing

404 Not Found

Published 20 September 2026

What does 404 mean? Literally: the server understood your request and has nothing at that path. But an HTTP 404 is the least trustworthy code in the whole set: it is routinely returned for things that do exist, and the page you are reading may be a 404 that never said so.

Start with what it proves

The network worked. A 404 is a reply, so the name resolved, a connection opened, TLS negotiated, your request arrived and an answer came back. Whatever is wrong happened at the far end, after your request was safely delivered.

Unlike a 502 or a 504, which are always their problem: a 404 is genuinely ambiguous. Either your path is wrong or their page is gone, and the code alone cannot tell you which. That is the whole reason this one needs a minute's work.

The thirty-second version

Three ways a 404 misleads

1. It is hiding a 403

Returning 404 for something you are not allowed to see is a deliberate, widespread security practice. A 403 confirms the resource exists; a 404 reveals nothing. GitHub does this for private repositories, and so do many object stores and admin paths.

So not found can mean not yours. The tell is that it resolves for someone with access and 404s for everyone else: if a colleague can open the link and you cannot, stop looking for a broken URL.

2. It came from the edge, not the origin

A CDN or reverse proxy can answer 404 on its own, without ever asking the server behind it. The page may exist on the origin and simply not be known to the edge: a cached negative, a routing rule that does not match, or a deploy that reached one and not the other.

The response headers give it away. A cf-ray, a via, or an x-cache header means something sat in the middle and may have answered for itself. That is a different problem with a different fix, and it is invisible if you only read the number.

3. It is a soft 404: the page says "not found" and returns 200

The worst of the three, because every automated check calls it healthy. The server sends 200 OK with a body that reads "page not found". Humans see an error; monitoring sees success; uptime stays green while the content is gone.

A soft 404 also confuses search engines, which have to guess from the text that the page is really missing, and they index the error page in the meantime. If a site has quietly lost a section and nothing alerted, this is usually why.

You cannot see it in a browser: the page looks like an error either way. The only way to know is to read the status code.

Read the actual status and headers. The HTTP status checker fetches the URL and shows the real code, the full redirect chain and the response headers, so a soft 404 shows up as the 200 it really is, and a cf-ray tells you the edge answered rather than the origin.

Check a URL

If you own the site

When it is not really a 404 at all

If the page fails to load and you are assuming 404 from a browser error page, check the code before going further. A browser shows something similar for several conditions that are not 404s at all, and they point in completely different directions:

What you seeWhat it actually is
"Site cannot be reached"No status code: DNS, refused, or timeout. See no route to host.
A certificate warningTLS failed before HTTP began: which is you or the site.
A "not found" pageCould be 404, 410, or a soft 404 returning 200. Only the code distinguishes them.
Nothing, then a long pauseOften a 504, or an MTU problem.