Dispatch
What Is a 404 Error? Page Not Found Management Explained
A 404 error is the HTTP status code a server sends when it cannot find anything matching the URL a browser or crawler requested. It is not a bug or...
On this page
A 404 error is the HTTP status code a server sends when it cannot find anything matching the URL a browser or crawler requested. It is not a bug or a sign that your website is broken. It is the web working as designed: a standard, documented response that tells whoever asked, “there’s nothing here.” Every large website accumulates 404s over time, and that alone is not a problem. What matters is why the 404s exist, how many people or bots are hitting them, and whether you handle them with intention rather than letting them pile up unmanaged.
What a 404 actually means
HTTP status codes are grouped by their first digit. The 400 range signals a client-side problem, meaning the request itself could not be fulfilled as made. A 404 specifically means “not found”: the server processed the request but found no resource at that path. This is different from a 500-series error, which indicates something broke on the server itself.
A correctly configured 404 page should still return the literal 404 status code in the HTTP header, even though it shows a friendly, human-readable message in the browser. That header is what search engine crawlers and monitoring tools actually read; the visible page content is for human visitors.
404 vs 410 vs soft 404
These three terms get confused constantly, so it helps to separate them clearly.
| Type | What it means | When to use it |
|---|---|---|
| 404 (Not Found) | The server has no resource at this URL and gives no further detail | Default choice when content is missing or was never there |
| 410 (Gone) | The resource used to exist and has been deliberately, permanently removed | When you intentionally deleted content and want to signal that clearly |
| Soft 404 | The page displays "not found" type content to users but returns a <!–INLINECODE1–> status instead of an actual error code | This is a misconfiguration, not a status you should aim for |
According to Google’s own crawling and indexing documentation, both 404 and 410 responses tell search engines “the page doesn’t exist and you don’t want search engines to index the page,” and pages returning either code are dropped from the index rather than penalized (Google Search Central, troubleshooting crawling errors). In practice, the difference between choosing a 404 or a 410 for SEO purposes is small. Google’s John Mueller addressed this directly in a public discussion about removing a batch of low-quality pages, stating that the difference in how Google processes 404s versus 410s “is so minimal that I can’t think of any time I’d prefer one over the other for SEO purposes” (reported by Search Engine Journal). A 410 can communicate slightly faster removal intent in some cases, but it is not a meaningful ranking lever on its own.
Soft 404s are the configuration genuinely worth fixing. Because the server claims success (200) while showing error-page content, crawlers can’t reliably tell the page is broken, which sometimes results in thin or empty “error” pages getting indexed when they shouldn’t be, or content gaps where Google silently treats a working page as an error. Common causes include empty search-results pages, removed-product pages that redirect to a generic homepage without a real 404 status, or JavaScript-rendered pages that fail to load content but still serve a 200.
When 404s are fine, and when they actually hurt
A 404 on its own is not a quality signal Google penalizes you for. Sites with millions of pages return 404s constantly as part of normal churn: old blog posts get deleted, products get discontinued, users mistype URLs. None of that drags down your rankings by itself.
404s become a real problem in two situations:
- Broken inbound links with existing value. If other websites link to a URL on your site that now 404s, you are losing the equity, referral traffic, and user experience benefit of that link for no reason. This is worth fixing with a targeted redirect, not because Google punishes the 404, but because you are wasting a link you already earned.
- Large-scale, unintentional 404s. If a site migration, a broken internal linking structure, or a CMS bug causes thousands of previously-working URLs to start 404ing at once, that’s a usability and crawl-efficiency problem. Googlebot has to spend crawl resources discovering that those pages are gone, and real users following old bookmarks or search results hit dead ends.
The fix in both cases isn’t “eliminate every 404.” It’s identifying which 404s represent lost value and addressing those specifically.
How to find your 404s
You have several reliable ways to surface 404 errors, and using more than one gives a fuller picture:
- Google Search Console’s Page indexing report. This is the current name for what was previously called the Index Coverage report. It shows URLs Google has tried to crawl that returned a “Not found (404)” status, along with soft 404s under “Why pages aren’t indexed” (Search Console Help, Page Indexing report). This tells you what Google specifically has encountered, which is useful for catching crawl-discovered 404s you might not know about.
- Bing Webmaster Tools, if Bing traffic matters to you. Bing’s Crawl Information report lists the 404s Bingbot ran into separately from what Search Console shows (Bing Webmaster Tools, Crawl Information report). The two crawlers don’t always discover or revisit the same URLs on the same schedule, so checking only Google’s report can leave Bing-specific dead links unnoticed.
- Server log files. Your raw access logs record every request made to your server, including the status code returned and what triggered it (a search engine bot, a referring site, a direct user visit). Log analysis is the most complete source because it captures everything hitting your server, not just what Google or Bing chooses to report.
- Site crawlers. Tools that crawl your site like a search engine would (following internal links) will surface broken internal links that lead to 404 pages, which is different from external 404s caused by other sites linking incorrectly.
- The URL Inspection tool. For a single specific URL, Search Console’s URL Inspection tool lets you check live indexing status and run a real-time fetch to see exactly how Googlebot currently sees that page (Search Console Help, URL Inspection tool).
- Not Google Analytics 4, by default. GA4 doesn’t track HTTP status codes out of the box, so a 404 page that loads your analytics tag still records as an ordinary pageview. Seeing your 404 page in GA4 reporting requires either a 404 template with a distinct page title you can filter on, or a dedicated custom event fired from that template, neither of which is set up automatically.
How to handle 404s once you find them
Not every 404 deserves a redirect. Treating every single one identically, either redirecting everything or ignoring everything, wastes effort in one direction or the other. A simple decision framework:
- Redirect, with a 301 (permanent) status, not a 302. Use this when the old URL has backlinks, meaningful organic traffic history, or is still commonly linked to or bookmarked, and there’s a genuinely relevant replacement page. A 301 signals the move is permanent, which is what you mean in this situation.
- Leave as a 404 (or switch to 410) when the content is gone for good, has no real replacement, and isn’t attracting valuable inbound links. Redirecting unrelated old URLs to your homepage “just in case” creates a confusing, low-value redirect chain and doesn’t help users or search engines.
- Fix the soft 404 configuration when a page is returning a
200status with error-page content. Make sure your CMS or server is actually returning a true 404 or 410 status code, not just displaying error text on a success response.
A well-designed 404 page also matters for the humans who land on it. At minimum it should clearly state the page wasn’t found, keep your site navigation and branding intact so visitors aren’t stranded, and offer a way forward, like a search box or links to popular sections, rather than a dead end.
Ongoing monitoring matters more than a one-time cleanup. Set up periodic checks of your Page indexing report and server logs so a sudden spike in 404s (often a sign of a botched migration, a broken plugin update, or a bad redirect rule) gets caught quickly rather than discovered months later through declining traffic.
SPA and JavaScript routing behavior
Single-page applications and other JavaScript-heavy sites handle “page not found” states differently than traditional server-rendered sites, and this is where a lot of soft 404 problems originate. In a client-side-routed app, the server typically returns a 200 status for every route, including ones that don’t actually exist, because routing happens in the browser after the JavaScript loads. If your app doesn’t explicitly detect the invalid route and either serve a true 404 status (when feasible) or otherwise make the “not found” state unambiguous to a renderer, search engines can end up indexing what is functionally an error page as if it were valid content.
Google does render JavaScript before indexing content, processing pages through crawling, rendering, and indexing as distinct stages (Google Search Central, Understanding JavaScript SEO basics), but rendering doesn’t fix a routing-level status code problem. If you’re building or maintaining a JS-routed site, test how your invalid-route handling behaves using the URL Inspection tool’s live test, and where your framework and server setup allow it, configure server-side or edge-level handling so genuinely missing routes return an actual 404 status rather than relying on client-side JavaScript alone to communicate that the page doesn’t exist.
The practical takeaway
404 errors are a normal, expected part of running a website, not a defect to eliminate entirely. Focus your effort on the cases that actually cost you something: broken links that used to carry value, large unintentional waves of 404s from migrations or bugs, and soft 404 misconfigurations that confuse crawlers about what’s actually an error. Everything else, the routine churn of old URLs quietly disappearing, can be left alone.