What Is a 404 Error and How to Fix It

What a 404 error actually tells you

A 404 does not tell you that the whole server is broken. It tells you something narrower: the request reached an HTTP server, but that server could not find the requested resource.

I once investigated a store where the homepage loaded normally while every product link returned 404. The application was not completely down. Nginx was receiving the requests, but the URLs no longer matched the application’s routes after a deployment. That distinction saved us from restarting services that were working perfectly.

When you open a page, your browser sends an HTTP request. If the server cannot match the URL to a file, route, or application record, it returns 404 Not Found. The response does not have to explain why the resource is missing.

That is the useful boundary. PHP and the database can be healthy while one product page returns 404. If you separate the request from the resource it asks for, troubleshooting becomes much less speculative.

Why does a 404 happen?

There is no single cause. A visitor may have typed the wrong address, or the server may be using the wrong file path, rewrite rule, application route, or proxy setting. These are the cases I check most often.

The URL is wrong or incomplete

One missing character is enough. /products/phone and /product/phone are different resources. Case can matter too: on a Linux server, products.html and Products.html are separate files.

Links copied from email or social media can also include punctuation at the end, such as a period or closing parenthesis. Before searching the server, copy the actual URL from the browser and inspect it.

Start there. It sounds obvious, but a surprising amount of server-side debugging begins with an address that was never valid.

The page was deleted or moved

A changed CMS slug, deleted product, moved category, or new permalink structure can leave old URLs behind. If the resource was genuinely removed, 404 may be the correct response. If it moved to an equivalent address, a 301 redirect is usually more appropriate.

Redirecting every old URL to the homepage is not a good substitute. Someone looking for a specific product or article should go to its new equivalent, if one exists. Otherwise, show a useful 404 page instead of a technically successful but confusing redirect.

The web server is using the wrong document root

If Nginx or Apache points to the wrong root directory, it will not find files that are present elsewhere. For example, if the site lives under /var/www/example/public but the configuration uses /var/www/example, the expected index.php and static assets are searched for in the wrong place.

Nginx’s root, alias, and try_files directives deserve particular attention. The try_files directive checks files in the specified order and can pass control to its final parameter. A small path mistake can turn a working application into a wall of 404 responses.

Check the effective server block, not only the configuration file you remember editing.

CMS permalinks or rewrite rules are broken

In systems such as WordPress, friendly URLs usually do not map to real files. They are passed to a front controller, which selects the post or category. If Apache or Nginx does not perform that handoff, the homepage may work while posts and categories return 404.

Saving the permalink settings in WordPress can regenerate some Apache rewrite rules. On an Nginx VPS, that alone is not enough: inspect the relevant location block and the handoff to the PHP front controller. Take a backup before changing anything. Clicking Save in a panel is not a rollback plan.

DNS may be sending visitors to the wrong server

Sometimes the server returning the 404 is not the server that should host the site. A DNS record may still point to an old VPS, CDN, staging machine, or default virtual host.

For a useful distinction, DNS_PROBE_FINISHED_NXDOMAIN means the name could not be resolved, while a 404 means an HTTP server was reached. The existing post How to Fix DNS_PROBE_FINISHED_NXDOMAIN Error covers that difference. After a DNS change, caches can also make different networks show different answers for a while.

The proxy, CDN, or application route returns 404

With a reverse proxy, the request may pass through Nginx, a CDN, or a load balancer before reaching the application. A wrong location match can produce a 404 before the application sees the request. If the application receives it but has no matching route, the application itself returns 404.

Response headers can offer clues. Server, Via, CDN-specific headers, and application headers are not proof on their own, but they become useful when compared with the logs.

One layer at a time.

How I check a 404

I do not begin by deleting files or rebooting the server. First I establish where the request went, which status code came back, and which layer generated the response.

1. Test the URL directly

Copy the address, remove accidental spaces, and test the complete URL. To request only the headers, use curl -I:

curl -I https://example.com/old-page

If you see HTTP/2 404 or HTTP/1.1 404 Not Found, the server received the request and returned 404. The -I option sends a HEAD request rather than downloading the body, which makes it a quick first check.

Some applications handle HEAD differently from GET. When the result is unclear, send a normal GET while discarding the response body:

curl -sS -D - -o /dev/null https://example.com/old-page

This prints the response headers and sends the body to /dev/null. I pay particular attention to an unexpected Location header.

2. Make redirects visible

A URL may pass through several redirects before ending at a 404. The -L option follows redirects, while -w prints the final status and effective URL:

curl -sS -L -o /dev/null -w 'final=%{http_code} url=%{url_effective}n' https://example.com/old-page

The final code is not the whole story. Add -D - when you need to inspect every response header. An unnecessarily long 301 or 302 chain may show that the problem began before the final 404.

3. Confirm DNS and the destination IP

Check where the hostname resolves:

dig +short example.com A
dig +short example.com AAAA

The +short option keeps the output readable. An unexpected IPv6 address can send some clients to a different server, so confirm that the A and AAAA records belong to the same service.

If the error is coming from an upstream behind a proxy, the existing post How to Fix a 502 Bad Gateway Error explains a related but different failure: 502 concerns an invalid upstream response, while 404 concerns a missing resource.

4. Match the request with server logs

