404 Errors Checklist: Find, Fix, and Prevent Broken URLs

The complete 404 errors checklist

Use this sequence before changing redirects or deleting records. It separates consequential errors from normal URL decay and prevents blanket fixes that create soft 404s.

1. Confirm the final HTTP status with an HTTP request, crawler, or browser developer tools.
2. Check whether redirects, JavaScript, a content delivery network, or a security layer changes the response.
3. Identify every internal page, canonical tag, hreflang annotation, structured data item, feed, and XML sitemap that references the URL.
4. Review organic traffic, referral traffic, conversions, backlinks, and historical purpose.
5. Determine whether an equivalent replacement exists.
6. Use 301 for a permanent move, 302 for a temporary move, 404 when no replacement exists, or 410 when permanent removal is known.
7. Update internal links to the final destination instead of relying on a redirect.
8. Remove the old URL from sitemaps and other machine-readable feeds.
9. Test status codes, redirect hops, canonical signals, rendering, and indexability.
10. Monitor logs and search reporting for recurring patterns.

Not every 404 requires intervention. A random mistyped URL with no links, visits, or strategic value can remain a 404. An internally linked product page with backlinks and sales history deserves immediate investigation.

What a 404 status means

HTTP 404 Not Found is a client error response. Under RFC 9110, it means the origin server did not find a current representation for the target resource, or is unwilling to disclose that one exists. The status alone does not establish whether the absence is temporary or permanent.

Common causes include deleted pages, URL migrations, mistyped links, changed category paths, expired products, malformed parameters, case sensitivity, missing files, routing failures, and client-side applications that do not map invalid routes correctly.

Hard 404 versus soft 404

A hard 404 returns the actual HTTP 404 status. A soft 404 returns 200, or sometimes redirects to an irrelevant destination, while showing content that effectively says the requested page does not exist. Search systems must infer the failure from the page rather than receiving an accurate protocol signal.

A custom error page is not inherently a soft 404. It can provide navigation, search, and recovery options while still returning a genuine 404 response. Test the network response rather than judging the visible design.

Prioritize 404s with a value and exposure matrix

A raw error count is a poor work queue. Score each URL by user exposure, recoverable authority, commercial importance, and whether your own systems continue to reference it.

For large sites, add a weighted score. A practical model assigns points for internal inlinks, linking root domains, sessions, conversions, sitemap inclusion, recent crawler requests, and strategic page type. This makes remediation auditable and prevents teams from spending weeks on valueless historical noise.

Choose 301, 302, 404, 410, or restoration

Choose the response according to user intent and the resource lifecycle, not according to a desire to eliminate an error report.

1. Does the original resource still belong at the same URL? Restore a useful 200 page and correct the technical failure.
2. Is there a permanent, substantially equivalent replacement? Use a server-side 301 redirect. Update internal links, canonical tags, hreflang references, and sitemaps to point directly to the destination.
3. Is the relocation genuinely temporary? Use 302 and retain the original URL in your internal architecture where appropriate.
4. Is permanent removal known and no replacement exists? Use 410 Gone.
5. Is the URL simply unavailable with no suitable replacement? Keep a true 404.

Similarity matters more than category proximity. A deleted tutorial about configuring a specific feature should not redirect to a generic blog homepage. A discontinued product can redirect to its direct successor, but not automatically to a broad product category. Google specifically warns that redirecting many unrelated URLs to the homepage can confuse users and may be treated as a soft 404.

Do not use 404 or 403 for rate limiting. Google notes that 4xx responses other than 429 can lead to content being removed from Search. Use an appropriate capacity or rate-limit response and fix the underlying availability problem.

Find every meaningful 404 source

No single report provides a complete inventory. Combine discovery channels, then deduplicate by normalized URL and final response.

• Site crawl: Crawl internal HTML, images, scripts, stylesheets, canonicals, hreflang, structured data, and pagination. Export each broken URL with its source page and anchor.
• Search reporting: Review indexing and crawl reports, but remember that reports can include old, externally linked, or automatically discovered URLs.
• Server and edge logs: Group 404 requests by path pattern, user agent, referrer, frequency, and response time. Logs reveal URLs that a link crawler may never encounter.
• Analytics: Track visits that render the custom 404 template. Preserve the requested path and referrer without collecting unnecessary personal information.
• Backlink data: Identify missing URLs with meaningful external links, referral traffic, brand citations, or links from authoritative documents.
• XML sitemaps and feeds: Validate every submitted URL and media reference.
• Release monitoring: Compare routes before and after migrations, redesigns, CMS changes, localization launches, and product feed updates.

Screaming Frog documentation describes exporting response codes, inlinks, anchors, and source pages. Whatever crawler you buy, require source-link reporting, rendered crawling when needed, scheduled comparisons, API or warehouse export, and separate treatment of redirects, hard 404s, and soft 404 candidates.

Fix implementation failures and edge cases

Redirect chains and loops

Point every internal reference directly to the final canonical URL. A chain such as old URL to interim URL to current URL adds failure points and wastes requests. Test protocol, hostname, trailing slash, case, locale, and parameter variants.

JavaScript and single-page applications

A client-rendered Not Found component can leave the server returning 200 for every route. Google advises JavaScript sites to produce meaningful status behavior. Use server-side routing, hybrid rendering, or a platform mechanism that lets invalid routes return 404. Test the initial HTTP response and rendered result separately.

