when do you need redirects? the checklist for every url that ever existed

seo · Mar 26, 2026 · 4 min read

the sibling post covered what a 301 is; this one answers the operational question: when, exactly, must redirects exist. the principle first — every url that ever worked and was linked, printed, ranked or bookmarked is a promise still held by the internet — then the checklist.

the situations that demand a redirect map

  • any rebuild or migration. the new site’s urls will not match the old ones, because slugs encode decisions and the decisions changed. before launch: the full list of old urls, each mapped to its closest new home. this is the artifact that separates migrations that keep their rankings from ones that amputate them — the mechanism is in what is a 301 redirect.
  • renamed pages.  /services  became  /web-design : one line in the map, the promise kept.
  • deleted pages whose topic lives on. the old blog post about your 2023 offer forwards to the current service page. visitors asked a question; the 404 is you declining to answer.
  • protocol and subdomain canonicalization. http→https, www→bare — permanent, site-wide, forever, per why does my site say not secure.
  • domain changes. every old-domain url forwards to its new-domain twin. the deed itself is covered in what is a domain name; the redirects are how the domain’s history travels.
  • the printed and paid links. brochures, van decals, ad campaigns, instagram bios — they carry urls too, and the redirect map is what keeps them honest after the site changes underneath them.

when you do NOT need one

  • urls that never existed publicly and were never linked — no promise, nothing to keep.
  • staging and preview environments, properly noindexed.
  • the old site’s admin paths and junk parameters nobody ranked for anyway — the audit sorts these from the real ones.

the audit that finds the broken promises

  1. list the old urls: the previous sitemap, search console’s pages report, the wayback machine for anything older.
  2. test each: does it return 200 (still fine), a proper 301 to the right place, or 404 (a promise broken)? the console shows which broken urls google still tries to visit.
  3. fix the 404s that matter — traffic, links, printed material — and let the truly worthless ones rest.

the tool for step one is free and covered in what is google search console; the testing discipline is the same one the sitemap’s orphan-check enforces on my own build, written in forty-two repositories.

FAQ

isn’t a 404 fine for deleted pages?

for pages nothing ever pointed at, yes. for pages with history, the 404 is you answering a real question with nothing — the closest-live-page redirect answers it instead.

how big can a redirect map get?

hundreds of lines for a mature site — it is a spreadsheet, not a poem. the size is why it gets written before the migration, not discovered after it.

do redirects slow the site?

one redirect adds a hop — noticeable only when chained. the map should route directly, old to new; the chain problem is in what is a 301 redirect.

the closing thought

redirects are the memory of a website: they let you rebuild, rename and move without breaking the promises the old urls made. write the map before the change, test it after, and the internet’s memory of you stays intact — because the promises were kept by design, not by luck.

if you are planning a rebuild near Parma: