404 Not Found Error: Causes and How to Fix It

A 404 Not Found means the server you reached understood the request just fine, looked for the resource at that exact path, and came up empty. That's different from a timeout or a 500 - the server is alive and working, it just can't find the specific file or route you asked for. Here's how to find out which of the handful of real causes is yours, and fix it.

What 404 actually means

HTTP 404 is a client-error response, not a server-error one. The web server received your request, resolved it to a specific file path or application route, checked whether that resource exists, and it didn't - so it returned 404 instead of serving anything. That's the opposite of a 502 or 503, where the server itself is struggling. A 404 usually means one of three things: the URL is genuinely wrong, something that used to be there got moved or deleted, or the server is looking in the wrong place because of a misconfigured rewrite rule, DNS record, or cache.

The fix depends entirely on which of those three it is, so don't jump straight to "reinstall WordPress" - spend two minutes narrowing it down first.

Step 1: Confirm it's really a 404, not something else styled to look like one

Some themes and CDNs render custom error pages that visually resemble a 404 but are actually a different status code underneath. Check the real code before you do anything else:

curl -I https://yourdomain.com/the-page-that-404s

Look at the first line of the response. If it says HTTP/1.1 404 Not Found, you're in the right place. If it says 403, 500, or something from Cloudflare (like a 522), the fix is completely different - see our guides on 403 Forbidden or Cloudflare 521/522/525 instead.

Cause 1: The page or file genuinely doesn't exist anymore

The most common reason is also the most boring one: the content was deleted, renamed, or never published at that URL. This happens after a redesign, a CMS migration, or someone editing a slug without setting up a redirect.

• Check your CMS admin (WordPress, etc.) for the page under a different slug or in Trash.
• Check File Manager in cPanel if it's a static file - confirm the exact filename, extension, and case (Linux servers are case-sensitive, so Image.JPG and image.jpg are different files).
• If the page moved on purpose, add a 301 redirect from the old URL to the new one instead of leaving visitors and Google hitting a dead end - see our URL redirect guide for the syntax.

Cause 2: Broken rewrite rules in .htaccess

If entire categories of URLs 404 - every blog post, every product page, every route that used to work - but your homepage loads fine, the rewrite rules that translate pretty URLs into actual file paths are broken or missing. This is extremely common after a migration, a plugin update, or someone manually editing .htaccess.

In cPanel, open File Manager, enable "Show Hidden Files" in Settings, and check the .htaccess in your site's document root. For WordPress specifically, the block should look like this:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

If that block is missing, truncated, or duplicated, restore it and save. If mod_rewrite itself isn't enabled on the server (rare on cPanel, more common on custom Apache/Nginx VPS setups), rewrite rules will be silently ignored no matter how correct they are - check with your host or, on a VPS you manage, confirm with apache2ctl -M | grep rewrite.

Cause 3: Wrong document root or app deployed to the wrong path

On a VPS running your own Nginx or Apache config, a 404 on every single URL - including the homepage - almost always means the web server's document root doesn't point at where your files actually live. Check the vhost config:

server {
    listen 80;
    server_name yourdomain.com;
    root /var/www/yourdomain.com/public;   # <- does this path actually exist and hold your files?
    index index.html index.php;
}

A stray trailing slash, a leftover staging path, or deploying a new build to a different folder than the one Nginx is configured to serve are the usual culprits. Confirm the path with ls /var/www/yourdomain.com/public before touching the config, and reload with nginx -t && systemctl reload nginx after fixing it.

Cause 4: DNS pointing at the wrong server

If the 404 looks unfamiliar - wrong branding, wrong error page design, or it's clearly not your host's default page - your domain may be resolving to a server that never had your site on it in the first place. This happens after switching hosts when the A record or nameservers weren't fully updated, or when a stale CDN/proxy edge is still cached with an old origin.

dig yourdomain.com A +short
dig yourdomain.com NS +short

Compare the IP against your actual hosting server's IP. If they don't match, you're hitting the wrong box entirely - see pointing your domain correctly and DNS propagation for how long the fix takes to take effect everywhere.

Cause 5: A caching layer is serving a stale 404

If you just fixed the underlying issue but the page still 404s, a CDN, browser cache, or server-side page cache (LiteSpeed Cache, Redis, Varnish) may be serving a cached 404 response instead of re-checking. Purge in this order:

1. Server-side cache plugin (LiteSpeed Cache, WP Rocket, etc.) - use its "Purge All" button.
2. CDN/proxy cache - in Cloudflare, go to Caching → Configuration → Purge Everything.
3. Your own browser - hard refresh with Ctrl+Shift+R (Cmd+Shift+R on Mac), or test in an incognito window.

Quick reference table

Prevention

• Set up 301 redirects whenever you rename or remove a published URL - never let a live link go dead.
• Keep a backup of a known-good .htaccess before letting a plugin or theme rewrite it.
• After any migration or host change, verify DNS with dig before telling anyone the new site is live.
• Submit an updated XML sitemap in Google Search Console after large URL changes so crawlers stop hitting the old paths.