301 Redirect Mapping for Migrations: How to Not Lose Your Rankings

Executing a flawless 301 redirect mapping migration is the difference between a seamless transition and an SEO catastrophe. Let’s get it right the first time.

Why Your Redirect Map Is Your Migration’s Life Raft

Let’s be direct. A site migration is one of the most volatile events in the life of a website. Get it wrong, and you can watch years of accumulated SEO value evaporate in a matter of days. The single most critical document standing between you and that disaster is your redirect map. A proper 301 redirect mapping migration isn’t just a technical task; it’s a strategic transfer of authority.

A 301 redirect is a permanent move instruction for browsers and search engine bots. It says, ‘This page has moved for good, and all the link equity, authority, and ranking signals you associate with it should now be passed to this new URL.’ Without it, search engines see your new URLs as entirely new pages, disconnected from the history and authority of the old ones.

This guide isn’t a high-level overview. It’s a technical, no-nonsense playbook for creating, validating, and implementing a redirect map that protects your traffic. Forget the fluff; this is about preserving your rankings. For a broader view, you can consult our complete site migration SEO checklist, but here, we’re focused on the linchpin: the map itself.

Step 1: The Pre-Migration Crawl – Your Single Source of Truth

You can’t map what you don’t know exists. Before you can even think about destinations, you need a definitive, exhaustive list of every single URL on your current site. Your memory is fallible, and your sitemap is probably lying to you. Trust only the data.

Fire up your crawler of choice—we’re partial to our own ScreamingCAT, for obvious, open-source reasons—and run a complete crawl of your live domain. Don’t just crawl and export. You need to be methodical.

Your goal is to build a master list of URLs. To do this, you need to consolidate data from multiple sources to ensure nothing gets left behind. Your crawl is the foundation, but you should augment it with exports from:

• Google Analytics / Plausible: All pages that have received at least one visit in the last 12-18 months.
• Google Search Console: All pages with impressions or clicks.
• Backlink Tools (Ahrefs, Moz, etc.): All pages with external links pointing to them.
• XML Sitemaps: All URLs submitted to search engines.

Combine these lists and de-duplicate them. This master list of ‘Old URLs’ is the foundation of your entire 301 redirect mapping migration. Every URL on this list must be accounted for. No exceptions.

Step 2: Building the Ultimate 301 Redirect Mapping Migration File

With your master list of old URLs, it’s time to build the map. The format is brutally simple: a spreadsheet with two columns. Column A is ‘Source URL,’ and Column B is ‘Destination URL.’ That’s it. Don’t overcomplicate it.

The goal is to create a 1:1 mapping wherever possible. For every old URL, you must find its direct equivalent on the new site. Old product page A maps to new product page A. Old blog post B maps to new blog post B. This maintains topical relevance and provides the best user experience.

What about pages that won’t exist on the new site? You have two choices. If the page is being removed and has no relevant equivalent (and ideally, no significant traffic or backlinks), you can serve a 410 ‘Gone’ status code. If the content is being consolidated into a broader category page, redirect the old URL to that new category page. Avoid the lazy, catastrophic mistake of redirecting everything to the homepage.

# .htaccess example for individual and pattern-based redirects

# For individual 1:1 redirects
Redirect 301 /old-page.html https://www.newdomain.com/new-page/
Redirect 301 /another-old-page.html https://www.newdomain.com/another-new-page/

# For pattern-based redirects using mod_rewrite (more scalable)
RewriteEngine On
RewriteCond %{HTTP_HOST} ^olddomain.com [NC,OR]
RewriteCond %{HTTP_HOST} ^www.olddomain.com [NC]
RewriteRule ^(.*)$ https://www.newdomain.com/$1 [L,R=301,NC]

• Export URLs: Take your consolidated list of every known URL from the pre-migration crawl.
• Create a Spreadsheet: Open a new Google Sheet or Excel file.
• Populate Column A: Paste all your old URLs into the first column, labeled ‘Source URL’.
• Map Destinations: Manually, or using formulas and scripts, identify the corresponding new URL for each old one and place it in Column B, ‘Destination URL’.
• Handle Removals: For any URL that is being intentionally deleted, mark it clearly in a third column (‘Notes’) and decide if it should be a 410 or redirected to a parent category.
• Review and Sanity Check: Have a second person review the map. Typos can be devastating.

Step 3: Staging Validation – Your Pre-Launch Sanity Check

If you launch a migration without testing your redirects in a staging environment, you are gambling with your business. It’s that simple. A staging or development server that mirrors the new site structure is non-negotiable.

Once the redirects are implemented on the staging server, it’s time to validate them. Don’t just spot-check a few URLs. You must test every single redirect in your map. This is where a crawler becomes indispensable once again.

Using a tool like ScreamingCAT, you can switch to ‘List Mode,’ upload your entire list of ‘Source URLs’ from your map, and crawl them against the staging environment. The resulting report will tell you exactly what happened to each URL. You are looking for a clean report where every source URL returns a 301 status code and the final destination URL is the correct 200 OK page you specified in your map.

Step 4: Common Pitfalls and How to Sidestep Them

Even with a solid plan, migrations are fraught with peril. The difference between a veteran SEO and a novice is knowing where the landmines are buried. Here are the most common mistakes we see.

First, redirect chains and loops. This happens when Page A redirects to Page B, which then redirects to Page C. It’s inefficient and burns crawl budget. Worse is a loop, where A redirects to B and B redirects back to A. Your validation crawl should catch these. We’ve written extensively about how to find and fix redirect chains and loops.

Second, mixed content and protocol issues. Ensure your map specifies the final protocol (HTTPS). Redirecting from HTTP to a new HTTPS domain is standard, but don’t accidentally map to an HTTP version on the new site. The same goes for www vs. non-www canonicalization. Be consistent.

Finally, forgetting about non-HTML files. Images, PDFs, and other assets have URLs, too. If they have backlinks or generate traffic, they need to be mapped just like any HTML page. Your initial crawl should have picked these up; don’t ignore them during the mapping phase.

Step 5: Post-Launch Monitoring – The Job Isn’t Over

The redirects are live. The new site is up. Your job is not done. The first few weeks after a migration are a critical monitoring period. You are looking for signs of trouble before they become major problems.

Your first stop is Google Search Console. Watch the ‘Coverage’ report like a hawk for a spike in 404s (Not Found) or redirect errors. These are direct signals from Google that something is wrong with your implementation. Use the URL Inspection Tool to debug specific examples.

Next, keep an eye on your analytics. Expect some turbulence, but you shouldn’t see a catastrophic drop-off in organic traffic. If you do, segment your data to see if the drop is site-wide or isolated to specific sections. This can help you pinpoint where the redirect map might have failed.

Finally, about a week after launch, re-crawl your original list of ‘Source URLs’ against the live site. This is your final verification that all redirects are still in place and working as intended. Things can break during a push to production. Trust, but verify.

A successful migration isn’t silent. It’s loud with the sound of correct status codes, preserved rankings, and the sweet, sweet hum of a server correctly passing link equity.

The ScreamingCAT Team