A 301 redirect map for a CMS replatform is a complete, tested list that sends every old URL to its single best new equivalent, permanently, before you flip the switch. That is the whole job. Not most URLs. Not the top hundred. Every one that a person or a crawler could still ask for. Get that right and the move is boring; get it wrong and you spend the next two quarters explaining a traffic chart to people who do not want to hear about URL structures.
Here is the thing nobody tells you until it hurts. Redirects are not a technical afterthought you do the weekend of launch. They are the single most valuable thing you carry across, because they are the only proof the new house has the same address as the old one.
Think of it as mail forwarding, not construction
Imagine you move offices. You do not just build the new place and hope everyone finds it. You file a change of address so that every letter sent to the old suite gets walked over to the new one. A 301 is exactly that: a permanent forwarding note that tells browsers, Google, and the AI answer engines that /old-path now lives at /new-path, and that they should hand over the reputation the old address earned.
A 302, by contrast, is the sticky note that says "back in five minutes." It forwards the visitor but keeps the reputation parked at the old door, waiting for you to return. On a permanent move, that is precisely the wrong instruction (and yet it is the default in an alarming number of frameworks, so check yours before you trust it).
So the question that decides your migration is not "did we set up redirects." It is "does every letter get to a real, correct desk, on the first try, and stay there."
What actually breaks the map
Most redirect disasters are not exotic. They are the same four mistakes, wearing different hats.
The first is the letters you forgot existed. Your new sitemap has 2,000 pages. Your old site, once you crawl it properly and pull server logs and pull Search Console, has 9,400 addresses that something out there still asks for. PDFs. Old campaign landing pages. That one blog post from 2017 that quietly earns a third of your organic traffic. If it is not on the list, it does not get forwarded, and a real person hits a 404 that used to be a customer.
The second is the lazy catch-all. Somebody, under deadline, points every unmatched old URL at the homepage. It feels responsible. It is not. Google treats a redirect to an irrelevant page as a soft 404 and drops the target from the index anyway, so you have done the work and kept none of the value. A forward that lands on the wrong desk is barely better than no forward at all.
The third is the chain. Old URL redirects to an interim URL, which redirects to the new one, which itself has a trailing-slash rule that fires a fourth hop. Every hop bleeds a little speed and a little authority, and after five hops Google simply stops following. You built the forwarding, then folded the note into origami.
The fourth, and the meanest, is the loop. /a sends to /b, and a leftover rule sends /b back to /a. The browser gives up. So does the crawler. This one is invisible until someone tries the exact path you never tested.
The mapping table, in the only form that survives
Whatever tool you use, the map needs to carry more than two columns. The extra columns are what let you find the breakage before launch instead of after.
| Column | Why it earns its place |
|---|---|
| Old URL | The address on the letter. Pulled from crawl, logs, and Search Console, not from memory. |
| New URL | The forwarding desk. One target, resolving with a 200, no query-string surprises. |
| Status type | 301 for permanent. If anything says 302, it needs a reason in writing. |
| Match confidence | Exact, close, or guessed. Anything guessed gets a human before go-live. |
| Traffic / value | So you fix the page earning 40,000 visits before the one earning four. |
| Post-launch status | The live response code after cutover. Blank means untested, and untested means unknown. |
The order of operations most teams get backwards
Build the map from a real inventory, not from the new sitemap working backwards. The new site tells you where desks exist; it cannot tell you which letters are still coming. You need the old URLs first, weighted by traffic and links, then matched forward. This is the unglamorous discovery work a pre-migration crawl exists to do, and it is where a tool like Replatform Radar quietly earns its keep by flagging the forgotten PDFs and the orphaned pages before they become 404s.
Then stage it. Load the redirects on the new platform before DNS points at it, and run the full old-URL list through a checker against staging. You are looking for one thing: every old address returns a single 301 to a live 200. No chains. No loops. No homepage dumps. Fix, re-run, repeat until the report is clean.
Then, and this is the part people skip, crawl again on launch day and again a week later. Redirects rot. A well-meaning content edit changes a slug, a caching layer swallows a rule, and a forward that worked at cutover quietly dies on a Tuesday.
What I would actually do
Treat the redirect map as the deliverable the whole migration is judged on, and staff it that way. If I had to choose between a beautiful new design shipping on time and a complete, tested redirect map shipping on time, I would ship the map every single time and make the design wait a week. Rankings you lose to a broken forward take six months to claw back, if they come back at all, and no stakeholder remembers the launch date once the traffic line goes flat.
File the change of address before you move the furniture. The letters are already in the mail.