404 Errors: 12 Mistakes to Avoid and How to Fix Them

What a 404 error actually means

HTTP 404 Not Found means the origin server cannot find a current representation of the requested resource, or is unwilling to disclose that one exists. The status does not establish whether the absence is temporary or permanent. That distinction comes from HTTP Semantics in RFC 9110.

Visitors can encounter a 404 after following a broken link, entering a mistyped address, opening an obsolete bookmark or requesting a deleted page. Search crawlers encounter the same response while revisiting known URLs or discovering links.

A 404 is therefore a protocol response, not an SEO penalty. Google can remove a URL returning a persistent 4xx response from its index, but that is usually the desired outcome for content that no longer exists. The SEO risk comes from accidentally making valuable content unavailable, wasting links, or sending contradictory signals.

The 12 most damaging 404 mistakes

1. Redirecting every 404 to the homepage. The destination is usually irrelevant, frustrates visitors and may be interpreted as a soft 404.
2. Returning 200 for a missing page. A friendly design does not replace the correct HTTP status.
3. Leaving broken internal links live. Visitors and crawlers should not need to discover an intentional deletion through navigation.
4. Deleting a URL with valuable backlinks without reviewing replacement options.
5. Redirecting to a loosely related page. Similar keywords do not necessarily mean equivalent intent.
6. Keeping 404 URLs in XML sitemaps. Sitemaps should describe canonical URLs intended for indexing.
7. Using 404 or 403 for rate limiting. Google advises using 429 or 503 for temporary capacity problems.
8. Creating redirect chains. Old URLs should point directly to the final destination.
9. Ignoring case, slash and parameter variations. Routing inconsistencies can create large families of broken URLs.
10. Handling missing routes only in client-side JavaScript. Crawlers may receive 200 before the interface displays a missing-page message.
11. Trying to fix every historical 404. Random bot requests and obsolete external URLs may have no business value.
12. Judging success only by Search Console counts. A reported URL needs context from links, traffic, status history and site architecture.

404, 410, 301, 302 or 200: the decision matrix

Choose a response according to the resource state and user intent. Do not choose it merely to make an audit warning disappear.

A 301 is justified only when the destination is a credible continuation of the old resource. If a discontinued product has a direct successor, redirecting may help. If no comparable product exists, a useful 404 or 410 is more honest than a redirect to a broad product category.

A practical framework for prioritizing 404 fixes

Do not work through a raw URL export from top to bottom. Score each affected URL using five signals: internal inlinks, organic traffic, conversions, external backlinks and intended indexability.

1. Critical: A current navigation, template, canonical, hreflang tag or sitemap points to the URL. Repair the source link or restore the page immediately.
2. High: The URL has qualified backlinks, recent organic visits, conversions or a close replacement. Restore it or implement a relevant 301.
3. Medium: External links or user visits exist, but the replacement is imperfect. Review intent manually before redirecting.
4. Low: The URL has no internal links, traffic, backlinks or valid replacement. Retain 404 or 410 and monitor only if the pattern grows.
5. Ignore or block at the edge when appropriate: Obvious exploit probes, malformed bot URLs and infinite parameter combinations may require security or crawl controls rather than redirects.

A useful decision question is: Would a visitor requesting the old URL consider the destination the same resource or a clear successor? If not, do not redirect automatically. This rule prevents redirect maps from becoming collections of misleading approximations.

How to find the cause, not just the URL

Combine several evidence sources because each reveals a different part of the problem. A crawler finds currently linked errors. Search Console shows URLs Google has encountered. Analytics identifies visits and commercial impact. Backlink tools reveal external authority. Server logs show actual crawler requests, response frequency and recurring URL patterns.

Diagnostic sequence

1. Crawl the site and export every internal URL returning 404 or 410, including its linking pages, anchor text and link location.
2. Validate the status with an HTTP request rather than relying only on what a browser displays.
3. Compare the URL against XML sitemaps, canonicals, hreflang annotations, structured data and navigation templates.
4. Check analytics, conversions and landing-page history.
5. Review backlinks and referral visits before choosing restoration, redirection or removal.
6. Inspect server logs for Googlebot requests, status trends and patterns such as uppercase paths, old directories or malformed parameters.
7. Test the final response through every redirect hop on mobile and desktop user agents.
8. Recrawl after deployment and annotate the release so recurring errors can be traced.

For a handful of URLs, browser developer tools and command-line HTTP checks may be sufficient. Large sites benefit from a crawler, log analyzer, backlink index and scheduled monitoring. Tool selection should favor exportable inlink data, rendered JavaScript testing, redirect-chain reports and integrations with analytics or log storage.

Soft 404s and JavaScript routing failures

A soft 404 occurs when a URL appears unavailable but does not return an appropriate missing-resource status. The classic example is a page that says “product not found” while returning 200. Google may classify that URL as a soft 404 based on the response, content and destination behavior.

