404 Not Found Error: What It Means and How to Fix It

DIRECT ANSWER

HTTP 404 Not Found means the server was reached, but it could not find a current representation of the requested resource. Check the URL for spelling, case and outdated paths first. If you manage the site, inspect application routes, rewrite rules, deployed files, proxy configuration and internal links.

Key takeaways

A 404 confirms that an HTTP server returned a response; it is different from DNS, TLS and connection failures.
Mistyped, outdated, deleted or moved URLs are common causes, but valid paths can also fail because of routing, rewrites or deployments.
Compare the failing path with a known-working path and inspect server or application logs to narrow the cause.
Redirect permanently moved content to the closest relevant replacement—not automatically to the homepage.
A custom Not Found page should continue to return HTTP status 404, not 200.

Updated 2026-09-24 · Editorial review pending HTTP & Server Errors

Site Administrator

What this error means & how to recognize it

A page displays 404, Not Found or a custom missing-page message while other pages on the same site load.
An API request returns a 404 even though the hostname and server are reachable.
A previously working URL starts returning 404 after a deployment, migration, permalink change or application update.
Search results, bookmarks or internal links lead to content that is no longer available.
Multiple unrelated paths fail after a web-server, reverse-proxy or rewrite configuration change.

Root causes, ordered by likelihood

Likely causes, from most common to less common:

Mistyped or incomplete URL: A spelling error, missing path segment or incorrect letter case points to a resource that does not exist.
Deleted or moved content: The page or file was removed, renamed or relocated without a relevant redirect.
Broken internal or external link: A link still references an obsolete URL, often after a migration or URL-structure change.
Missing application route: The deployed application does not define the requested page or API endpoint, or the path uses the wrong API version or prefix.
Incorrect rewrite or permalink rules: Apache, Nginx, a framework router or a CMS configuration fails to send a valid path to the intended handler.
Deployment or document-root problem: A file, route or build output was not deployed, or the server is serving a different directory than expected.
Reverse-proxy mismatch: A proxy or gateway sends the request to the wrong application or backend, where that path is unknown.
Case-sensitive path difference: A URL that works on one environment may fail on a case-sensitive filesystem or server when its capitalization does not match the route or filename.

How to fix it

Diagnostic flow at a glance — full detail in the steps below.

If you are visiting the site

Recheck the address, including spelling, capitalization, hyphens, file extensions and every path segment.
Remove a suspicious final path segment or navigate from the site homepage and built-in search to locate the current page.
If the page was reached through a bookmark or search result, look for a newer version of the content rather than repeatedly refreshing the same URL.
Report a broken trusted link to the site owner with the exact URL and the page where you found it.

If you manage the site

Confirm the failing request. Record the exact path, HTTP method, host, query string and the time of the failure. Check whether the problem affects one URL, one route family or the entire site.
Decide whether the resource should exist. Check the content record, deployed files or application route definition. A deliberately removed resource should normally remain a 404 unless a genuinely relevant replacement exists.
Compare a failing and working path. Look for differences in case, trailing slashes, file extensions, locale prefixes, API version, route prefix and query handling.
Inspect routing and rewrite configuration. Review the application router, CMS permalinks, web-server rules, document root and reverse-proxy mappings. Make configuration changes only with appropriate authorization, after preserving the current configuration and considering their effect on other routes.
Check the deployment. Confirm that the expected file, build output, route and static assets were included in the deployed release and that the active server is using the intended release.
Review logs. Use web-server, proxy and application logs to determine which component generated the 404 and whether the request reached the expected backend. Remove or sanitize credentials, tokens and personal data before sharing logs.
Repair links or redirects. Update internal links to the current path. If content permanently moved, configure an authorized permanent redirect to the closest equivalent destination. Do not redirect unrelated missing URLs to the homepage.
Verify the error response. Request the original missing URL and confirm it returns HTTP status 404. A custom error page can be useful, but it should not turn a missing resource into a misleading successful 200 response.
Retest affected paths. Check the original URL, the replacement URL if one exists, representative working routes and relevant API methods after the change. Monitor 404 logs afterward for remaining broken links.

Prevention & how to verify the fix

Run broken-link checks before and after migrations, redesigns and URL-structure changes.
Keep documented redirects for important content that moves permanently.
Test representative page, asset and API routes as part of each deployment.
Treat path capitalization, trailing slashes, locale prefixes and API versions as explicit routing decisions.
Keep web-server, reverse-proxy and application routing configuration under change control.
Monitor frequently requested 404 paths to identify broken internal links, outdated integrations and recurring user requests.
Preserve stable URLs for content intended to remain available or indexed.
Ensure custom error templates retain the correct HTTP status.

When to get outside help

Escalate to the site, application or infrastructure owner when a route should exist but the router and server disagree, a deployment removes many URLs, or a rewrite or proxy change affects broad sections of the site. Provide the exact path, HTTP method, expected destination, first observed time, recent deployment or configuration changes, and sanitized relevant logs. In production, avoid broad routing or redirect changes without authorization, a rollback plan and testing of unaffected routes.

Run a website check

Frequently asked questions

Does a 404 mean the whole website is down?

No. A 404 means the requested resource was not found. Other pages, files or API routes on the same host may continue to work normally.

Is a 404 caused by DNS or an SSL certificate problem?

Usually not. A 404 is an HTTP response from a server or application, while DNS, TLS and connection failures occur before a normal HTTP response can be returned.

Should every 404 redirect to the homepage?

No. Redirect only when the requested content has a genuinely relevant replacement. Keeping an unrelated or permanently missing URL as a proper 404 gives users and crawlers a clearer result.

Can rewrite rules cause a valid URL to return 404?

Yes. Incorrect web-server rewrites, CMS permalink settings, document-root configuration or application routing can stop a valid path from reaching its intended handler.

Why does an API endpoint return 404 when the host works?

The endpoint path, HTTP method, API version or prefix may be wrong, the route may not be deployed, or a reverse proxy may be sending the request to a backend that does not provide it.

Should a custom Not Found page return HTTP 200?

No. The page may have a helpful custom design, but a resource that does not exist should normally retain HTTP status 404.

Further documentation

MDN Web Docs — HTTP 404 Not Found: Reference for the meaning and semantics of the 404 status code.
RFC 9110 — HTTP Semantics: Formal HTTP semantics and status-code definitions.

For implementation details, consult the documentation for the web server, reverse proxy, CMS or application framework used by the affected site, especially its routing, rewrite, redirect and custom error-response guidance.