Here is the whole job in one sentence: a redirect map is the change-of-address form you file for every URL you're moving, so that anyone (or any crawler) who knocks on the old address gets walked to the new one instead of a slammed door. A 301 is a permanent forward. Google has said for years that it passes link equity with no dilution. Skip it and you don't just lose a page. You lose the years of reputation that page quietly earned.
Picture the day you move house. The couch is on the truck, the keys are handed over, and somewhere out there a birthday card, three magazine subscriptions, and your tax refund are all still being sent to the old place. You didn't lose them because you did anything wrong. You lost them because you forgot to tell the post office where you went.
A CMS replatform is exactly this, except the post office is Googlebot and it does not knock twice.
Why the map, and not just "the CMS handles it"
Every platform promises redirects are trivial. They are trivial the way packing is trivial: the boxes are easy, it's remembering what's in the attic that ruins you. Your new CMS knows about the pages it was told to import. It knows nothing about the campaign landing page from 2019 that still ranks, the PDF someone linked from a government site, or the ten slightly-different URLs that all serve the same article because trailing slashes and capital letters were never anyone's job.
So the map has to be built from what the internet actually thinks your site is, not from what your CMS admits to. That means pulling old URLs from at least four places and merging them: a full crawl of the live site, your server access logs (the only source that shows URLs machines hit but no menu links to), Search Console's performance and coverage data, and your analytics for anything with real traffic in the last twelve months. XML sitemaps are a nice fifth. On their own they're the inventory the movers wrote, not the one reality kept.
The three mistakes that turn a clean move into a slow bleed
The first is the mass dump to the homepage. When you can't be bothered to map a page, it's tempting to point it at the front door. Google treats a redirect from a specific page to the homepage as a soft 404, which is a polite way of saying it ignores the forward and drops the page anyway. One-to-one, old URL to the closest new equivalent, is the only mapping that keeps the equity.
The second is the chain. You redirect A to B this year, forgetting that B already redirects to C from the last migration, and now every visitor takes a three-stop tour before arriving. Googlebot follows a limited number of hops (Google recommends keeping it under five, and stops chasing well before ten) and every hop shaves a little speed and a little trust. Flatten chains so each old URL points straight at the final destination.
The third is the silent one: case, slashes, and query strings. /About, /about, and /about/ are three doors to some servers and one door to others. If your old platform was forgiving and your new one is strict, you can 404 half your traffic without a single "broken" link in sight.
What actually forwards the mail
Not everything that looks like a redirect behaves like one. This is the part teams learn at 2am on cutover night.
| Method | What it does | Use it for a move? |
|---|---|---|
| 301 (permanent) | Server tells crawlers the page moved for good; passes equity | Yes. This is the change-of-address form. |
| 302 (temporary) | Says "back soon" — Google now passes equity but keeps indexing the old URL | No, not for a permanent move. You'll confuse everyone. |
| Meta refresh | Browser reloads after a delay; slow, unreliable for crawlers | No. |
| JavaScript redirect | Fires only if the script runs and is rendered | Last resort. Bots may never see it. |
Build it before you need it
The map is not a launch-week task. It's an inventory task, and inventory is what a pre-migration crawl exists to produce. Before you touch the new platform, you want a spreadsheet where every live URL sits in one column and its future home sits in the next, with high-traffic and high-link pages flagged so a human checks those by hand. Our own crawler scores exactly this: which pages carry enough reputation that a lazy redirect costs you real money, and which orphans and duplicates you can safely let die. You can see how we frame the whole pre-cutover pass at replatformradar.com/migrate.
Then test it against staging before go-live. Spot-check the top pages by hand. Run the whole list through a crawler that reports status codes so you catch the chains and the accidental 404s while they're free to fix. After launch, watch Search Console's coverage report for a rising tide of "not found" and treat each one as a card that got returned to sender.
So what would I actually do?
Map every URL with traffic or inbound links, one-to-one, and be ruthless about killing the rest on purpose instead of by accident. I would rather delete two hundred dead pages knowingly than forward two hundred thousand to the homepage and pretend that counts. The teams who bleed for six months after a replatform almost never skipped redirects entirely. They did a rushed 80 percent and assumed the last 20 didn't matter, and the last 20 was where the tax refund lived.
Move day is coming either way. The only question is whether the mail follows you or piles up on a porch that isn't yours anymore.