Soft 404s create ambiguity. Google states that true 404 responses are a strong signal not to recrawl a URL, while soft 404s can continue consuming crawl resources. A 2025 WebSci redirection study identified 62,000 custom 404 URIs in its dataset and classified nearly half as soft 404s. This is dataset evidence, not a universal rate for all websites.

Single-page applications require special care. If the server returns the application shell with 200 for every route, client-side rendering may later display a missing-page screen without changing the response seen by the crawler. Use server-side routing, server-side rendering or another implementation that provides meaningful status codes. Test the initial response and rendered result separately using Google’s URL inspection and rendering tools.

Custom 404 pages that help users without confusing crawlers

A custom 404 page is fully compatible with a true 404 response. Its job is to help a visitor recover, not to rank as a substitute landing page.

• State plainly that the requested page could not be found.
• Preserve the site’s main navigation and visual identity.
• Offer search, popular categories or a small set of contextually useful links.
• Provide a route to report a broken link when the audience is likely to encounter one.
• Avoid automatically redirecting visitors after a timer.
• Do not stuff the page with keywords, hundreds of links or unrelated promotions.
• Record the requested path and referrer in analytics without exposing private URL data.

For ecommerce, suggest the closest category only when it is useful, but keep the 404 status unless the server performs a justified redirect. For documentation, include version navigation and a search box. For local businesses, retain access to locations, contact details and appointment paths while clearly identifying the missing resource.

Prevention for migrations, ecommerce and enterprise sites

Most expensive 404 incidents are process failures. Before a migration, inventory indexable URLs, backlinks, traffic and canonical targets. Build a one-to-one redirect map, reject irrelevant mappings, and test it in staging. Update internal links, canonicals, hreflang, structured data and XML sitemaps at launch rather than depending on redirects forever.

Ecommerce teams should define states for temporarily unavailable, discontinued with successor, discontinued without successor and invalid filter combinations. A product that may return can remain 200 with accurate availability information. A permanent successor can receive a 301. A permanently discontinued item with no substitute can return 404 or 410 after business and link review.

Enterprise sites should assign URL ownership, keep redirect rules in version control and monitor status-code changes after deployments. Pattern-level alerts are more useful than isolated URL alerts. Examples include a rising 404 rate in a locale, an entire media directory failing, or newly published links containing an obsolete path.

Support this with a topical hub-and-spoke architecture. Link durable guides from stable hubs, consolidate overlapping pages before deletion and refresh decaying resources at known URLs. Original datasets, statistics pages and expert resources tend to attract natural links, making preservation and redirect review especially important.

KPIs and validation after a fix

Measure whether users, crawlers and authority signals reached the intended outcome. A lower total 404 count alone is not proof of improvement.

• Broken internal links: Count links, not only unique destination URLs. The target for intentional site navigation is zero.
• High-value 404 exposure: Track missing URLs with traffic, conversions, backlinks or sitemap inclusion.
• Soft 404 count: Monitor reported examples and validate templates or route patterns.
• Redirect quality: Measure direct, intent-matched redirects and the number of chains or loops.
• Recovery: Compare impressions, visits, conversions and referring-link continuity for restored or redirected URLs.
• Crawl behavior: Use logs to observe requests to retired URLs and unnecessary crawling of soft 404 patterns.
• Recurrence rate: Count new internally linked 404s introduced per release or content update.

Validate the final status, rendered page, canonical, indexability and internal links. Search systems need time to revisit URLs, so separate implementation validation from later indexing or traffic outcomes. Keep monitoring long enough to cover the site’s normal crawl cycle.

What is proven, what is consensus and what is uncertain

Proven by standards and official documentation: 404 does not indicate whether absence is temporary or permanent. A permanent move should use 301, a temporary move should use 302, and an unavailable resource without a replacement can return 404 or 410. Google discourages unrelated homepage redirects and requires meaningful status handling for JavaScript sites.

Strong practitioner consensus: Active internal 404s should be repaired first. URLs with traffic or meaningful backlinks deserve manual review. Irrelevant redirects are worse for users than an honest missing-page response. Crawlers, analytics, backlink data and logs should be combined rather than treated as interchangeable.

Still context dependent: There is no universal 404 threshold that harms rankings, no guaranteed timeline for deindexing, and no fixed amount of authority preserved by every redirect. Community discussions often report large historical 404 inventories without obvious ranking damage, but those reports are anecdotal and cannot establish causation.

For Google AI Overviews and AI Mode, the foundational requirement remains ordinary Search eligibility: a supporting page must be indexed and eligible to appear with a snippet. Bing, Copilot and ChatGPT also depend on accessible, retrievable sources. A broken or soft 404 URL is therefore a retrieval and reliability problem, not a separate AI optimization opportunity.