Products, jobs, events, and property listings

Do not apply one rule to every expired item. Temporarily unavailable inventory may retain a useful 200 page if it clearly explains availability and offers valid alternatives. A permanently discontinued item with a direct successor can use 301. An expired listing with no lasting information can return 404 or 410. Remove structured data that no longer matches visible content.

Assets and APIs

Broken images, JavaScript bundles, fonts, API endpoints, and downloadable files can damage usability without appearing in a page-only crawl. Monitor asset requests and distinguish intentional API 404 responses from front end routing defects.

Build a useful custom 404 page without creating a soft 404

The best 404 page admits the failure, helps the visitor recover, and returns the correct status. Include a plain explanation, site search when it works well, links to major sections, a route to support, and contextually selected alternatives. Preserve the requested URL in diagnostics, but do not echo unsanitized input into the page.

Avoid automatically redirecting visitors after a timer. It removes control, obscures the original failure, and complicates diagnosis. Also avoid presenting a full homepage clone with no clear error message. Users need to understand why the expected resource is absent.

Measure recovery rather than admiring the design. Useful events include search use, navigation clicks, support requests, exits, and successful journeys to a valid page. Segment by referrer and requested path. A high recovery rate can improve user experience, but it does not excuse broken internal navigation.

Test the template for accessibility, mobile usability, localization, caching, and failure independence. If the 404 page depends on the same broken application bundle or API that caused the error, it may fail when users need it most.

Control 404s at enterprise scale

At scale, prevention is more valuable than periodic cleanup. Require a redirect map and internal-link update plan for migrations. Block deployment when high-value routes disappear unexpectedly, sitemap URLs return non-200 responses, or templates produce new broken links.

Use log analysis to separate human demand, search crawler requests, malicious scanning, and malformed bot traffic. Group errors by template and path pattern. One CMS component producing 50,000 bad URLs is one root cause, not 50,000 independent editorial tasks.

Maintain canonical discipline. Sitemaps should list canonical, indexable 200 URLs. Canonical tags must not point to missing pages. Hreflang clusters should not contain dead alternates. Navigation, breadcrumbs, related-content modules, and structured data should use final URLs rather than redirected ones.

Assign ownership by failure type: editorial teams for deleted resources and links, engineering for routing and status codes, product teams for lifecycle rules, and SEO for prioritization and validation. Keep a redirect registry with source, destination, reason, owner, creation date, and review date. Review broad rules after migrations so temporary mappings do not become permanent technical debt.

Recover organic value and support AI search retrieval

A valuable missing page can break more than a blue-link ranking. Google states that pages supporting AI Overviews and AI Mode must meet the same foundational technical requirements as Search, including indexability and snippet eligibility. A 404 cannot serve as an indexed supporting page. Bing, Copilot, ChatGPT, and other retrieval systems also depend on accessible sources, links, feeds, or indexes, although their exact selection systems differ.

When an authoritative resource was removed accidentally, restoration may outperform redirection because it preserves the original topic, citations, and query fit. When consolidating overlapping content, redirect only after the surviving page fully answers the old intent. Rebuild important internal links from the relevant hub, not from unrelated sitewide blocks.

Use recovered assets in a topic graph. A durable statistics page, original dataset, comparison, glossary, or expert guide can become a spoke linked from a clear subject hub. Check backlink intersections and unlinked brand mentions before retiring such assets. If external sources cite the old URL, contact high-value publishers after restoration or migration and request a direct update.

Digital PR should create genuine link demand through useful evidence, not fabricated statistics or deceptive redirects. Refresh cited resources on a defined schedule and monitor their outgoing references. Link rot research shows that broken references persist across the web, so maintaining citation destinations is an ongoing publishing responsibility.

KPIs, evidence strength, and common mistakes

Track metrics that describe exposure and prevention: internally linked 404 count, percentage of sitemap URLs returning 200, high-value backlink destinations recovered, median remediation time, new 404s per release, redirect-chain count, soft 404 candidates, 404 requests from human referrals, and recurrence by template. Total historical 404 count alone is not a reliable performance target.

What is proven

HTTP specifications define 404 as a missing current representation and 410 as known permanent removal. Google officially recommends accurate status codes, relevant permanent redirects for moves, current sitemaps, and avoidance of irrelevant homepage redirects. A page displaying an error while returning 200 can be classified as a soft 404.

What practitioner consensus supports

Experienced technical SEO practitioners generally prioritize active internal links, backlinks, traffic, and revenue over unreferenced historical URLs. Current community discussions repeat this distinction, but forum reports are anecdotal and do not establish ranking causation.

What remains uncertain

There is no universal threshold at which a number of 404s harms every site. Crawl behavior varies with site size, change frequency, architecture, demand, and server health. Independent research provides prevalence evidence, including a 2024 study where 35.2 percent of 88,000 sampled homepages had at least one broken link, but that is not a universal or current benchmark for every website.

The highest-risk mistake is mass redirecting every missing URL to a homepage or category merely to reduce reports. Other failures include leaving broken internal links in place, returning 200 on error templates, keeping dead URLs in sitemaps, redirecting through chains, and restoring thin pages solely to avoid a 404.