Site Migration Redirect Guide: Keep Your Traffic When URLs Change

Site migrations are the highest-stakes redirect scenario you will face. Whether you are moving to a new domain, changing your CMS, or restructuring every URL on your site, the redirect plan is the single factor that determines whether you keep your organic traffic or watch it evaporate.

The numbers are not encouraging. Most site migrations cause an initial traffic drop of 10 to 20 percent, and poorly planned ones can lose 50 percent or more. [1] The difference between a smooth migration and a disaster almost always comes down to the redirect mapping, the testing process, and the speed of response when something goes wrong.

This guide walks through every phase of a site migration from a redirect perspective: planning the URL map, choosing the right redirect types, testing before launch, monitoring after launch, and recovering from the mistakes that inevitably slip through.

---

Why redirects matter during a migration

When you change URLs, every existing link to your site becomes a pointer to a location that no longer exists. That includes organic search results, external backlinks from other websites, bookmarks in browsers, links in emails and documents, and internal links within your own site.

Without redirects, all of those links lead to 404 errors. Search engines lose track of your pages. Users bounce. The backlink equity you spent years building disappears overnight.

Redirects solve this by telling browsers and search engines where the old URL now lives. A properly implemented 301 redirect transfers ranking signals from the old URL to the new one, preserving your search positions and ensuring users land on the right page. [2]

What counts as a site migration

The term "site migration" covers a wide range of changes:

• Domain change: Moving from olddomain.com to newdomain.com
• Protocol change: Moving from HTTP to HTTPS
• Subdomain restructuring: Moving from blog.example.com to example.com/blog
• CMS migration: Switching from WordPress to a headless CMS, or from Shopify to WooCommerce
• URL structure change: Reorganizing your URL hierarchy (e.g., /products/shoes/nike to /nike/shoes)
• Site merger: Combining multiple sites into one domain
• Content pruning: Removing a large number of pages while keeping the rest

Each type has different redirect requirements, but the fundamental process is the same: map old URLs to new ones, implement redirects, test, launch, and monitor.

Phase 1: Pre-migration planning

The planning phase is where migrations succeed or fail. Rushing into a migration without a complete URL inventory and redirect map is the most common cause of traffic loss.

Build a complete URL inventory

Before you can map old URLs to new ones, you need a complete list of every URL that exists on your current site. Use multiple sources because no single source catches everything:

1. XML sitemap. Your sitemap is the starting point, but it only includes URLs you have explicitly added. Many sites have URLs that exist but are not in the sitemap.
2. Google Search Console. The Coverage report and the Pages report show every URL Google knows about, including ones not in your sitemap. Export the full list.
3. Web crawler. Run a crawl of your entire site using Screaming Frog, Sitebulb, or a similar tool. This catches pages linked within your site that might be missing from the sitemap and Search Console.
4. Server logs. Your access logs show every URL that has received traffic, including old URLs that might still get visits from external links.
5. Backlink data. Check Ahrefs, Moz, or Google Search Console's Links report to find URLs that have external backlinks pointing to them. These are the highest-priority URLs for redirect mapping.

Combine all sources into a single spreadsheet. Remove duplicates. You now have your master URL list.

Prioritize by value

Not all URLs are equal. Sort your master list by:

• Organic traffic: Pages that bring in search traffic are the ones where redirect mistakes cost the most.
• Backlink count: Pages with external backlinks carry equity that you want to preserve.
• Conversion value: Landing pages and product pages that drive revenue need perfect redirects.
• Internal link count: Pages that many other pages link to are structural nodes in your site.

Focus your quality assurance effort on the top 20 percent of URLs by these metrics. Spot-check the rest, but pour your attention into the pages that matter most.

Create the redirect map

The redirect map is a spreadsheet with at minimum two columns: the old URL and the new URL it should redirect to. For each old URL, determine the appropriate destination:

One-to-one mapping is ideal. If /old-page becomes /new-page, that is a clean one-to-one redirect. The content is the same (or very similar), just at a new address.

Many-to-one mapping is necessary when you are consolidating content. If three separate blog posts are being merged into a single comprehensive guide, all three old URLs should redirect to the new combined page.

No equivalent exists. This is where many migrations go wrong. If a page is being removed with no replacement, do not redirect it to the homepage. Google treats mass homepage redirects as soft 404s, which means the redirect effectively does nothing for SEO. [2] Instead:

