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
- Did it ever work? If you followed a link that used to resolve, they moved or deleted something. That is their change, not your network and not your browser.
- Does the parent path work? If
/docs/guide404s but/docsloads, the section exists and the page within it does not. If/docsalso 404s, suspect the whole area moved. - Check the case. Most web servers treat paths as case-sensitive even on case-insensitive filesystems. A capital letter is a genuinely common cause.
- Try it logged out, or from another network. If it works for someone else, it is not missing: see below.
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.
If you own the site
- Return a real 404, not a 200. The status code is the machine-readable part; the pretty page is for humans. Getting this wrong is the single most common mistake in custom error pages.
- Use 410 when something is deliberately gone. A 404 says "not here, maybe later". A 410 says "removed on purpose", and crawlers drop it faster and stop asking.
- Redirect only to something equivalent. Sending every missing URL to the homepage is worse than a 404: the visitor loses the signal that the page is gone, and search engines treat a mass redirect to an unrelated page as a soft 404 anyway.
- Watch the pattern, not the count. A steady trickle of 404s is normal internet noise. A sudden cluster on one path prefix is a deploy that dropped a directory.
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 see | What it actually is |
|---|---|
| "Site cannot be reached" | No status code: DNS, refused, or timeout. See no route to host. |
| A certificate warning | TLS failed before HTTP began: which is you or the site. |
| A "not found" page | Could be 404, 410, or a soft 404 returning 200. Only the code distinguishes them. |
| Nothing, then a long pause | Often a 504, or an MTU problem. |