Common Nginx paths are /var/log/nginx/access.log and /var/log/nginx/error.log, although distributions and hosting panels may use different locations. Send the request again while watching both files:

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log

The access log usually shows the URL, status code, and client IP. The error log may show a file path or upstream detail. An access-log 404 with no error-log entry is not automatically a problem; Nginx can record an expected missing file only in the access log.

For Apache, check /var/log/apache2/access.log and /var/log/apache2/error.log. PHP-FPM logs can tell you whether the application received the request at all.

5. Check the file and its permissions

For a static asset, first verify that it exists:

sudo stat /var/www/example/public/assets/app.css
sudo namei -l /var/www/example/public/assets/app.css

stat confirms the file, while namei -l shows permissions on each component of the path. If the file exists but the web server cannot read it, you will often see 403, although an application or custom error configuration can mask that as 404.

Do not run chmod -R 777 just to make the error disappear. It changes the symptom, not the permission model, and can create a separate security problem.

Fixing the 404 at the right layer

The correct fix depends on where the request disappears. The order below works as a starting point for file-based sites, CMS installations, and framework applications.

When the file has moved

If the old URL has an equivalent new address, add a 301 redirect. A simple Nginx example is:

location = /old-page {
    return 301 /new-page;
}

Test the configuration before reloading it:

sudo nginx -t
sudo systemctl reload nginx

That -t check is not decorative. I once changed Nginx on a virtual host I thought was staging. It was production. The change did not take the site down, but it was close enough to leave an impression; I now check the hostname before touching the file, and my production shell prompts have been red ever since.

When an application route is missing

Check the route definition and the production base URL. If the request should be /api/v1/users but the client calls /api/users, searching for a missing file in Nginx wastes time. Look in the application logs for route or controller mismatches.

After a deployment, a route cache or compiled asset may still reflect the previous release. Use the official cache-clearing command for your framework, with a backup and a maintenance plan. Copying a generic rm -rf command from a forum can turn a 404 into data loss.

When WordPress permalinks fail

Open the permalink settings in WordPress and save them again without necessarily changing the structure. On some installations this regenerates rewrite rules. If the site uses Nginx, inspect the relevant location block too. With Apache, check that .htaccess exists and is readable.

On a VPS hosting several sites, verify the selected server block as well. If the hostname lands on the wrong virtual host, the correct file can be sitting right there while visitors see another site’s 404 page.

What belongs on a 404 page?

Not every 404 can or should be eliminated. For a deleted resource, a useful custom page is better than a blank error screen.

• State clearly that the page was not found.
• Offer search, main categories, or a link to the homepage.
• Check that the 404 page’s own CSS, JavaScript, and images do not create another chain of 404s.
• Use 301 only when a suitable equivalent resource exists.
• Do not return 200 for a missing page. That creates a soft 404 and can distort monitoring or search data.

Watching 404 logs also helps with content maintenance. If the same old URL is requested every day, it may point to a broken menu, an external link, or a campaign URL that was never updated. Returning the correct status tells crawlers and users whether the resource actually exists.

404, 403, 410, and 500 are different problems

These codes are not interchangeable. RFC 9110 places 4xx responses in the client-error class and 5xx responses in the server-error class.

For 403, inspect the resource and permissions. For 500, inspect application logs. For 502, inspect the upstream connection. Applying the 404 fix to all three only makes diagnosis slower.

Preventing avoidable 404 responses

• List existing URLs before changing the site’s URL structure.
• Prepare a 301 map with old and new addresses for moved pages.
• Test critical pages with curl or automated HTTP checks after deployment.
• Keep web-server configuration in version control and run validation such as nginx -t before changes.
• Review 404 logs regularly; repeated requests for one address often reveal a broken link.
• Test permalink, static-asset, API, and image URLs in staging with a domain layout close to production.
• After DNS changes, check A and AAAA records, CDN origin settings, and the selected virtual host together.

A small crawler is useful as internal links grow. Manually opening every page is not realistic, but an automated report still needs human review. A URL returning 404 is not automatically useless; it may be an old link that needs a precise redirect.

Frequently asked questions

Is a 404 error caused by my internet connection?

Usually not. A 404 means an HTTP server received the request and could not find the resource. If DNS fails, a connection cannot be established, or the network blocks the request, you will see a different class of error.

Are 404 errors bad for SEO?

A 404 for a URL that genuinely does not exist is normal. The real problem is an important page returning 404 because of a configuration mistake, or moved content disappearing without an appropriate redirect.

When should you use a 301 instead of a 404?

Use 301 when the old content has a valid, equivalent new address. If no genuine replacement exists, keep the correct 404; if the resource was permanently removed, 410 may be more precise.

How do you find the source of a 404 error?

Verify the status with curl -I or browser developer tools, then check DNS, web-server configuration, and access and error logs. Once you know which layer generated the response, the fix usually becomes a file-path, redirect, virtual-host, or application-route change.

When I see a 404 now, I resist the urge to restart anything. I check the hostname, run curl, and follow the request until I find the layer that said no.

Sources

• MDN – 404 Not Found — developer.mozilla.org
• RFC 9110 – HTTP Semantics — rfc-editor.org
• NGINX – try_files Directive — nginx.org