301 Redirect Mapping Mistakes That Break a Replatform

You click a link a colleague sent you a year and a half ago, back when it was the whole point of the email, and you land on a page that politely tells you it never existed. Somebody, somewhere, launched a new site and forgot that link was still out there earning its keep. That's the small, quiet version of the thing that keeps me up: an old URL that pulls in traffic, backlinks, or crawl equity needs a permanent, one-hop redirect to its closest equivalent on the new platform, and most teams find out which ones mattered only after they've already broken them. Get the map right and rankings usually recover within weeks. Ship it late, incomplete, or stuffed with chains, and you claw back traffic for months. This guide covers what to map, how to prioritize, and the mistakes teams make on their first go. Nearly all of them.

What a redirect map actually is

A redirect map is a two-column source-of-truth: old URL → new URL, one row per live path on the old site. It is not a rewrite rule you improvise at cutover. It is a reviewed artifact, built before go-live, that your platform, CDN, or edge layer executes as HTTP 301s the moment the new site is live.

The trap is treating it as a technical afterthought. In practice the map is a content decision. Deciding where an old page "goes" requires knowing whether the destination still exists, whether it's a true equivalent, and whether the page was worth keeping at all. That's why redirect mapping and content inventory are the same project. You can't map what you haven't inventoried.

Start from the URLs that matter, not the sitemap

A CMS export or XML sitemap tells you which pages the CMS thinks exist. It does not tell you which URLs the outside world actually requests. Merge at least four sources before you map anything:

Crawl data: every internally linked, indexable URL.

Analytics, every path with sessions in the last 12 months (captures seasonal pages a shorter window misses).

Search Console / Bing: every URL with impressions or clicks, plus indexed URLs you may have forgotten.

Backlink data. External links point at old URLs; those are pure equity you cannot afford to 404.

The union of these lists is your true universe. It is almost always larger than the CMS export, often by 20-40%, because it includes old campaign URLs, PDFs, paginated archives, and pages deleted from the CMS but still linked externally.

Prioritize with data, then map

You will not hand-map 40,000 URLs, and you shouldn't. Segment first:

Tier | Criteria | Treatment
1, Manual | Top traffic, top backlinks, revenue pages | Hand-mapped, human-reviewed
2, Pattern | Consistent old→new URL structure | Rule-based (regex) mapping
3, Fuzzy | No clean pattern, low value | Matched by slug/title similarity, spot-checked
4, Retire | Thin, dead, or zero-value pages | Redirect to nearest parent, not homepage

The 80/20 is real: a small set of URLs carries most of the traffic and links. Map those by hand. Let rules handle the structured bulk. This is exactly the segmentation a tool like Replatform Radar automates, clustering URLs by pattern and value so you know which rows need a human and which don't.

The mistakes teams learn the hard way

Redirecting everything to the homepage

When a page has no obvious equivalent, teams get lazy and point it at /. Google treats homepage redirects for deleted content as soft 404s and passes little to no equity. Always redirect to the nearest relevant parent category: the topic hub, not the front door.

Redirect chains and loops

If the old site already had redirects (and it does), your new map can stack them: /a → /b → /c. Each hop leaks equity and adds latency; long chains get abandoned by crawlers. Flatten every chain to a single hop at go-live. Take your current live redirects and resolve them to their final destination before writing the new rule.

Forgetting the non-page assets

PDFs, images, feeds, and old API paths accumulate backlinks too. A datasheet PDF that ranks and earns links is as valuable as an HTML page. Inventory assets, not just pages.

Trailing slashes, case, and parameters

Platforms disagree on whether /page and /page/ are the same URL, whether paths are case-sensitive, and how they handle tracking parameters. Pick one canonical form, redirect all variants to it, and test both slashed and unslashed inputs.

Testing after go-live instead of before

The map is only a spreadsheet until it's deployed. Validate it in staging: feed every Tier-1 source URL through the redirect engine and confirm it returns a single 301 to a live 200 destination. Do not discover on Monday that 6,000 rules were case-mismatched.

A go-live checklist

Assemble the URL universe from crawl, analytics, Search Console, and backlinks.

Resolve existing redirects so you map to real destinations, not old chains.

Segment into manual, pattern, fuzzy, and retire tiers.

Confirm every destination returns 200 and is genuinely equivalent.

Enforce one canonical form for slashes, case, and parameters.

Test the full Tier-1 set in staging. One hop, correct status, live target.

Keep the map live for at least a year; do not remove rules at the first sign of recovery.

How long to keep redirects

So here's what I actually think, no hedging. Google has said 301s need to stay in place "for at least a year" to pass signals fully, and honestly I'd go further: the high-value ones should never come down at all. Redirects are cheap. A row in a spreadsheet costs you nothing to keep and protects equity you spent years earning. Budget for the map as permanent infrastructure, not a launch task you quietly decommission the first calm week. Delete rules early and you're just re-breaking the same links on a delay.

Nobody brags about redirect mapping at the launch party. You only feel it later, the day some poor visitor clicks that eighteen-month-old link and hits a wall you built. So treat the map like something you genuinely shipped: assemble it from real demand data, flatten every chain to one clean hop, and test the whole thing in staging before you flip the switch. Do that and the cutover is boring. Skip it and that dead link is the least of what you'll be explaining.