Redirect mapping for a CMS replatform is the process of matching every live URL on your old site to its best destination on the new one, using permanent 301 redirects so that link equity, rankings, and human traffic survive the cutover. The teams who do it well treat it as a data problem, not a launch-week scramble: they build a complete source URL list, decide the destination for each one based on user intent, and validate the whole map in staging before DNS ever flips. The teams who learn it the hard way discover missing redirects through a traffic cliff two weeks after go-live.
Start with a URL inventory that is actually complete
The single most common cause of post-migration traffic loss is not bad redirects — it is URLs nobody knew existed. Your CMS admin panel shows you the pages editors created. It does not show you the campaign landing pages, PDF datasheets, old blog taxonomy URLs, paginated archives, or the parameterized variants that Google has been indexing for years.
Pull your source list from at least four places and deduplicate:
- Server logs and analytics — every URL that received a real hit or a Googlebot crawl in the last 12 months.
- Google Search Console — the Pages report and the Performance report, which expose URLs that earn impressions even if they get few clicks.
- A full crawl of the live site, following internal links and the XML sitemap.
- Backlink data — external links point at URLs you may have forgotten, and those are exactly the ones worth preserving.
Union these sources. The gap between your CMS export and this combined list is your risk surface, and it is usually 20-40% larger than teams expect.
Classify before you map
Not every URL deserves a redirect. Mapping every source to a destination one-to-one wastes effort and creates junk. Bucket each URL into a disposition first:
| Disposition | What it means | Action |
|---|---|---|
| Migrate | Content survives with a clear equivalent | 301 to the new URL |
| Consolidate | Several old pages become one | 301 all variants to the winner |
| Rewrite | Content changes but the topic stays | 301 to the new page covering the topic |
| Kill | Low value, no links, no traffic | 410 Gone, or 301 to nearest parent |
A page with zero traffic, zero backlinks, and no keyword footprint does not need to haunt your redirect table forever. Sending it to 410 Gone tells search engines it is deliberately retired. This is the kind of migrate / rewrite / kill triage that a pre-migration content audit is built to automate, so you are mapping decisions instead of URLs.
Match by intent, not by string similarity
The lazy approach is to fuzzy-match old slugs to new slugs and call it done. That fails whenever your information architecture changes — which is the whole reason most teams replatform. A URL like /products/widget-pro-2019 should not redirect to /blog/widget-pro-2019 just because the strings look alike.
Ask one question for each source URL: if a person landed here, what were they trying to do? Send them to the page that satisfies that intent. When no exact equivalent exists, redirect to the closest relevant parent (a category or hub), never to the homepage. A blanket redirect to the homepage is a soft 404 in Google's eyes and passes almost no ranking signal.
The technical details that quietly break things
Even a correct destination map fails if the mechanics are wrong. Watch for these:
- Redirect chains. If A → B → C, collapse it so A → C and B → C directly. Each hop bleeds signal and slows crawlers; chains longer than two or three hops may stop being followed.
- Redirect loops. A → B and B → A produce an infinite loop and a dead page. These appear when two teams map overlapping ranges independently.
- Protocol and host normalization. Decide the canonical form (HTTPS, with or without
www, trailing slash policy) and enforce it at the server, not with hundreds of individual rules. - 302 by accident. Many frameworks default to temporary 302 redirects. A 302 does not pass equity the way a 301 does. Confirm the actual status code, not the intent.
- Query strings. Decide whether parameters are preserved, stripped, or mapped. Faceted URLs and tracking parameters need explicit rules.
Validate in staging, then again at launch
Build the redirect map against the staging environment and crawl your entire source list through it before cutover. For every source URL, record the final status code and final destination after all hops. You are looking for three failure signals: any URL that returns 404, any that lands somewhere other than its mapped destination, and any that resolves through more than one redirect.
Treat the redirect map as a test suite, not a spreadsheet. Every source URL is an assertion: "this input produces this output with this status." Re-run it on launch day and weekly for the first month.
After go-live, monitor Search Console's Pages report for a spike in "Not found (404)" and "Page with redirect" anomalies, and watch server logs for Googlebot hitting old URLs. Crawl budget means large sites can take weeks to fully recrawl; a redirect you missed may not show up in rankings for ten days or more.
A realistic sequence
- Assemble the union URL inventory from logs, GSC, crawl, and backlinks.
- Assign a disposition (migrate / consolidate / rewrite / kill) to each URL.
- Map surviving URLs to destinations by intent.
- Flatten chains, kill loops, set 301 vs 410 deliberately.
- Crawl the full source list through staging and fix every failed assertion.
- Deploy, re-validate at launch, and monitor for four to six weeks.
Redirect mapping is not glamorous, but it is the difference between a replatform that holds its rankings and one that spends six months clawing them back. Do the inventory work up front, decide intent deliberately, and validate like it is code — because to search engines, it is.