Designing a website without 404s

Original Article ↗ Hacker News Discussion ↗

A proposal to eliminate 404 “Not Found” pages by automatically redirecting mistyped or obsolete URLs to the closest-matching content divides opinion among web developers. Supporters see it as a user-friendly way to handle link rot and URL changes, while critics warn it can mislead users (especially in sensitive domains like medication), break the web’s expectation of stable, unique URLs, confuse search engines, and enable trolling. Many favor a compromise: still return a proper 404 status but present “Did you mean…?” suggestions or redirects only when the previous canonical target is known.

Concept: Fuzzy URL Matching Instead of 404s

  • Site maps mistyped or non-existent product URLs to the “closest” supplement page instead of returning 404.
  • Originally motivated by auto-migrating changing URL schemas and product renames.

Perceived Benefits

  • Can be helpful on search-centric sites: users already expect to browse results, not hit precise slugs.
  • Useful for typo recovery and link migrations.
  • Multiple URLs pointing to the same content is seen as acceptable by some, especially when an ID in the path is the true key.
  • Some users frequently “edit the URL bar” (e.g., for ticket IDs, product codes) and appreciate when that works.

Main Usability and Safety Concerns

  • 404 exists to clearly signal “this doesn’t exist”; silent redirection can mislead users into thinking they got the right page.
  • For medications/supplements this is considered potentially dangerous: a near match could be the wrong product yet look “correct enough.”
  • Bookmarks and shared links might later resolve to different content if matching changes over time.
  • Troll URLs with offensive or conspiratorial text can resolve to innocent products, creating reputational issues.

SEO and Web-Architecture Concerns

  • Risk of duplicate-content and indexing confusion when many URLs resolve to the same page.
  • Debate over whether Google penalizes this; some cite guidelines and migrations that worked fine with proper 301s and canonicals, others see it as fragile and opaque.
  • URLs are treated as a public API surface; fuzzy matching effectively commits the site to an unbounded set of “supported” URLs.
  • Archiving and link-rot handling become harder when URLs are non-deterministic.

Implementation and Scaling Issues

  • Similarity lookups on every bad URL can be expensive; suggestions to cache, throttle, and deprioritize in the database.
  • Large sites with millions of URLs may find fuzzy DB queries impractical.

Suggested Alternatives and Compromises

  • Keep proper 404 (or 410) status codes and show a rich “Did you mean…?” page with search, suggestions, and top similar URLs.
  • Use canonical URLs with IDs, and redirect only when ID matches but slug doesn’t.
  • For migrations, store old URLs and do explicit 301/302/307/308 redirects; use fuzzy matching only as on-page suggestions, with similarity thresholds.

Author’s Updated Plan

  • Track which URLs map to which products.
  • On 404:
    • If URL was previously associated with a product, redirect to that product.
    • If it’s a new, unknown URL, return a 404 page that lists similar products instead of silently redirecting.