Introduction

A real 404 Not Found is an HTTP response with status code 404, not just a webpage that happens to say "not found." The only reliable way to tell is to inspect the actual HTTP response status. Browsers, proxies, and frameworks can display friendly error pages that obscure what the server really returned, so you should check the response directly.

Check the HTTP Status Code

The most direct test is to look at the response headers.

With curl:

curl -I https://example.com/some/path

If the result includes:

HTTP/1.1 404 Not Found

then you are truly getting a 404.

If the page visually looks like a 404 but the status is 200 OK, that is not a real 404. That is a soft 404 or a custom application response.

Use Browser Developer Tools

In a browser, open the Network panel in developer tools, reload the page, and inspect the request.

What to look for:

• the request URL
• the response status code
• whether there was a redirect first
• the final response body

This matters because a page can go through several steps:

• '301 or 302 redirect'
• final 404
• or a 200 response containing a "page not found" template

Only the Network panel shows the actual chain clearly.

JavaScript and API Calls

If the problem is in frontend code or an API call, log the status programmatically.

1fetch("/api/missing-resource")
2  .then(response => {
3    console.log(response.status);
4    console.log(response.ok);
5  })
6  .catch(console.error);

A 404 will show response.status === 404 and response.ok === false.

If you are using Axios:

1import axios from "axios";
2
3axios.get("/api/missing-resource")
4  .then(response => console.log(response.status))
5  .catch(error => {
6    if (error.response) {
7      console.log(error.response.status);
8    }
9  });

This is often faster than guessing from UI behavior.

Server Logs Help Confirm It

If you control the server, check the access logs. A real 404 is usually visible there with the requested path and the returned status code.

For example, an access log entry might show a pattern like:

GET /missing-page 404

That confirms the server itself generated the 404 rather than a frontend route or proxy layer faking the message.

Distinguish Real 404s From Related Cases

Several cases can look similar but are different:

• '403 Forbidden: the resource exists, but access is denied'
• '401 Unauthorized: authentication is required or invalid'
• '410 Gone: the resource used to exist and was intentionally removed'
• soft 404: the page says "not found" but still returns 200

This distinction matters for debugging, monitoring, SEO, and client behavior.

For example, search engines treat a real 404 differently from a soft 404, and application retries should behave differently for 404 versus 500.

Redirects Can Mislead You

Sometimes the URL you requested is not the URL that actually returned the final response. A reverse proxy, application router, or CDN may redirect the request before the final status appears.

That is why curl -I -L can be useful:

curl -I -L https://example.com/old-url

This follows redirects and shows the chain that leads to the final response.

Common Pitfalls

The most common mistake is relying on page text alone. A pretty "not found" page can still return 200 OK.

Another mistake is checking only the browser address bar and not the Network panel. Redirects and client-side routing can hide the true response path.

Developers also often assume every missing API resource produces a 404, but some frameworks return 200, 204, or custom error envelopes depending on implementation.

Finally, do not ignore proxies and CDNs. The component returning the 404 may not be the application server you first suspect.

Summary

• A real 404 is an HTTP status code, not just a message on the page.
• Use curl -I, browser developer tools, or application logs to verify the status.
• Distinguish real 404s from soft 404s and nearby codes such as 403 or 410.
• Inspect redirects because the final response may come from a different URL or layer.
• Trust the response metadata, not the page design.