How to Create a 301 Redirect Map for Website Migrations

A 301 redirect map is the single most important artifact in any website migration. It is a spreadsheet that pairs every old URL on your existing site with the exact new URL it should point to after launch. Get it right and Google transfers the vast majority of your accumulated link equity and rankings to the new pages. Get it wrong and you wake up to a wall of 404s, evaporating organic traffic, and months of rebuilding what you already earned.

Whether you are changing domains, replatforming from WordPress to a headless stack, restructuring your URL taxonomy, or consolidating two sites into one, the discipline is the same: no old URL should ever return a 404 or 410 unless you deliberately intend it to. This companion guide walks through building a redirect map from scratch, the matching logic that keeps rankings intact, the QA that catches redirect chains, and the deployment patterns that make it all hold together. It is the checklist we run on every website migration project at eSEOspace.

Why a 301 Redirect Map Is Non-Negotiable

A 301 is a permanent server-side redirect. When a browser or search engine requests an old URL, the server responds with HTTP status 301 Moved Permanently and the location of the new page. Unlike a 302 (temporary) or a client-side JavaScript redirect, a 301 signals to Google that the move is permanent and that ranking signals should consolidate onto the destination.

• Link equity preservation: Every backlink pointing at an old URL is a vote for your site. A 301 passes that authority to the new URL. Without one, the backlink points at a dead page and the equity is lost.
• Ranking continuity: Google treats a well-implemented 301 as a strong signal to swap the old URL for the new one in its index, usually keeping positions largely intact.
• User experience: Bookmarks, email links, printed materials, and social shares keep working instead of dumping visitors on an error page.
• Crawl efficiency: Clean redirects help Googlebot discover and reindex the new structure faster, shortening the ranking-recovery window.

The cost of skipping this step is measurable. Sites that launch without a complete redirect map routinely lose 30 to 60 percent of organic traffic in the first month, and recovery can take a quarter or longer.

Step 1: Build a Complete Inventory of Old URLs

You cannot redirect what you have not catalogued. The goal here is a single deduplicated list of every URL that currently exists or has ever ranked. Pull from multiple sources because no single one is complete.

• Crawl the live site with Screaming Frog, Sitebulb, or a similar spider. Export all internal HTML URLs with 200 status codes.
• XML sitemaps: Fetch every sitemap (including nested index files) for the canonical list the site publishes.
• Google Search Console: Export the Pages report and the Performance report. GSC surfaces URLs that get impressions and clicks even if they are not linked internally.
• Analytics: Pull top landing pages from the last 12 to 16 months so you capture seasonal traffic.
• Server logs: The definitive record of what bots and users actually request, including orphaned pages no crawler finds.
• Backlink tools: Ahrefs or Semrush show which URLs external sites link to; these deserve priority protection.

Combine everything into one spreadsheet and deduplicate. Then add columns for organic clicks, number of referring domains, and internal link count so you can prioritize the pages that matter most. A page with 400 backlinks needs a hand-checked destination; a paginated tag archive with zero traffic can follow a rule.

Step 2: Map Old URLs to New URLs (The Matching Logic)

This is the analytical heart of the project. For each old URL, decide the single best new destination. The guiding principle is relevance: redirect to the closest equivalent page, not to the homepage. Bulk-redirecting everything to the root is treated by Google as a soft 404 and passes almost no equity.

Work through this decision hierarchy for every URL:

• 1:1 exact match — the page still exists with the same purpose. Map old to new directly. This covers the majority of URLs on most migrations.
• Closest equivalent — the page was merged or renamed. Point it at the most topically relevant surviving page (e.g. three thin service pages consolidated into one hub).
• Parent category — a deleted product or post with no direct replacement. Send it up one level to its category or section, never to the homepage if a more specific parent exists.
• Deliberate 410 — genuinely dead content with no value and no backlinks. A 410 Gone tells Google to drop it. Use this sparingly and only for confirmed junk.

If your URL structure follows predictable patterns, write regex or pattern-based rules for large sections (e.g. /blog/2019/(.*) to /articles/$1) and reserve manual mapping for high-value and irregular URLs. Document every rule in the map so QA can verify it. When you are replatforming and rebuilding the underlying application, coordinate the URL scheme with your development team early; our custom development work almost always starts by locking the new URL taxonomy before a single template is built.

Step 3: Structure the Redirect Map Spreadsheet

A clean, machine-readable map is what makes deployment and QA painless. Use one row per redirect with at minimum these columns:

• Old URL — the full absolute path being redirected from.
• New URL — the exact absolute destination.
• Redirect type — 301 (default), or 410/302 where intentional.
• Match confidence — exact, close, parent, or review-needed.
• Priority — driven by traffic and backlinks.
• Status — mapped, tested, live.
• Notes — rationale for non-obvious mappings.

Keep old and new URLs as absolute paths, normalize trailing slashes and protocol (always https), and force lowercase unless the platform is case-sensitive by design. Consistency here prevents the single most common migration bug: a redirect that itself needs a redirect because of a trailing-slash mismatch.

Step 4: Test the Map Before You Launch

Never trust a redirect map until you have exercised it. Ideally deploy the rules to a staging environment that mirrors production and validate against the full old-URL list.

1. Check status codes: Crawl every old URL and confirm it returns a single 301 (not 302, not 200, not 404).
2. Eliminate redirect chains: A must go straight to C, never A to B to C. Chains bleed equity and slow crawling. Flatten every multi-hop path.
3. Kill loops: Confirm no URL redirects back to itself or into a cycle.
4. Verify destinations return 200: A redirect that lands on a 404 is worse than no redirect. Crawl all new URLs too.
5. Spot-check high-value pages by hand: Manually confirm your top 50 pages by traffic and backlinks land on truly equivalent content.

Screaming Frog's list mode is ideal here: paste the old URLs, crawl, and export the response codes and redirect paths in one pass. Anything that is not a clean 301-to-200 gets flagged and fixed before go-live.

Step 5: Deploy, Then Monitor and Iterate

Where the redirects live depends on your stack. Server-level rules are fastest and most reliable: Nginx (return 301 or a map block), Apache (.htaccess RewriteRule), or platform config such as next.config.js redirects, Vercel/Netlify _redirects, or a Cloudflare Worker. Avoid meta-refresh and JavaScript redirects for SEO-critical paths; they are slower and pass equity less reliably. For large maps, a hashed lookup (Nginx map, or a redirect table in your app) outperforms thousands of sequential rule evaluations. This deployment layer is a standard part of how we handle website development and launches.

• Launch day: Deploy all redirects with the new site, submit updated XML sitemaps in Search Console, and use the URL Inspection tool to request indexing on top pages.
• Week one: Watch the GSC Pages report for a spike in Not Found errors and the Crawl Stats report for 404 responses. Add missing redirects immediately.
• Ongoing: Monitor organic traffic against the pre-migration baseline, keep the redirect map as living documentation, and hold the redirects in place for at least a year (Google recommends keeping them indefinitely).
• Update internal links: Redirects are a safety net, not a substitute. Update navigation, in-content links, and canonicals to point directly at new URLs so you are not relying on redirects internally.

A migration is not finished at launch; it is finished when organic traffic has returned to or exceeded the baseline and the 404 report is clean. A disciplined redirect map is what makes that outcome the default rather than the exception.