A Practical Guide to 404 errors

In practice, 404 errors are not just a technical nuisance. They are failed journeys: a visitor clicked an old link, followed a broken navigation path, mistyped a URL, or arrived from a search result that no longer matches your site.

The good news is that 404s are measurable. A privacy-first analytics setup can surface broken URLs, referrers, devices, countries, and campaign tags without turning the visitor into a profile. The goal is not to identify who hit the error. The goal is to understand which broken paths cost you traffic and fix the ones that matter.

What a 404 Actually Means

A real 404 means the server says the requested resource was not found. That is different from a "soft 404", where the page looks missing but still returns a 200 OK response. Google has warned that soft 404s can limit crawl coverage because crawlers spend time on duplicate or empty pages instead of useful URLs. Google's own guidance says missing content should usually return a proper 404 or 410, or redirect to the closest relevant replacement when one exists.

That distinction matters:

• A deleted campaign landing page with no replacement can return 404 or 410.
• A renamed product page should use a 301 redirect to the new product URL.
• A missing page that redirects every visitor to the homepage can be treated as a soft 404 because it does not satisfy the original intent.
• A custom 404 page should still return the HTTP status 404, not 200.

Do not treat every 404 as a disaster. Search engines understand that pages disappear. The problem is persistent 404 traffic to URLs that used to matter, have backlinks, appear in your own navigation, or sit inside active campaigns.

Track 404s as Events

The cleanest approach is to add an analytics event to your 404 template. Send only the fields needed to debug the issue:

analytics.track('404_viewed', {
  path: window.location.pathname,
  referrer: document.referrer || null,
  query_present: window.location.search.length > 0,
});

For a privacy-first implementation, avoid recording full query strings by default. Query parameters can contain email addresses, search terms, ad click identifiers, reset tokens, and other sensitive data. Store a boolean like query_present, or keep a sanitized allowlist such as utm_source, utm_medium, and utm_campaign.

If your analytics tool supports custom dimensions, attach a small set of debugging context:

• error_path: the missing path, normalized without personal query parameters
• referrer_host: the domain that sent the visitor
• source_type: internal, external, search, campaign, direct
• site_section: blog, docs, pricing, product, account
• environment: production, staging, preview

This keeps the report useful without collecting unnecessary identifiers.

Prioritize by Impact

Once you collect 404 events, sort them by practical cost rather than raw count.

First, look for internal links. If the referrer is your own domain, the fix is usually simple: update the navigation, related posts, sitemap, footer, docs link, or CTA. Internal 404s are the highest-confidence repairs because you control the source.

Second, check campaign traffic. A paid ad, newsletter, affiliate link, QR code, or social post that points to a dead URL wastes budget. If UTM parameters are present, fix the campaign destination and add a redirect from the broken URL.

Third, inspect externally linked URLs. A 404 with referral traffic from a partner, review site, press mention, or high-authority article may deserve a redirect even if the page is old. Use Search Console, server logs, or backlink tools to confirm whether the URL has links worth preserving.

Fourth, separate noise from real demand. Bots request wp-admin, random vulnerability paths, old plugin files, and typo-heavy URLs constantly. Do not create redirects for attack traffic. Block abusive patterns at the edge if they become expensive, but keep your redirect map focused on real user intent.

Choose the Right Fix

Use a 301 redirect when the old page has a clear permanent replacement. A discontinued feature page might redirect to the current feature overview. A renamed blog post should redirect to the new slug. A deleted product page might redirect to the closest category, but only if that category actually helps the visitor.

Use a 410 Gone when a resource was intentionally removed and there is no replacement. This can be useful for expired jobs, old legal pages, deleted user-generated content, or retired documentation that would mislead visitors.

Use a real 404 when the page never existed or the URL is simply invalid. A helpful 404 page should include search, popular links, contact options, and a route back to the main product. It should not pretend the page exists.

Fix the source when you control it. A redirect is a safety net, not a substitute for clean links. Update internal links, XML sitemaps, canonical tags, hreflang references, email templates, app links, and documentation.

A Simple Weekly Workflow

Set up a weekly 404 review with four columns:

Keep a redirect changelog. Old redirect maps become messy quickly, and chains slow down users. Whenever possible, redirect old URLs directly to the final destination instead of chaining /old-a to /old-b to /new.

What to Measure After Fixing

After shipping changes, watch three metrics:

• 404 events for the fixed URL should drop.
• Successful pageviews on the destination should rise.
• Conversions from the affected source should recover if the broken path was business-critical.

Also inspect Google Search Console after major repairs. Its Core Web Vitals report and indexing reports are based on field and crawl data, so they lag behind real-time analytics, but they are useful for confirming whether Google still sees the broken URLs.

The point is not to eliminate every 404. The point is to stop losing visitors through broken paths you can actually control.

404 Cleanup Checklist

Start with the broken URLs that have real visitors, internal referrers, campaign traffic, or valuable backlinks. For each one, decide whether to fix the source link, add a direct 301, return a clear 410, or leave the 404 alone because it is bot noise. After the change, compare 404 events with destination pageviews and backend conversions so the repair is tied to recovered user intent, not just a cleaner report.