404 Error

A 404 error is the server's way of saying "you reached me fine, but nothing lives at that address." It's the correct, honest answer when a page has been removed and has no meaningful replacement, and despite two decades of SEO folklore, a normal quantity of 404s harms nothing.

Where 404s actually cost you is in three specific situations: when URLs with backlinks or steady traffic die without a redirect (that equity is now unclaimed), when internal links point at missing pages (users hit walls, crawl cycles get burned on dead ends), and when the 404 page itself is a design afterthought that ejects visitors from the site. The status code isn't the problem. Untriaged 404s are.

What an honest 404 looks like

Verify the status, not the page design, plenty of "Page not found" screens secretly return 200:

curl -I https://example.com/this-never-existed/

HTTP/2 404
content-type: text/html; charset=UTF-8

A custom 404 page that keeps the correct status code, on Apache:

# .htaccess, path, never a full URL
ErrorDocument 404 /error-404.html

And on nginx, the internal keyword stops the error page being addressable directly:

error_page 404 /error-404.html;
location = /error-404.html {
    internal;
}

Careful with the Apache one: set ErrorDocument 404 https://example.com/error-404.html (a full URL instead of a path) and Apache issues a 302 redirect to the error page, which then returns 200. You've just converted every missing page into a soft 404 with one config line. What belongs on the error page itself, search box, category links, the stuff that recovers the visit, is covered in 404 page best practices and the implementation guide.

404 vs 410 vs soft 404: how each gets handled

The 404-vs-410 decision gets its own treatment in 404 vs 410: handling removed pages the right way. The short version: the difference is real but small, and either honest code beats a dishonest 200 by a mile, the dishonest version is the soft 404, which has its own entry because it deserves one.

How to check it on your own site

1. Confirm your error handling is honest: request a garbage URL (curl -I https://yoursite.com/xyz-$(date +%s)/) and confirm you get a literal 404 header, not a 200 or a redirect.
2. Crawl the site with Screaming Frog, open Response Codes → Client Error (4xx), then use the Inlinks pane on each URL. A 404 with internal inlinks is your bug to fix; a 404 with zero inlinks that Google found in some ancient sitemap is usually noise.
3. In Search Console, open Indexing → Pages → Not found (404) and export. Cross-reference against your backlink tool of choice, any 404 URL with referring domains is unclaimed equity begging for a 301 to the closest live equivalent.
4. Check your access logs for 404 frequency by URL. A missing URL Googlebot hits daily deserves attention before one it hits yearly.
5. Test the 404 template itself in a browser with DevTools open: does it load fast, keep navigation, offer search, and, critically, return 404 in the Network tab even when rendered by your JS framework?

Common mistakes

• Blanket-redirecting all 404s to the homepage. Google classifies irrelevant redirects as soft 404s, users get teleported somewhere they didn't ask for, and you lose the diagnostic signal entirely. Fix: redirect only where a genuinely equivalent page exists; let the rest 404.
• Panicking at the GSC 404 count. "Not found (404)" in the Pages report is informational, not a penalty ledger. Ancient URLs, scraper-mangled links, and long-dead parameters accumulate there harmlessly. Triage by inlinks, backlinks, and traffic, then ignore the rest.
• An error template that returns 200. Especially common on single-page apps, where the router happily renders "Not found" over a 200 response. Fix: configure the server or prerender layer to send the real status; the JS layer alone can't.
• Deleting pages during content pruning without checking backlinks first. The content was thin; the links pointing at it were not. Fix: backlink-check every URL on the kill list, 301 the linked ones to relevant survivors.
• Letting internal links rot. Every internal link to a 404 is self-inflicted, you control both ends. Fix: make a 4xx-inlinks crawl part of your monthly routine and fix at the source, not with patch redirects.

FAQ