404 Not Found 4xx

What does 404 mean?

A 404 Not Found response means the server understood the request but could not find anything matching the requested URL. It's one of the most recognizable error codes on the web — most people have seen a "404 Page Not Found" message even if they've never written a line of code.

A 404 doesn't tell the client why the resource is missing. It might have never existed, it might have been deleted, or the URL might simply be wrong. This ambiguity is intentional — the server isn't required to explain itself, which is sometimes useful for privacy and security (more on that below).

How a 404 behaves

A few technical details that are easy to overlook:

• It can carry a body. Servers almost always send an HTML page (or JSON object for APIs) along with a 404, giving the client something useful to display or parse.
• It's cacheable, but rarely cached by default. The HTTP spec allows 404 responses to be cached, but most servers don't send caching headers for them, so browsers and CDNs typically treat each 404 as fresh.
• It's safe to retry. A 404 doesn't change anything on the server, so retrying the same request is harmless — though it will almost always return the same result unless the resource gets created later.
• It applies to the URL, not the action. A 404 means this specific path doesn't exist — it says nothing about whether other paths on the same server work fine.

Common causes

If you're building the API or website:

• The route was removed or renamed without a redirect being set up
• A database record the route depends on (e.g., a user profile, blog post, or product) was deleted
• A typo in your route definitions or controller bindings
• Case sensitivity — /About and /about may resolve differently depending on your server configuration

If you're calling an API:

• You're hitting the wrong base URL or API version (e.g., /v1/ vs /v2/)
• The resource ID in the URL doesn't exist (e.g., requesting /users/9999 when user 9999 was never created or was deleted)
• An authentication issue is being masked as a 404 — some APIs deliberately return 404 instead of 403 for resources you're not allowed to see (see the security note below)

If you're a website visitor:

• The page was moved or deleted by the site owner
• You followed an old bookmark or a link from a site that hasn't updated its links
• You mistyped the URL directly into the address bar

How to fix it

As an API/website builder:

• Set up redirects (301/302) from old URLs to their new locations whenever you restructure routes
• Make sure your routing layer returns a proper 404 (not a 200 with an error message in the body — see the SEO section below)
• For APIs, return a consistent JSON error shape on 404s (e.g., { "error": "Resource not found" }) so clients can handle it programmatically
• Log 404s in production — a spike in 404s on a specific path often means a broken link somewhere, either internal or from an external referrer

As an API consumer:

• Double-check the exact URL, including trailing slashes, casing, and the API version segment
• Confirm the resource ID actually exists by checking a "list" endpoint first
• Read the response body — many APIs include a helpful message even on a 404

As a website visitor:

• Check the URL for typos
• Try navigating from the site's homepage instead of using the broken link
• Use the Wayback Machine if you need to find the page's old content

404 vs related codes

Real-world examples

Most major APIs follow the same convention. GitHub's API returns a 404 for repositories that don't exist or that you don't have permission to see — deliberately not distinguishing between "doesn't exist" and "exists but private," so you can't probe for the existence of private repos. Stripe's API similarly returns a 404 for objects (charges, customers, etc.) that don't exist under the authenticated account, even if the object ID exists under a different account.

SEO implications

404s are a normal, healthy part of the web — search engines expect some pages to disappear over time, and a proper 404 simply tells them to drop that URL from the index eventually.

The real problem is soft 404s — pages that show "not found" content to a human but return a 200 OK status to the server. Search engines may keep these pages indexed (since the status code says everything's fine) while showing users a broken page, which hurts both SEO and user experience. Always make sure your custom error pages return an actual 404 status, not 200.

A well-designed 404 page (with navigation, search, and links to popular content) can also reduce bounce rate when visitors do land on a dead link.

FAQ

Is 404 a client error or a server error?

It's classified as a client error (4xx), meaning the request itself was understood, but the specific resource isn't available — as opposed to 5xx errors, which indicate something went wrong on the server's end.

Does a 404 page hurt my site's SEO?

Not by itself. Search engines treat 404s as a normal signal that a page no longer exists. What hurts SEO is a soft 404 — returning a 200 status code on a page that actually shows error content.

Should I redirect all my 404s to the homepage?

Generally no. Blanket-redirecting every missing URL to the homepage can create a poor user experience and may be interpreted by search engines as a soft 404 if done with a 200/301 instead of an actual 404. It's better to show a helpful custom 404 page, and only redirect specific URLs you know have moved.

Why do some APIs return 404 instead of 403 for resources I don't have access to?

This is a deliberate security choice. Returning 404 instead of 403 prevents an attacker from learning whether a resource exists at all — a technique sometimes called "404'ing" private resources.

Can a 404 response be cached?

Yes, technically — the HTTP spec permits caching 404 responses. In practice, most servers don't add cache headers to error responses, so browsers and CDNs treat them as non-cacheable by default.

Fun fact

There's a popular urban legend that "404" refers to a room number at CERN where the first web server lived. It's not true — the number is simply part of the systematic numbering scheme HTTP uses for client errors (the 4xx range), but the myth has stuck around because, well, it's a better story.