A Practical Guide to 404 Errors

Every 404 error on a site is a failed journey, not just a technical nuisance: someone 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 should redirect to the current feature overview. A renamed blog post should redirect to the new slug. A deleted product page should 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.

Frequently Asked Questions

What is the difference between a 404 and a soft 404?

A real 404 tells the server the resource is missing. A soft 404 looks empty but still returns 200 OK, which can limit crawl coverage because search engines spend time on pages that do not actually help visitors.

Should a custom 404 page return a 200 status code?

A custom 404 page should still return the HTTP status 404, not 200. Returning 200 turns it into a soft 404, which confuses search engines about whether the page actually exists.

When should I use a 301 redirect instead of a 410?

Use a 301 when the old page has a clear permanent replacement, like a renamed blog post redirecting to its new slug. Use a 410 Gone instead when the resource was intentionally removed and there is no replacement, such as an expired job listing or a retired documentation page.

How do I track 404 errors without collecting personal data?

Add an analytics event to your 404 template that sends the path, the referrer, and a boolean like query_present. Skip raw query strings by default, since they can carry email addresses, search terms, ad click identifiers, or reset tokens.

Which 404s should I fix first?

Start with internal links, since you control the source and the fix is usually just updating a navigation menu, related posts, or a footer link. After that, check campaign traffic and externally linked URLs that carry real referral value.

Should I redirect 404s caused by bot traffic?

Bot traffic is not worth redirecting. Bots request paths like wp-admin and old plugin files constantly, and building redirects for that traffic wastes effort. Block abusive patterns at the edge instead and keep the redirect map focused on real user intent.

What custom dimensions are useful for a 404 analytics event?

error_path, referrer_host, source_type, site_section, and environment give enough context to debug without collecting extra identifiers. Together they show where visitors came from and which part of the site sent them to a dead link.

Why do redirect chains slow things down?

Chaining /old-a to /old-b to /new adds extra hops before a visitor reaches the final destination. Redirecting straight to the final URL keeps the path fast and keeps the redirect map easier to read.

How do I know if a broken URL is worth a redirect?

Check whether it has referral traffic from a partner, review site, or press mention, and confirm with Search Console, server logs, or backlink tools. A 404 with real backlinks or steady referral traffic usually deserves a redirect even if the page is old.

What should I check after fixing a 404?

Watch for 404 events on the fixed URL dropping, pageviews on the destination rising, and conversions from the affected source recovering if the path mattered to the business. Google Search Console can also confirm whether Google still sees the broken URL, though its reports lag behind real-time analytics.