• If similar content exists elsewhere on the new site, redirect to that page.
• If the content category still exists but the specific page does not, redirect to the category page.
• If no relevant page exists at all, return a 410 Gone status code. This tells search engines the page has been intentionally removed.

Choose the right redirect type

For site migrations, use 301 redirects for every permanent URL change. A 301 tells search engines the move is permanent and that ranking signals should transfer to the new URL.

Do not use 302 redirects for migration URLs. A 302 tells search engines the move is temporary, which means they keep the old URL in the index and do not transfer ranking signals. Some CMS platforms default to 302 redirects, so verify the actual status code being sent, not just the rule you configured.

If your migration involves API endpoints where the HTTP method matters (POST, PUT, DELETE), use 308 redirects instead of 301 to preserve the request method.

Plan your timeline

A well-structured migration timeline includes:

• 4+ weeks before launch: Complete URL inventory, begin redirect mapping
• 2-3 weeks before launch: Finish redirect map, begin implementation on staging
• 1-2 weeks before launch: Test all redirects on staging, fix issues
• Launch day: Deploy redirects, verify critical URLs, monitor error rates
• Week 1 post-launch: Daily monitoring, fix 404 spikes as they appear
• Weeks 2-4: Monitor organic traffic trends, address Search Console errors
• Months 2-3: Track search ranking recovery, resolve lingering issues
• Ongoing: Keep redirects in place indefinitely [3]

Phase 2: Implementation

With your redirect map complete, the next step is implementing the redirects on your server or platform.

Server-level implementation

Server-level redirects are the fastest and most reliable. They execute before your application code runs, which means lower latency and fewer points of failure.

For Apache servers, use .htaccess or the main server configuration. For large migrations with hundreds of URLs, use a RewriteMap directive that reads from a text file rather than creating individual RewriteRule entries. See the .htaccess redirect guide for syntax details.

For Nginx servers, use a map block for large redirect sets. This is more efficient than individual location blocks because Nginx evaluates the map once during configuration parsing. See the Nginx redirect guide for patterns.

For Cloudflare, Bulk Redirects support up to 20,000 URL-to-URL mappings per list and execute at the edge before requests reach your origin server. This makes them extremely fast. See the Cloudflare redirect guide for setup.

For WordPress, plugins like Redirection or Rank Math can handle the mapping, but be aware that these execute in PHP, which is slower than server-level redirects. For large migrations, consider implementing the redirects at the server level instead. See the WordPress redirect guide.

For Shopify, use the built-in URL redirect manager or bulk import via CSV. See the Shopify redirect guide.

Handle edge cases

Several situations require special attention during implementation:

Query parameters. If your old URLs include query strings (?category=shoes&color=red), verify that your redirect rules handle them correctly. Some servers strip query strings by default. Test with actual URLs including their full parameters.

Trailing slashes. Decide on a canonical format (with or without trailing slash) and redirect all variants to the chosen format. Mixing trailing slash conventions creates duplicate content issues.

Case sensitivity. URLs are technically case-sensitive, but users and other sites may link to your pages with different capitalization. Consider implementing case-insensitive redirect matching.

URL-encoded characters. Spaces, special characters, and non-ASCII characters in URLs get encoded (e.g., %20 for a space). Make sure your redirect rules handle both the encoded and decoded versions.

Fragment identifiers. The # portion of a URL (the fragment) is never sent to the server, so it cannot be used in server-side redirect rules. If your old site used fragment-based routing (common in single-page applications), you will need a different approach.

Avoid creating redirect chains

When implementing new redirects, check whether any destination URL is itself already a redirect. If /old-page redirects to /new-page, and /new-page already has an existing redirect to /final-page, you have created a redirect chain. Update the first redirect to point directly to /final-page.

This is especially common during second or third migrations when old redirect rules are still in place from previous URL changes. Audit your existing redirects before adding new ones. For guidance on detecting these, see how to find redirect chains.

Update internal references

Redirects are for external links and bookmarks that you cannot control. For everything you can control, update the links directly:

