What a redirect map actually is
It's a spreadsheet. Column A: every URL on the old site that's indexed, linked, or receiving traffic. Column B: the exact new URL that content now lives at. One row per page — not per section, not "everything under /blog/ goes to the new blog," but the actual destination for the actual page. That spreadsheet then becomes the literal rule set your developer implements as server-level 301 redirects (in an .htaccess file, an Nginx config, or your host's redirect manager) at the moment the new site goes live.
It sounds almost too simple to be the difference between a smooth migration and a disaster, but in our experience running these for client sites — covered in more depth in our guide to redesigning without losing rankings — the redirect map is consistently the single highest-leverage document in the entire project.
Why 1:1 mapping beats redirecting everything home
We still see this shortcut proposed regularly, usually to save time: redirect every old URL that doesn't have an obvious new home straight to the homepage. It feels harmless. It isn't. Google's algorithm interprets a page-to-homepage redirect as a strong signal that the specific content which used to live at that URL simply no longer exists — because, from Google's perspective, it doesn't. The ranking signals, backlinks and topical relevance that page had built up get orphaned rather than transferred, and homepage relevance dilutes as dozens of unrelated old URLs all point there. We've audited sites six months post-migration where 60+ old service and blog pages were dumped onto the homepage, and organic traffic to those topics never recovered — because nothing on the new site was actually serving as page for page.
Every redirect should answer one question honestly: "if a search engine or a real visitor lands here expecting the old content, does the new destination actually satisfy that expectation?" If the answer is no, keep looking for a better match before defaulting to the homepage.
How to build the list
Pull two sources and reconcile them. First, Google Search Console's Pages and Performance reports, filtered to the last 16 months, to get every URL Google has indexed and every URL that's actually earned clicks or impressions. Second, a full crawl of the live site with a tool like Screaming Frog or Sitebulb, which catches URLs that are linked internally or externally but might not show fully in Search Console yet. Combine both lists, deduplicate, and you have your complete inventory — usually larger than most site owners expect, because old campaign landing pages, category archives and paginated listings all count.
This is exactly the same inventory step we walk through for platform moves in our Wix to WordPress migration guide — the redirect map discipline is identical whether you're changing platforms, changing URL structure, or both at once.
Redirect chains to avoid
A redirect chain happens when URL A redirects to URL B, which itself redirects to URL C — often the accumulated result of two migrations over the years without anyone cleaning up the first redirect map. Each hop adds latency, and Google's crawler will follow a limited number of chained redirects before giving up, meaning a page three hops deep might never get properly re-indexed at all. When you build a new redirect map, always resolve chains down to a single final destination: A should redirect straight to C, not to B.
How to verify it after launch
Don't assume the redirect map worked just because it was implemented — verify it. Manually visit your top 20 highest-traffic old URLs (from your Search Console benchmark) right after launch and confirm each one lands on the intended new page with a 301, not a 302 or a soft 404. Then watch Search Console's Coverage report daily for the first two weeks: a sudden spike in "Not found (404)" errors is the clearest early warning that a section of the redirect map has a gap. Catching that in week one is a five-minute fix; catching it in month three after rankings have already dropped is a much longer recovery.
Beyond Search Console, a follow-up crawl of the old URL list two to three weeks post-launch is worth the hour it takes. Feed your original URL inventory back into Screaming Frog in "list mode," pointed at the old domain, and it will report the actual status code and final destination for every single one — catching any redirect that quietly resolves to the wrong page, or one that technically works but chains through two intermediate hops before landing.
Tools and implementation
How the redirect map actually gets implemented depends on your stack. On Apache-based hosting, that's typically a set of RewriteRule entries in .htaccess; on Nginx, server block rewrite rules; on WordPress, a redirection plugin like Redirection can manage large maps through a CSV import rather than hand-editing server config. Whichever method, always use 301 (permanent) rather than 302 (temporary) redirects for a migration — a 302 tells search engines the move might not be permanent, so they hold onto the old URL's ranking signals instead of transferring them, which defeats the entire purpose of the exercise.
For sites with more than a couple hundred redirects, pattern-based rules (redirecting an entire URL structure at once, like an old /services/city-name/ pattern to a new /locations/city-name/ pattern) can replace dozens of individual rows safely — but only when the pattern genuinely holds for every URL in that set. Mixing pattern rules with individual overrides for the exceptions is normal and expected; forcing every URL into a pattern rule just to avoid writing individual rows is how gaps get introduced.