A 301 redirect map is the list that tells every old URL where its content now lives, and the rule that decides whether your replatform keeps its traffic is almost insultingly simple: every URL that ever earned a link, a ranking, or a bookmark gets a single one-hop 301 to the closest matching new URL. That's the whole game. Teams learn it the hard way because the map they build covers the pages they can see in the CMS, and the internet has a much longer memory than the CMS does.
Here's how it usually goes. The spreadsheet is green. Every row maps to a shiny new URL, someone signs off, and everyone goes home. Three weeks after launch a report comes back with a number nobody wanted: organic sessions down a third, and holding. The map wasn't wrong. It was just answering a smaller question than the one the search engines were about to ask.
Think of it as a hotel that renumbered every room
You've just renovated the whole building. Great lobby. But you changed every room number, and guests keep arriving at the front desk with the old numbers written on their reservations. A 301 is the concierge who says, "Ah, room 214 is now room 3B, right this way," and walks them there personally. A 404 is the concierge shrugging and pointing at the door.
Now, who shows up with old room numbers? Not just the guests you emailed. The pizza delivery driver has last year's address. The taxi dispatcher. The parcel service. Every crawler, every AI answer engine, every ancient forum link, every PDF someone bookmarked in 2019. You planned for the guests. You forgot the pizza guy, and the pizza guy is Googlebot.
The rows the CMS export never shows you
Your CMS knows about its own pages. It does not know about the URLs living just outside its walls, and those are exactly the ones that quietly carry authority. A serious map is built from four sources stitched together, not from one tidy export.
You want your CMS page list, yes. But also the last twelve months of Search Console and analytics landing pages (that's what actually gets traffic), your server access logs (that's what actually gets crawled), and a fresh full-site crawl (that's what's actually linked). Overlay them and the gaps light up: the campaign URLs marketing spun up outside the CMS, the paginated archives, the old category pages you deprecated but forgot to unpublish, and every last PDF, image, and file sitting in an uploads folder that nobody has opened since the last redesign.
Those files are the suitcases left in the old rooms. They don't move themselves, and half of them are load-bearing.
One hop, not a scavenger hunt
The second thing teams learn the hard way is that redirects quietly stack. You migrated once before, so old URL A already points to B. Now B is dead too, so you point A to B and B to C, and add a trailing-slash rule and an http-to-https rule on top. Congratulations, you built a scavenger hunt. Googlebot will follow a chain, but it gives up after about ten hops in a single pass, and every extra hop bleeds a little signal and a little crawl budget on the way through.
Fix the source, not the symptom. Point A straight at C. One hop. If you're inheriting old rules, flatten the chains before you add new ones, or you're stacking concierges who each send the guest to a different floor.
Get the status code right
The map is only as good as the code the server actually returns. A surprising amount of grief comes from sending the right destination with the wrong signal.
| Code | Means | Use it when |
|---|---|---|
301 | Moved permanently; consolidate signals onto the new URL | The content lives at a new URL for good. This is your default. |
302 | Temporary; keep indexing the old URL | Genuinely short-term. During a permanent move it tells Google to keep the old room booked. |
404 / 410 | Gone | The page is intentionally killed and has no successor. Honest, and better than a fake redirect. |
200 to a generic page | Looks fine, ranks like garbage | Never on purpose. Mass-redirecting dead URLs to the homepage reads as a soft 404. |
That last row is the classic. Redirecting a thousand orphaned URLs to the homepage feels tidy and passes exactly none of the equity you were trying to save. If there's no relevant destination, let it 404. A clean dead end beats a lie.
Test it before the boxes are unpacked
Build the map against staging and run the whole old-URL list through a status checker before cutover, not after. You're looking for three things: every important old URL returns a single 301, the destination returns a 200 (not another redirect, not a 404), and the destination is actually the right room and not the lobby. Sampling a dozen rows is how the green spreadsheet happens. Check all of them, and diff the crawl again the morning after launch.
This is the unglamorous work a pre-migration crawl exists to do: reconcile the CMS list against logs, analytics, and a live crawl so the URLs living outside the walls end up on the map. You can score every page and file before the move instead of discovering them in a traffic report.
What I'd actually do
Build the map from all four sources or don't call it a map. I'd rather ship a week late with every logged and linked URL accounted for than launch on time and spend the next six months explaining a graph that points down. Redirects are not a launch-week task you bolt on at the end. They are the moving company, and if you skip them the furniture stays in the old building.
So keep the concierge on the front desk. Every guest with an old room number is someone who was already trying to reach you, and the pizza guy remembers who left him standing in the hall.