• Internal links throughout your site content
• Navigation menus and footers
• XML sitemap entries (submit a new sitemap with the new URLs)
• robots.txt directives (update any Allow/Disallow paths that have changed)
• Hreflang tags (update all language/region annotations to reference the new URLs)
• Canonical tags (ensure they point to the new canonical URLs)
• Open Graph and social meta tags
• Structured data and schema markup
• Email templates and marketing materials

Every internal link that points to a redirected URL is an unnecessary redirect hop that adds latency. Fix them at the source.

Phase 3: Pre-launch testing

Testing before launch catches the mistakes that are cheap to fix now and expensive to fix later.

Test on staging first

Never deploy untested redirects to production. Set up your redirect rules on a staging environment and verify them there. This means:

1. Spot-check critical URLs manually. Take the top 50 URLs from your prioritized list and test each one individually. Verify the status code is 301, the destination URL is correct, and the destination page loads properly.
2. Bulk test the full map. Use a tool or script to test every URL in your redirect map. Compare the actual destination against the expected destination. Flag any mismatches. See how to check redirects in bulk for methods.
3. Test redirect chains. Verify that no redirect leads to another redirect. Every old URL should reach its final destination in a single hop.
4. Test edge cases. Check URLs with query parameters, trailing slashes, mixed case, and encoded characters. Check both the HTTP and HTTPS versions if applicable.
5. Test 404 handling. Verify that URLs not in your redirect map return a proper 404 page (or 410 if the content was intentionally removed), not a redirect to the homepage.

Verify with different tools

Do not rely on a single testing method:

• Browser DevTools: Open the Network tab and check each request's status code and Location header. See how to check redirects in a browser.
• cURL: Use curl -I -L to follow the redirect chain and see every hop. See how to check redirects with cURL.
• Redirect tracing tools: Paste a URL and see the full chain visualized with status codes and headers.

DNS preparation

If your migration involves a domain change, prepare for DNS changes in advance:

• Lower your DNS TTL (time-to-live) values 24 to 48 hours before migration. A TTL of 300 seconds (5 minutes) means DNS changes propagate quickly. [4]
• Verify your new domain's SSL certificate is installed and working before you start redirecting traffic to it.
• Plan for DNS propagation delay. Even with low TTLs, some resolvers cache longer than they should.

Phase 4: Launch day

Launch day is about execution and rapid response. Everything should be planned and tested before this point. The launch itself should be boring.

Deployment checklist

1. Deploy redirect rules to production
2. Verify the top 20 critical URLs redirect correctly (manually, one by one)
3. Run a bulk test against the full redirect map
4. Check Google Search Console for immediate crawl errors
5. Submit the new XML sitemap to Google Search Console
6. Request re-crawl of your most important pages via URL Inspection
7. Verify robots.txt on the new site is not blocking critical pages
8. Confirm hreflang tags are updated if you have a multilingual site
9. Monitor server logs and error rates in real-time

What to watch for on day one

• Spike in 404 errors. Check your server logs and Search Console for URLs returning 404 that should be redirecting. These are gaps in your redirect map.
• Redirect loops. Users and crawlers hitting ERR_TOO_MANY_REDIRECTS means a loop exists somewhere. See what is a redirect loop and how to fix ERR_TOO_MANY_REDIRECTS.
• Redirect chains. Multiple hops where there should be one. Use redirect monitoring to catch these automatically.
• Wrong status codes. 302s where there should be 301s. Check the actual response headers, not your configuration.
• Mixed content warnings. After an HTTPS migration, any remaining HTTP resources (images, scripts, stylesheets) trigger browser warnings. See the HTTP to HTTPS redirect guide.
• Unexpected destination pages. Regex patterns in redirect rules can match URLs you did not intend. Verify that non-migrated pages are unaffected.

Phase 5: Post-migration monitoring

The first 30 days after a migration are critical. This is when problems surface and when rapid response prevents lasting damage.

Week 1: Daily monitoring

• Google Search Console: Check the Pages report daily for new crawl errors. Pay attention to 404, redirect errors, and soft 404 classifications. Google recrawls pages over days and weeks, so new errors will appear gradually.
• Organic traffic: Compare daily organic sessions to the same day in the previous period. A dip of 10 to 20 percent in the first week is normal. [1] A drop larger than 30 percent suggests redirect problems.
• Server logs: Monitor for high-volume 404s that indicate missing redirects.
• Redirect integrity: Run periodic bulk redirect checks to ensure nothing has changed since launch.

