A team exports their CMS the week before launch, gets a tidy page count back, and it feels like the finish line has come early. Then someone finally pulls the server logs, and the real number of live URLs turns out to be two to five times bigger, stuffed with old campaign pages, parameter variants, and links nobody remembers publishing. The export wasn't lying. It was just quietly describing a smaller site than the one your visitors are actually walking around in. That gap is the whole reason this subject is worth an afternoon of your attention.
Redirect mapping is the work of pairing every indexed or linked URL on your old site with a single home on the new one, then nailing those pairs down with permanent (301) redirects at launch. Do it well and you keep your rankings, your backlinks, your referral traffic. Do it halfway and you've built the single most common reason traffic falls off a few weeks after a launch everyone applauded. The cruel part is the delay: nobody spots the holes until Google recrawls and quietly marks you down. It doesn't go sideways because anyone's careless. It goes sideways because it looks like a spreadsheet chore and behaves like excavating a building that's been paved over for years. What follows is the field guide, built from the same mistakes teams keep repeating.
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.
What the map itself has to contain
Tiering tells you what to work on first. It does not tell you what the file looks like, and a redirect map that is missing a column is the reason somebody discovers a broken tier-one URL three weeks after cutover. Six columns, and every one of them earns its place.
| Column | Why it earns its place |
|---|---|
| Old URL | The address on the letter. Pulled from crawl, logs and Search Console together, never from memory or the sitemap alone. |
| New URL | The forwarding desk. One target, resolving 200, no query-string surprises. |
| Status type | 301 for permanent. If anything says 302, it needs a reason written down next to it. |
| Match confidence | Exact, close, or guessed. Anything guessed gets a human before go-live. |
| Traffic or value | So the page earning forty thousand visits gets fixed before the one earning four. |
| Post-launch status | The live response code after cutover. Blank means untested, and untested means unknown. |
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.
So here's where I actually land. If you take away one thing, scope your map from the logs, not the export. Everything else on this list earns its place, but that single move is what separates a map that's complete from one that only looks complete, and those two are not the same thing. Kill the dead URLs on purpose rather than by accident, force every redirect into one clean hop, and keep the map alive for a full year, because that's exactly when the slow backlinks and the forgotten pages come knocking on old addresses.
And if you're staring down a specific move, the platform-by-platform notes under the migration guides cover where each CMS tends to hide its legacy URLs, which is rarely the first place you'd think to look, and where the redirect logic really lives. Get those two right and the site you map is finally the whole site, not the smaller one your export kept insisting was all there was.