The single biggest cause of organic traffic loss after a CMS replatform is a broken or incomplete 301 redirect map. Every old URL that earns traffic, backlinks, or crawl equity needs a permanent, one-hop redirect to its closest equivalent on the new platform. Get the map right and rankings usually recover within weeks; ship it late, incomplete, or full of chains, and you lose traffic that can take months to claw back — if it comes back at all. This guide covers what to map, how to prioritize, and the mistakes teams almost always make the first time.
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
Google has said 301s need to stay in place "for at least a year" to pass signals fully, and there's no harm in keeping high-value ones indefinitely. Cheap redirects that protect backlink equity should simply never be deleted. Budget for the map as permanent infrastructure, not a launch task you decommission.
None of this is glamorous, and most of it gets discovered the hard way — usually the week traffic drops. Treat the redirect map as a first-class deliverable, build it from real demand data, keep it to one clean hop, and test it before the switch. That discipline is the difference between a quiet cutover and a quarter spent explaining a traffic cliff.