Weeks 2-4: Weekly monitoring

• Search ranking positions. Track your most important keywords. Positions may fluctuate during the first few weeks as Google reprocesses your site.
• Index coverage. Old URLs should start disappearing from Google's index as new URLs replace them. If old URLs persist for more than 4 weeks with 301s in place, investigate.
• Backlink health. Check that external backlinks are being followed through your redirects to the correct destination pages.
• Crawl budget. If you have a large site, watch for signs that Googlebot is spending excessive time following redirects instead of crawling new content. [5]

Months 2-3: Recovery assessment

Most migrations show traffic recovery within 4 to 8 weeks. [1] If traffic has not recovered by week 8:

• Audit the redirect map for missing URLs (check backlinks that are now 404ing)
• Verify no redirects are using 302 instead of 301
• Check for redirect chains that may have formed
• Look for canonical tag conflicts on the new site
• Confirm the new sitemap is submitted and being processed

Common migration failures

These are the mistakes that cause the worst outcomes. Each one has been responsible for significant traffic losses in real-world migrations.

Incomplete redirect mapping

The most common failure. URLs that exist in backlink profiles or Search Console but were missed during the inventory phase. The fix is using multiple data sources (sitemap, crawl, Search Console, backlink tools, server logs) and cross-referencing them. No single source is complete.

Redirecting everything to the homepage

When teams cannot find a good match for a deleted page, the temptation is to redirect it to the homepage. Google treats these as soft 404s and ignores them. [2] The ranking signals from backlinks to those pages are lost. Use 410 for pages with no relevant replacement.

Using 302 instead of 301

Some CMS platforms and CDNs default to 302 redirects. Others have confusing configuration interfaces where it is easy to select the wrong type. Always verify the actual HTTP response code, not just the configuration setting. For the differences, see 301 vs 302 redirects.

Removing redirects too early

Some teams remove redirects after a few months, assuming search engines have "processed" them. But external backlinks never stop arriving at old URLs. Google's own recommendation is to keep redirects in place permanently. [3] See what happens when redirects break for the consequences.

Regex errors in redirect rules

A miswritten regular expression can match URLs you never intended. One common mistake is forgetting to anchor a pattern, causing /blog to also match /blog-archive, /blogging-tips, and every other URL containing "blog." Test every regex pattern against your full URL inventory, not just the URLs you intend it to match.

Ignoring redirect chains

Migrations layered on top of previous migrations create chains. If your site was migrated once before and those old redirects are still in place, adding new redirects creates multi-hop chains. Audit existing redirects before adding new ones and collapse all chains to single hops. See redirect chains explained for how to detect and fix them.

Forgetting non-page URLs

Migrations often focus on HTML pages and forget about:

• Image URLs (which may have backlinks and appear in Google Images)
• PDF and document URLs
• RSS feed URLs
• API endpoints that third parties may call
• JavaScript and CSS files referenced by cached pages

If any of these URLs change, they need redirects too.

Not communicating the migration

If other teams, partners, or services depend on your URLs (API consumers, affiliate partners, integration endpoints), notify them before the migration. Redirects handle the transition, but direct updates to their systems are more reliable long-term.

The redirect map spreadsheet

A practical redirect map contains these columns:

| Column | Description | |--------|-------------| | Old URL | The full URL on the current site | | New URL | The full URL on the new site | | Status Code | 301 (or 410 if no redirect) | | Priority | High / Medium / Low based on traffic and backlinks | | Status | Not started / Implemented / Tested / Verified | | Notes | Any edge cases or special handling |

For large migrations, consider adding:

• Monthly organic sessions (from analytics)
• External backlink count (from Ahrefs/Moz)
• Current Google ranking for primary keyword
• Content change notes (same content, merged, rewritten, removed)

This spreadsheet becomes your single source of truth throughout the migration. Update the Status column as each redirect is implemented, tested, and verified.

Migration-specific redirect strategies

Domain change migration

When moving from old.com to new.com:

• Redirect every URL on the old domain to its equivalent on the new domain
• Keep the old domain registered and the redirects running indefinitely
• Update Google Search Console by adding the new domain as a property and using the Change of Address tool
• Expect a temporary traffic dip as Google reprocesses domain-level signals

HTTP to HTTPS migration

When adding SSL:

• Redirect every HTTP URL to its HTTPS equivalent (preserve the full path and query string)
• Update all internal links to HTTPS
• Update your sitemap with HTTPS URLs
• Add HSTS headers after confirming HTTPS works correctly
• Monitor for mixed content warnings

For the full process, see the HTTP to HTTPS redirect guide.

CMS migration

When switching platforms (e.g., WordPress to Next.js):

• URL structures often change completely. Map every old URL to the closest new equivalent.
• Old CMS-generated URLs (like /p=123 or /?page_id=456) need redirects to the new clean URLs
• Watch for platform-specific URL patterns (WordPress date-based permalinks, Shopify collection handles)
• Test that the new CMS does not create its own redirects that conflict with yours

Content consolidation

When merging multiple pages into fewer, more comprehensive pages:

• Redirect all old URLs to the consolidated page that best serves the same user intent
• If multiple old pages targeted similar keywords, the consolidated page should cover all of those topics
• Update internal links to point to the consolidated pages
• Consider adding anchor links on the consolidated page for specific sub-topics that had their own pages

Post-migration redirect monitoring strategy

One-time testing is not enough. Redirect rules can break due to server configuration changes, CMS updates, CDN rule modifications, or certificate renewals. See why one-time redirect checks are not enough for the full case.

Build ongoing monitoring into your process:

1. Automated redirect checks. Schedule bulk redirect validation weekly for the first month, then monthly thereafter.
2. Search Console monitoring. Review crawl errors weekly for at least three months post-migration.
3. Traffic monitoring. Set up alerts for significant organic traffic drops that might indicate broken redirects.
4. Backlink monitoring. Periodically check that your most valuable backlinks are still resolving to the correct pages.
5. Redirect chain monitoring. As your site continues to evolve, new chains can form. Check periodically. See redirect monitoring explained for approaches.

A solid redirect management strategy treats redirects as infrastructure that requires ongoing maintenance, not a one-time task.

Migration success checklist

Use this checklist to track your progress through each phase:

Pre-migration:

• [ ] Complete URL inventory from all sources
• [ ] Redirect map with one-to-one mappings, many-to-one mappings, and 410s
• [ ] Priority ranking of all URLs
• [ ] Timeline with milestones and responsible team members
• [ ] DNS TTL lowered (if domain change)
• [ ] SSL certificate installed on new domain (if domain change)

Implementation:

• [ ] All redirect rules deployed to staging
• [ ] Internal links updated to new URLs
• [ ] New XML sitemap created
• [ ] robots.txt updated for new URL structure
• [ ] Hreflang tags updated (if multilingual)
• [ ] Canonical tags updated

Testing:

• [ ] Top 50 critical URLs tested manually
• [ ] Full redirect map tested in bulk
• [ ] No redirect chains detected
• [ ] Edge cases tested (query strings, trailing slashes, mixed case)
• [ ] 404 handling verified for unmapped URLs

Launch:

• [ ] Redirects deployed to production
• [ ] Critical URLs verified
• [ ] New sitemap submitted to Search Console
• [ ] Change of Address filed (if domain change)
• [ ] Real-time error monitoring active

Post-launch:

• [ ] Daily Search Console checks (week 1)
• [ ] Weekly traffic comparison (weeks 1-4)
• [ ] Crawl error resolution within 48 hours
• [ ] Traffic recovery assessment (week 8)
• [ ] Ongoing redirect monitoring scheduled

---

References

1. Google, "Site moves overview," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes
2. Google, "Redirects and Google Search," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/301-redirects
3. Google, "Change page URLs with 301 redirects," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/301-redirects
4. Cloudflare, "Time to Live (TTL)," Cloudflare Learning Center. https://www.cloudflare.com/learning/cdn/glossary/time-to-live-ttl/
5. Google, "Large site owner's guide to managing your crawl budget," Google Search Central, 2024. https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget
6. IETF, "RFC 9110 - HTTP Semantics, Section 15.4: Redirection 3xx," June 2022. https://httpwg.org/specs/rfc9110.html#status.3xx
7. Ahrefs, "Site Migration Case Studies," Ahrefs Blog. https://ahrefs.com/blog/site-migration/
8. Moz, "The Ultimate Guide to Site Migrations," Moz Blog. https://moz.com/blog/the-ultimate-guide-to-site-migrations