HTTP 404 Not Found: RFC 9110 Definition, Causes and Fixes

In short. 404 means the server received the request and found nothing at that path. The server itself is healthy, which is why restarting it changes nothing. The distinction that matters is a soft 404 — a page saying “not found” while returning 200 — because search engines index that as real content.

The 404 Not Found error is one of the most common HTTP status codes site owners and visitors encounter. It means the server received the request but could not find the requested resource. Despite appearing simple, 404 can stem from many causes: a URL typo, broken rewrite rules, CDN cache issues, or SPA routing misconfiguration.

This guide covers what 404 really means, 7 common causes, how to diagnose it using DevTools and server logs, and proven solutions for nginx, Apache, Next.js, WordPress, and React applications in 2026.

What HTTP 404 Not Found Means

The normative definition is in RFC 9110 §15.5.5, and it is shorter than most people expect:

The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.

A 404 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

Four consequences follow from that wording, and each one catches people out:

• It says «a current representation», not «the page». The resource may well exist as a concept — the server simply has nothing to serve for it right now. That is why a 404 on an API endpoint does not prove the record was deleted.
• «Or is not willing to disclose that one exists» is deliberate. The spec explicitly blesses answering 404 for a resource that does exist but that this client has no business knowing about. Returning 403 there would confirm the resource is real; 404 does not. This is why admin paths and private objects often answer 404.
• It carries no information about permanence. A 404 tells a crawler nothing about whether to come back. If you know the resource is gone for good, 410 Gone is the code the spec prefers — search engines drop 410 URLs faster than 404s.
• It is cacheable by default. This is the practical trap: unless you send explicit cache headers, a 404 may be stored and replayed by browsers, CDNs and proxies. It is the usual reason a page still 404s minutes after you fixed it — the fix is live, the cached 404 is not gone. Send Cache-Control: no-store on 404s you expect to fix, and purge the CDN after the fix.

Do not confuse 404 with the codes around it — the difference changes how crawlers and clients behave:

Confusion between these hurts SEO — see our full HTTP status codes reference. A 404 is a client error (4xx class), but the root cause is usually server-side configuration, which is what the rest of this guide is about.

7 Common Causes of 404 Errors

1. URL typo. Most frequent cause — user or external link has an incorrect path.
2. Deleted or moved page. Content removed but no redirect configured.
3. Broken rewrite rules. Misconfigured try_files in nginx or .htaccess in Apache.
4. File permission problems. Web server cannot read the file due to wrong chmod/chown.
5. SPA routing errors. React/Vue/Angular apps without index.html fallback return 404 on direct navigation.
6. Stale CDN cache. CDN serves old 404 after you deploy the new page.
7. DNS or upstream misrouting. Request hits the wrong origin server.

Diagnosing 404 with DevTools and Logs

Open DevTools (F12 → Network tab), reproduce the error, and inspect the full request: URL, method, headers. The Referer header reveals where the broken link originated.

For fast header inspection, use the Enterno.io HTTP Header Checker — paste a URL and get the full response headers plus redirect chain.

From the command line:

curl -I https://example.com/broken-page
curl -v https://example.com/broken-page 2>&1 | head -50

Check web server logs:

# nginx
tail -f /var/log/nginx/access.log | grep " 404 "
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/access.log | grep " 404 "
tail -f /var/log/apache2/error.log

Solutions by Platform

nginx: try_files and custom error page

server {
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    error_page 404 /404.html;
    location = /404.html {
        internal;
    }
}

Apache (.htaccess)

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [L]
ErrorDocument 404 /404.html

WordPress

Go to Settings → Permalinks and click Save — this rewrites .htaccess. If that fails, check file permissions: chmod 644 .htaccess.

React / Vue / Next.js SPA

For static hosting, set up index.html fallback:

# nginx
location / {
    try_files $uri $uri/ /index.html;
}

301 redirects for deleted pages

Return 301 instead of 404 when content moved — preserves SEO equity:

location = /old-url {
    return 301 https://example.com/new-url;
}

Soft 404 Errors and Google Search Console

A soft 404 is a trickier problem: the page shows "not found" content to the visitor, but the server still returns an HTTP 200 OK status instead of a real 404. Google Search Console flags these under Pages → Not indexed → Soft 404. They waste crawl budget and can keep dead URLs in the index.

Common causes of a soft 404:

• An empty or "no results" page returned with status 200 (search pages, filtered category pages);
• A JavaScript app that renders a "not found" view client-side without setting the status code;
• A custom error page served through a 200 redirect instead of a real 404 response;
• Thin or near-empty pages that Google decides are effectively "not found".

The fix follows one principle: return the correct status code. A genuinely missing page must respond with 404 Not Found (or 410 Gone if removed permanently); a real page must return 200 with substantial content. For single-page apps, add server-side or edge logic that sends a 404 for unknown routes. You can confirm the actual status your server returns — separate from what the browser shows — with an HTTP status code checker, and read the exact wording of the code on the 404 Not Found reference (RFC 9110).

Preventing 404 Errors

• Scan regularly for broken links — at minimum monthly.
• Monitor key pages via Enterno.io Uptime Monitoring — get alerts if a page suddenly returns 404.
• Use 301 redirects for any URL structure changes.
• Watch Google Search Console — the Coverage report lists every 404 Googlebot hit.
• Build an informative 404 page with site search, popular links, and a contact form.

Frequently Asked Questions

Q: Does 404 hurt SEO?
A: Isolated 404s are fine. Mass 404s on previously indexed pages reduce crawl budget and rankings. Google recommends 410 for intentionally removed content.

Q: Should I use 404 or 410?
A: Use 410 Gone when content is permanently deleted. Use 404 for unknown or temporary cases. Googlebot deindexes 410 faster.

Q: Can I detect 404s automatically?
A: Yes — use Enterno.io monitoring with expected_code=200. Any deviation triggers Email/Telegram/Slack alerts.

Q: Why does deploying a new page return 404?
A: Three usual suspects: (1) CDN cache — purge it, (2) PHP OPcache — restart php-fpm, (3) rewrite rules not reloaded — reload nginx/apache.

Conclusion

A 404 is not a verdict, it is a signal. In 90% of cases it is fixed within 5 minutes after proper diagnosis via DevTools, logs, and the HTTP Header Checker. Key principles: set up 301 redirects when URLs change, monitor for broken links, craft a useful 404 page, and enable automatic monitoring of critical pages.