
A 404 Not Found error is the most common HTTP error on the web. Every site will generate them at some point — whether from a deleted page, a typo in a URL, or a broken link from another website. A handful of 404s won't hurt you. But a large number of them, especially on pages that used to rank or receive traffic, can quietly erode your SEO and frustrate your visitors.
Here's what causes 404 errors, how to find and fix them, and how to prevent them from damaging your site.
A 404 status code means the server is reachable and understood the request, but the resource at that URL doesn't exist. The server simply has nothing to serve at that path.
This is different from a 500 Internal Server Error, where the server itself is broken. With a 404, the server is working fine — it just can't find what was requested.
A 404 can appear because:
The most common cause. Someone removed a page, renamed a slug, or migrated content to a new URL structure without setting up 301 redirects. Any existing links — from Google, from other websites, from your own internal navigation — now point to nothing.
A visitor types yoursite.com/abuot instead of yoursite.com/about. Or a developer hardcodes a link with a missing character. The server looks for the path, finds nothing, and returns 404.
Your own site links to a page that no longer exists. This commonly happens after a site redesign, a CMS migration, or when content is reorganised. Internal 404s are especially damaging because they signal poor site maintenance to search engines.
If your server isn't configured to route requests properly, valid URLs can return 404s. This is especially common with single-page applications (SPAs) or frameworks that rely on URL rewriting.
For example, a Nginx server hosting a Vue or React app needs a fallback rule:
location / {
try_files $uri $uri/ /index.html;
}
Without this, refreshing any page other than the root will return a 404.
WordPress and other CMS platforms can break their permalink structure after an update or plugin conflict. Posts that worked yesterday suddenly return 404s across the entire site.
# In WordPress, try flushing permalinks:
# Go to Settings > Permalinks and click "Save Changes"
# Or regenerate .htaccess manually:
sudo cat /var/www/html/.htaccess
Linux servers treat URLs as case-sensitive. /About-Us and /about-us are two different paths. If a link uses the wrong case, the server returns a 404 even though the page exists at a slightly different URL.
You can't fix what you can't see. Use Google Search Console to find pages returning 404 that Google has tried to crawl:
You can also check your server logs directly:
# Find 404 responses in Nginx access logs
grep ' 404 ' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
This gives you the 20 most-requested URLs that returned 404s.
For pages that were moved or renamed, add permanent redirects so the old URL points to the new one.
On Nginx:
server {
# Single redirect
location = /old-page/ {
return 301 /new-page/;
}
# Redirect an entire directory
location /old-blog/ {
rewrite ^/old-blog/(.*)$ /blog/$1 permanent;
}
}
On Apache (.htaccess):
Redirect 301 /old-page/ /new-page/
RedirectMatch 301 ^/old-blog/(.*)$ /blog/$1
Crawl your own site and update any links that point to pages returning 404. Tools like Screaming Frog or a simple crawl script can find these:
# Quick check for broken links using curl
curl -o /dev/null -s -w "%{http_code}" https://yoursite.com/some-page/
A well-designed 404 page helps visitors find what they were looking for rather than bouncing. Include a search bar, links to popular pages, and a clear message that the page wasn't found.
If your entire site is returning 404s, the problem is almost certainly in your server configuration. Check your rewrite rules, verify your document root is correct, and restart your web server:
# Test Nginx configuration
sudo nginx -t
# Reload Nginx
sudo systemctl reload nginx
# Test Apache configuration
sudo apachectl configtest
# Reload Apache
sudo systemctl reload apache2
A 410 Gone tells search engines the resource was permanently removed on purpose. A 404 simply says it wasn't found. If you've intentionally deleted a page and want Google to de-index it faster, use a 410. If the page moved, use a 301 redirect instead of either.
A single broken page might not seem urgent, but when critical landing pages or product pages start returning 404s, you lose traffic and revenue without realising it. If a deployment accidentally breaks your URL routing and your entire site starts throwing 404 errors, you need to know immediately — not when customers start complaining.
Domain Monitor checks your site every minute from multiple locations around the world. If your monitored URLs start returning 404 status codes (or any non-2xx response), you'll get an alert within seconds via email, SMS, or Slack. You can set up downtime alerts for your most important pages so you catch routing issues, broken deployments, or accidental deletions before they affect your SEO or your users. Combined with proper website monitoring, you can track not just whether your homepage is up, but whether your key pages are actually serving the right content.
| Cause | Fix |
|---|---|
| Page deleted or moved | Add a 301 redirect to the new URL |
| Typo in URL | Fix the link at the source |
| Broken internal links | Crawl your site and update links |
| Bad rewrite/server config | Fix Nginx/Apache rewrite rules |
| CMS permalink issue | Flush permalinks, regenerate .htaccess |
| Case sensitivity | Standardise URLs to lowercase |
A 404 here and there is normal. But a growing number of them is a signal that something needs attention — whether it's a missing redirect, a broken deployment, or a misconfigured server.
Wildcard, SAN (multi-domain), and single-domain SSL certificates cover different use cases. Here's a clear comparison to help you pick the right type — and avoid paying for coverage you don't need.
Read moreDNS resolves correctly from your office but fails for users in other countries or on different ISPs. Here's why geographic DNS inconsistency happens and how to diagnose which layer is causing it.
Read moreRegistrar lock and transfer lock are often confused — and disabling the wrong one leaves your domain vulnerable. Here's a clear breakdown of what each does and when to use them.
Read moreLooking to monitor your website and domains? Join our platform and start today.