Picture yourself on a highway you've driven for years. Your GPS says take Exit 7. You've always taken Exit 7. Except this year the state renumbered every exit to match the mileposts, so Exit 7 is now Exit 43, the old sign is gone, and there's nothing telling you the two are the same place. You miss your turn. A redirect map is the sign that says "Exit 7 is now Exit 43." In a CMS replatform, a 301 redirect map is the complete list of every old URL and the new URL that should replace it, sent to the browser and to search engines as a permanent move so the traffic, the rankings, and the links that pointed at the old address all follow you to the new one.
Most teams learn this the hard way. They budget for the migration and treat redirects as a checkbox at the end. Then the old signs come down all at once.
Why a permanent sign, and not a temporary one
A 301 tells Google and every other crawler the move is permanent, so the ranking signals the old page earned should transfer to the new one. Google has said for years that 301s pass ranking signals, and since 2016 that 302s do too, but the two send different messages about intent. A 302 says "back in a minute," and if you leave a 302 in place for months, you're telling search engines to keep indexing the old address you're trying to abandon. For a replatform, where the old URL is never coming back, you want the permanent sign. Every time.
Here's the comparison worth taping to the wall.
| Method | Signal to crawlers | Use in a replatform |
|---|---|---|
| 301 redirect | Permanent move, transfer signals | The default for every changed URL |
| 302 redirect | Temporary, keep old URL indexed | Only for genuinely temporary states |
| Meta refresh | Ambiguous, slow, user-visible | Avoid |
| JavaScript redirect | Depends on rendering, easy to miss | Last resort, never for bulk mapping |
The map is per-URL, not per-template
The single most expensive assumption is that you can write a handful of pattern rules and call it done. "Everything under /blog/ goes to /articles/" feels efficient right up until you find the forty posts that were renamed, the twelve that were merged, and the eight that should quietly die because nobody has read them since the last office move. Pattern rules handle the boring majority. The map exists for the exceptions, and the exceptions are where your best-linked pages tend to hide.
So you inventory first. Every published URL, every redirect that already exists (yes, your current site is probably full of them), every PDF, every image that someone links to from an email newsletter you forgot about. Then you decide, page by page: does this move, get rewritten into something else, or get killed? That decision is the whole job. Building an inventory that predicts what breaks is exactly the unglamorous work we do at Replatform Radar before anyone touches the new platform, because you cannot forward mail you never knew existed.
The traps that leak traffic while everything looks fine
The cruel part of redirect work is that the site can look completely healthy while it bleeds. A few specific things get almost everyone.
Redirect chains. Old URL points to a second URL, which points to a third, which finally lands. Google will follow a chain, but each hop wastes crawl budget and dilutes the signal, and long chains eventually get dropped. Aim for one hop, old address straight to final address. This matters most when your new platform quietly adds its own redirects (http to https, adding or stripping a trailing slash) on top of the ones you wrote. Two of yours plus two of the platform's and suddenly you have a four-hop chain you never authored.
Trailing slashes, case, and protocol. To a server, /About, /about, /about/, and http://about can be four different doors. If your old site treated them as the same and your new one doesn't, your tidy map covers one version and misses three.
Query strings and parameters. Faceted URLs, campaign tags, session IDs. Decide what you're honoring before launch, not while support tickets pile up.
Assets, not just pages. That whitepaper PDF ranked for something. The image someone hotlinked from a partner site still gets requests. Redirects aren't only for pages with words on them.
Test before the old signs come down
You do not want to discover a broken map from a traffic graph three weeks after cutover, because by then Google has recrawled a lot of dead ends and drawn conclusions. Test the map against a staging environment first: run your full list of old URLs and confirm each returns a single 301 to a live, 200-status destination. No chains, no loops, no 404s wearing a redirect costume. Then, right after launch, crawl the old URLs live and watch for anything returning the wrong status. The window where this is cheap to fix is measured in days.
And keep the map. Six months on, when someone asks why an old campaign link 404s, the answer lives in that spreadsheet, not in anyone's memory.
So what would I actually do
I'd treat the redirect map as the first deliverable of the migration, not the last, and I'd staff it like it matters, because it does. Build the inventory before you fall in love with the new platform. Write per-URL rules for your top pages and links by hand, pattern rules for the long tail, and test the whole thing against staging until every old exit has exactly one sign pointing at exactly one new one. It's tedious, it's unglamorous, and it's the single cheapest insurance you'll buy on the whole project.
Take down the old exit signs before the new ones are up, and you don't lose a little traffic. You lose the people who were already on their way to you.