Most migration disasters aren’t caused by the new platform, the new design, or the new CMS. They’re caused by a spreadsheet nobody finished. Redirect mapping — the work of deciding which old URL points to which new URL, and how — is the single highest-leverage task in any site move, and it’s the one teams routinely rush in the final week before launch. Get it right and Google transfers your rankings across in days. Get it wrong and you watch three years of accumulated equity drain into a wall of 404s that no amount of “we’ll fix it later” fully recovers.
This guide treats redirect mapping as an engineering problem with a correct answer, not a checkbox. The goal is not “redirect everything somewhere.” It’s to preserve the specific signals — links, rankings, indexed history — that each old URL carries, and to route users and Googlebot to the closest equivalent with a single clean hop.
What a Redirect Map Actually Is
A redirect map is a two-column source of truth: every crawlable old URL on the left, its destination on the new site on the right, plus the status code you’ll serve. That’s it conceptually — but “every crawlable old URL” is doing enormous work in that sentence. The failure mode isn’t mapping the pages you remember; it’s the thousand you forgot. A complete redirect map is the union of your XML sitemap, your live crawl, your top-linked pages from a backlink tool, your top-traffic pages from analytics, and your server logs. Each of those sources catches URLs the others miss.
The distinction between a redirect map and the redirects themselves matters. The map is the plan — human-reviewed, QA’d, signed off. The implementation is the server config, plugin, or edge rule that enforces it. Keep them separate: you validate the plan against the old site, then validate the implementation against the plan.
When You Need Redirect Mapping (and When You Don’t)
Not every change requires a full redirect map. You need one whenever URLs change: a domain move, an HTTP-to-HTTPS switch, a CMS replatform, a URL-structure redesign, a consolidation of two sites into one, or pruning a large section. You do not need one for a pure visual redesign that keeps every URL identical — in that case the URLs are stable and redirects would only add risk.
The trap is the “mostly the same” migration, where a team assumes 90% of URLs are unchanged and only maps the obvious movers. Trailing slashes, case sensitivity, removed category prefixes, and CMS-appended IDs quietly change more URLs than anyone expects. Crawl both the old and the staging site and diff the URL lists before deciding what “unchanged” really means.
1:1 Mapping vs Pattern-Based Rules
There are two ways to build migration redirects, and mature migrations use both. 1:1 mapping is a literal old-URL-to-new-URL pair for a specific page — precise, safe, and essential for anything that earns links or traffic. Pattern-based (regex) rules transform whole URL families at once, for example rewriting /blog/2019/post-name to /articles/post-name across thousands of URLs with one rule.
The decision rule is simple: use patterns for structural, predictable transformations across a large set, and 1:1 rules for your priority pages and every exception. The mistake is trusting a pattern blindly across a whole site — one edge case in the regex silently misroutes a slice of URLs, and because it “works” on the pages you spot-check, nobody notices until rankings slide. Every pattern rule needs its own targeted QA crawl of URLs that match it.
- Pattern rules win when: URL structure changes uniformly, volume is high, and the transformation is deterministic.
- 1:1 rules win when: the page is a link or traffic asset, the new location isn’t algorithmically derivable, or the old page is being merged into a different one.
The Closest-Equivalent Rule
For every old URL, the destination should be the closest equivalent page that exists on the new site — not the homepage, not a generic category, not a soft 404. Google has been explicit for years that redirecting a retired page to an irrelevant destination (typically the homepage) is treated as a soft 404, and the equity you were trying to preserve is lost as surely as if you’d served a hard 404.
This is where url mapping stops being mechanical. When a product is discontinued, map it to the nearest replacement or its parent category, not the storefront root. When ten thin blog posts get consolidated into one comprehensive guide, map all ten to that guide — a many-to-one redirect is legitimate and passes equity when the destination genuinely covers the same intent. Only when there is truly no relevant equivalent should you let a URL 404 (or 410) deliberately, and that should be a conscious decision, not an accident.
Choosing the Right Status Code
Redirect mapping is not just where but how, and the status code is the how. For a permanent move — which is what a migration is — serve a 301. It tells Google the change is permanent, consolidates ranking signals to the new URL, and eventually drops the old URL from the index. A 302 signals a temporary move; Google will often still pass signals but keeps the old URL as canonical, which is not what you want for a permanent migration.
A few codes are worth knowing precisely. A 308 is the strict permanent redirect that preserves the request method (relevant for non-GET requests); for standard page moves, 301 is the conventional and safe choice. Reserve 410 Gone for pages you are intentionally and permanently removing with no equivalent — it’s a cleaner signal to Google than a 404 for deliberate deletions. Never use JavaScript or meta-refresh redirects for a migration: they’re slower, less reliable to render, and pass signals inconsistently compared to a server-side 301.
Killing Redirect Chains and Loops
The most common technical defect in a live redirect map is the chain: URL A redirects to B, which redirects to C. Every extra hop wastes crawl budget, slows the user, and dilutes the signal Google passes. Chains multiply during migrations because you’re stacking new rules on top of old ones — the HTTPS redirect, the www redirect, and the migration redirect fire in sequence when they should collapse into one.
The fix is to always point the original URL directly at the final destination. If your old site already had redirects (from a previous migration), don’t map to those intermediate URLs — map to where they ultimately resolve. Before launch, crawl the full old-URL list against the new implementation and flag anything returning more than one hop, plus any loop (A to B to A), which serves users an error page and gets the URL dropped entirely.
Building the Map: A Repeatable Process
A dependable redirect-mapping workflow looks like this, in order:
- Inventory everything. Merge crawl, XML sitemaps, analytics top pages, backlink-tool top pages, and server logs into one deduplicated URL list.
- Prioritize by value. Sort by links and organic traffic so your best pages get 1:1 human attention; the long tail can lean on patterns.
- Match destinations. Apply pattern rules to structural families, then hand-map priority pages and exceptions to their closest equivalents.
- Assign status codes. 301 for moves, 410 for deliberate deletions, and flag any URL with no valid destination for a decision.
- QA against staging. Test the map on the staging environment so failures are caught before real users hit them.
- Launch, then re-crawl. Immediately crawl the old URL set against production and fix chains, loops, and stray 404s the same day.
Where Automation Fits — and Where It Doesn’t
Manual redirect mapping is punishing at scale, which is exactly why it gets rushed. The inventory step alone — reconciling five URL sources — eats days, and the post-launch QA is a task nobody wants to own once the site is “live.” This is the layer where a continuous audit earns its keep. SEO Rocket‘s real-crawler site audit surfaces the failures a redirect map is supposed to prevent — broken links, redirect chains, orphaned pages, and status-code problems — automatically and continuously, with each issue explained rather than dumped as a raw code. Instead of remembering to re-crawl after launch, you get the migration’s aftermath flagged for you, so a chain introduced by a later config change doesn’t sit undetected for months.
Be honest about the boundary, though. For the deepest work — reconciling millions of URLs from raw server logs, or bespoke regex modeling on an enterprise replatform — a dedicated desktop crawler still has a place in the workflow. The point of automation isn’t to out-crawl every specialist tool; it’s to remove the “I forgot to check” failure mode by making the audit continuous and no-setup. Pair it with rank tracking on your priority URLs and you can watch, in near real time, whether the migration held — the fastest early warning that a redirect broke something.
Monitoring the Migration After Launch
The redirect map isn’t finished at launch; it’s finished when the rankings have transferred and stabilized, which typically takes anywhere from a couple of weeks to a few months depending on site size and crawl frequency. Watch three things. In Google Search Console, monitor the Pages report for a spike in 404s (missed mappings) and use the URL Inspection tool to confirm your priority old URLs report the new URL as canonical. In analytics, watch organic landing pages for any that cratered. And re-crawl periodically, because chains have a way of reappearing whenever someone touches the server config.
Expect a short dip. Even a flawless migration usually sees a brief ranking wobble as Google re-crawls, re-renders, and re-consolidates signals to the new URLs — that’s normal and recovers. A sustained decline, especially concentrated on specific page types, points at a specific defect in your redirect mapping: a broken pattern, a chain, or a batch mapped to the wrong destination. Diagnose by page type, not site-wide, and you’ll usually find the offending rule fast.
Frequently Asked Questions
How long should I keep migration redirects in place?
Keep 301 redirects live for at least a year, and ideally permanently. Google needs repeated crawls to fully transfer signals and update its index, and external links to your old URLs never expire on their own. Removing redirects after a few months is a common self-inflicted wound — the moment they’re gone, any residual link equity and direct traffic to old URLs is lost. Redirects are cheap to keep; there’s rarely a good reason to remove them.
Can I redirect an old page to a completely different topic?
No — and this is where equity gets silently destroyed. Google evaluates relevance between the source and destination. Redirecting a page about “running shoes” to a page about “office chairs” is treated as a soft 404, and the ranking signals don’t transfer. Always map to the closest topical equivalent. If none exists, a deliberate 410 is more honest than a misleading redirect to an unrelated page.
Do redirects pass 100% of link equity?
Effectively yes for a single, relevant 301 today — Google has stated that PageRank is not diluted by 301 redirects, reversing older guidance. The losses come from the things around the redirect: chains that add hops, redirects to irrelevant pages that soft-404, and destinations that don’t match the original intent. A clean, one-hop, relevant redirect is the closest you’ll get to lossless URL mapping.
Should I map redirects to HTTPS and non-www at the same time?
Yes — consolidate all of it into a single hop. Your final destination in the redirect map should already be the canonical version: HTTPS, your preferred www or non-www host, and the correct new path. Chaining HTTP to HTTPS to www to new-path is the classic multi-hop mistake. Bake the canonical form into the map’s destination column so every old URL reaches its final home in one 301.
