301 Redirect Mapping for a CMS Replatform: A Field Guide

Somewhere out in the world there's a QR code printed on the side of a few thousand product boxes, and it points at a URL on the site you're about to replace. You can't recall the boxes. You can't email the people who scan them. That link either survives the move or it quietly starts spitting out 404s in warehouses you will never set foot in. And here's the part that keeps me up: your CMS export has no idea that URL exists. Redirect mapping for a CMS replatform is the unglamorous work of matching every live URL on your old site to its best home on the new one, with permanent 301s, so that link equity, rankings, and actual humans all make it across. The teams who do it well treat it as a data problem. The gap between their CMS export and the real list of live URLs is usually 20-40% wider than they expect, and that gap is exactly where the boxes 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.

So here's what I actually think. Do the boring inventory before anything else, because you cannot redirect a URL you never wrote down. Pull the union list from logs, Search Console, a full crawl, and backlinks, triage each URL on purpose instead of by vibes, match by intent rather than by string, and then test the whole map like it is code, because to a search engine it genuinely is. If I had to pick one step to never skip, it is that union inventory. That's the one that catches the URLs nobody remembers. Nobody is ever going to praise your redirect map. But months from now, when someone in a warehouse points a phone at a box and lands exactly where they meant to, that is your quiet work holding. Go find the boxes before launch day finds them for you.