Redirect mapping for a CMS replatform is the process of pairing every indexed or linked URL on the old site with a single destination URL on the new one, then enforcing those pairs with permanent (301) redirects at launch. Done well, it preserves rankings, backlinks, and referral traffic. Done badly — or partially — it is the single most common cause of the post-launch traffic cliff, and most teams only discover the gaps after Google has already recrawled and demoted them.
The reason it goes wrong is not usually laziness. It is that redirect mapping looks like a spreadsheet task and behaves like an archaeology project. Below is the field guide built from the failures teams tend to repeat.
Start from crawl reality, not the sitemap
The most expensive mistake is scoping your redirect map from the current CMS export or the XML sitemap. Both undercount. A sitemap lists what the CMS thinks exists; it omits legacy URLs, parameterized variants, paginated archives, old campaign landing pages, and anything served outside the CMS. Your true URL universe is the union of several sources:
- A full site crawl (all internal links, including orphans reachable only via old menus).
- Server access logs — the definitive record of URLs real users and bots actually request, including ones no internal link points to anymore.
- Google Search Console Pages and Performance exports, for URLs receiving impressions and clicks.
- Backlink data from any tool you trust, to catch externally linked URLs you would never find by crawling.
- Historical redirect rules already in place — these must be preserved or chained correctly.
Deduplicate the union. That is your real map size, and it is routinely 2–5x larger than the CMS page count.
Prioritize by value, not by volume
You will not hand-map 40,000 URLs, and you should not try. Segment the universe into tiers and spend human judgment where it pays:
| Tier | Definition | Treatment |
|---|---|---|
| 1 — Manual | Top pages by clicks, backlinks, or revenue | One-to-one, human-verified destination |
| 2 — Pattern | Structured URLs with predictable new equivalents | Regex/rule-based mapping, spot-checked |
| 3 — Consolidate | Thin, duplicate, or retired content | Redirect to nearest relevant parent |
| 4 — Kill | No traffic, no links, no value | Let 410/404 — deliberately, not accidentally |
Deciding what to kill is a real decision, not a default. A page with zero clicks but three authoritative backlinks belongs in Tier 1, not the bin. Sorting this out ahead of launch is exactly the migrate/rewrite/kill work that a pre-migration inventory — the kind Replatform Radar produces — exists to make explicit rather than accidental.
The rules teams break without noticing
Never redirect everything to the homepage
Bulk-redirecting retired URLs to the homepage is treated by Google as a soft 404. You lose the link equity you were trying to save and gain nothing. Map to the most topically relevant surviving page, or return a clean 410 if nothing fits.
301, and only 301, for permanent moves
302s signal a temporary move and pass equity inconsistently. Meta refresh and JavaScript redirects are slower and less reliable for crawlers. Use server-level 301s. If your new platform forces client-side handling, treat that as a risk to escalate, not a footnote.
Eliminate chains and loops
A URL that 301s to a second URL that 301s to a third dilutes equity and wastes crawl budget. This is common when old redirects survive a migration and stack on top of new ones. Every source should point directly to its final live destination in one hop. Flatten chains before launch, not after.
Match the trailing-slash and case rules the new platform enforces
If the new stack canonicalizes to lowercase with trailing slashes and your map targets uppercase paths without them, every redirect fires an extra hop. Generate destinations that already match the new platform's canonical form.
Test before, at, and after launch
Redirect testing is not one event. Build it into three checkpoints:
- Pre-launch, on staging: run the full source list against staging redirects. Confirm each returns a single 301 to a live 200 destination — not a 404, not a chain, not a 302.
- Launch day: re-run against production immediately after cutover. DNS, CDN, and edge rules can override what worked on staging.
- Post-launch, for weeks: monitor Search Console coverage, crawl stats, and server logs. Watch for a spike in 404s, a rise in "crawled – not indexed," and any drop in indexed page count.
Watch the CDN and edge layer
Many redirects now live at the CDN or reverse proxy, not the CMS. If two layers both hold redirect logic, they can conflict or double-hop. Decide on one authoritative layer and document precedence.
Keep the map alive after go-live
Do not delete the redirect map after launch. It is operational infrastructure. New 404s will surface as forgotten URLs get crawled; add rules as you find them. Keep the map for at least a year — Google can take months to fully reprocess a large site, and backlinks from slow-updating third parties will keep hitting old URLs indefinitely.
The teams that avoid the traffic cliff are not the ones with the biggest map. They are the ones who scoped from logs, prioritized by value, enforced single-hop 301s, and treated testing as a process instead of a checkbox.
If you are scoping a specific move, the platform-by-platform notes under the migration guides cover where each CMS tends to hide its legacy URLs and where redirect logic actually lives — the two details that decide whether your map is complete.