Technical SEO

How do I handle redirects during site migrations?

The step-by-step redirect playbook for a site migration: crawl every old URL, 301-map each one to its closest new match, avoid chains, update internal links, and monitor 404s — so you keep rankings instead of losing them.

By Inventive HQ Team

To handle redirects during a site migration, crawl and inventory every existing URL, map each old URL 1:1 to its closest new URL, implement those as permanent 301 redirects in a single hop (never a chain), update your internal links to point at the new URLs directly, keep the redirects in place for at least a year, and monitor Search Console and server logs for 404s. Done this way, a 301 passes essentially all of a page's ranking authority to its new address, so search engines transfer rankings to the new structure and users never notice the move.

That is the summary an AI overview will give you. What it can't give you is the sequencing and the judgment calls: which pages to map by hand versus by rule, why redirecting to the homepage quietly destroys value, how to flatten the chains a migration inevitably creates, and exactly what to watch in the weeks after cutover. Get the redirect type wrong and you are choosing between 301, 302, 307, and 308 — our redirect status-code guide covers that decision; this article is the end-to-end migration playbook that uses it.

The migration redirect playbook at a glance

Every successful migration runs the same ordered steps. Do them out of order — deploying the new site before the redirects are ready, or removing the old domain too soon — and you lose traffic that is hard to win back.

#Migration stepRedirect actionWhy it matters
1Crawl the old siteInventory every indexed URL (Screaming Frog + Search Console + analytics)You cannot redirect URLs you don't know exist; missed URLs 404 and lose their rankings
2Map 1:1Match each old URL to its single closest new URL in a spreadsheetA relevant destination passes ranking authority; homepage redirects are treated as soft 404s
3Use 301 permanentImplement every move as a 301, not a 302/307301 consolidates signals to the new URL; temporary codes keep the old URL indexed
4One hop, no chainsPoint each old URL directly at its final live URL (A → C, never A → B → C)Chains waste crawl budget, add latency, and leak signal at each hop
5Cut over & verifyDeploy redirects first, test them, then point DNS; keep a rollback planAn untested cutover can 404 the whole site during peak indexing
6Update internal linksRewrite your own links, nav, sitemaps, and canonicals to the new URLsInternal links should hit the destination in zero hops, not via a redirect
7Keep redirects long-termLeave 301s in place 1–3 years (or permanently); never remove in the first 6 monthsBacklinks and bookmarks keep hitting old URLs for years after the move
8Monitor 404sWatch Search Console + server logs for 8 weeks; submit the new sitemapCatches broken redirects, chains, and loops before they compound into ranking loss
Site migration redirect flow A request to an old URL is caught by a 301 redirect and sent in a single hop to the matching new URL, which returns a 200 OK, while a chain of stacked redirects is shown as the pattern to avoid. One hop, not a chain: how a migration request should resolve

DO — single 301 hop Old URL /old-page

301 New URL /new-page 200 OK

AVOID — redirect chain /old-page 301 /temp-page 301 /new-page wasted hops

The rest of this guide walks each step in depth — but if you remember only one rule, make it this: every old URL should return exactly one 301 to a single relevant live page, and it should keep doing so for years.

Managing Redirects During Website Migrations

Site migrations represent some of the most challenging situations in web management. Moving to new infrastructure, changing domain names, restructuring URL hierarchies, or switching content management systems all require careful redirect planning. Improperly executed migrations can devastate SEO visibility, confuse users, and damage the user experience accumulated over years. Conversely, well-planned redirects during migrations preserve ranking authority, maintain user experience, and ensure search engines successfully crawl and index the new structure.

A strategic approach to migration redirects requires understanding your current URL landscape, planning the destination structure meticulously, implementing redirects systematically, and monitoring the transition carefully. The goal is making the migration essentially invisible to users and search engines—they should seamlessly follow redirects to the new location without realizing anything changed.

Pre-Migration Planning and Audit

Audit Your Current URL Structure

Before implementing any redirects, thoroughly understand your existing site:

Inventory Current Pages:

  • Use Screaming Frog or Google Search Console to identify all indexed pages
  • Note current URL structure and patterns
  • Identify parameter usage (tracking parameters, session IDs, etc.)
  • Document any special redirects already in place

Identify High-Value Pages:

  • Pages with most organic traffic
  • Pages with most backlinks
  • Pages ranking for important keywords
  • Pages with high conversion rates

These are where migration mistakes hurt most. They deserve extra care.

Find Duplicate Content:

  • Identify multiple URLs with identical content
  • Plan consolidation (which URL should be canonical?)
  • Remove unnecessary versions post-migration

Categorize URLs by Type:

  • Homepage
  • Service/Product pages
  • Blog posts
  • Category/Archive pages
  • Special pages (about, contact, etc.)
  • Old or outdated pages (candidates for removal)

Document Your Redirect Mapping

Create a comprehensive mapping document showing where each URL will go:

Spreadsheet Template:

Old URLNew URLRedirect TypePriorityNotes
/old-product/new-product301HighTop traffic page
/article-2020/blog/updated-article301MediumOutdated article
/store/shop301HighMain category

This document becomes your implementation blueprint and post-migration reference.

Choosing Redirect Strategy

Advertisement

Strategy 1: One-to-One URL Mapping

Approach: Each old URL redirects to a specific new URL

/old-page → /new-page
/old-product → /new-product
/old-service → /new-service

Best For:

  • Similar URL structures in old and new
  • Straightforward migrations (same CMS, same domain)
  • Preserving individual page rankings
  • Content that's been updated rather than reorganized

Pros:

  • Preserves all link authority to specific pages
  • Maintains granular tracking of page-level migration
  • Users land on exact content they sought

Cons:

  • Requires creating many redirect rules
  • Time-consuming mapping and implementation
  • Difficult to manage if URL structure changes significantly
  • Might create hundreds or thousands of redirects

Strategy 2: Category-Level Consolidation

Approach: Group old URLs into broader categories

/product/old-item-1 → /products
/product/old-item-2 → /products
/product/old-item-3 → /products

Best For:

  • Consolidating outdated products/services
  • Significant restructuring
  • Removing pages that shouldn't exist post-migration

Pros:

  • Fewer redirect rules to maintain
  • Cleaner new structure
  • Useful when consolidating duplicate content

Cons:

  • Users might not find exact product/page
  • Loses some link authority (redirect to category vs. specific page)
  • Less precise tracking

Strategy 3: Hybrid Approach

Approach: One-to-one for important pages, category-level for others

/services/consulting → /consulting-services (high-traffic, one-to-one)
/services/old-product-1 → /services (low-traffic, category redirect)
/services/old-product-2 → /services (low-traffic, category redirect)

Best For: Most real-world migrations

Pros:

  • Balances preservation and simplicity
  • Protects high-value pages while simplifying low-value redirects
  • Flexible approach

Implementation Timing and Phases

Phase 1: Pre-Migration (4-6 weeks before)

Immediate Actions:

  1. Finalize URL mapping document
  2. Create new site structure
  3. Develop all content for new site
  4. Set up new hosting/infrastructure if needed
  5. Test thoroughly before migrating live

Migration Announcement:

  • Internal team communication
  • Document the timeline
  • Identify responsible parties for each component

Phase 2: Migration Cutover (1-2 days)

The Big Day:

  1. Implement all 301 redirects on old site
  2. Deploy new site on new URL structure
  3. Point DNS to new location (if changing domains)
  4. Monitor for issues throughout the day
  5. Have rollback plan ready if critical issues occur

Timing Considerations:

  • Perform migration during off-peak hours
  • Avoid launching before weekends (limited support)
  • Avoid launching before major holidays
  • Schedule maintenance windows if possible

What NOT to Do:

  • Don't launch new site before redirects are tested
  • Don't assume redirects work without verification
  • Don't launch during peak traffic hours
  • Don't migrate without having a rollback plan

Phase 3: Post-Migration Monitoring (Weeks 1-8)

Week 1: Critical Monitoring:

  • Monitor server error logs for 404 errors
  • Check Google Search Console for crawl errors
  • Verify all high-priority pages are accessible
  • Monitor traffic for unexpected drops
  • Check user feedback for issues

Weeks 2-4: Transition Period:

  • Submit updated sitemap to Google Search Console
  • Monitor rankings for key pages
  • Check that Google is crawling new URLs
  • Verify redirects processing correctly
  • Address any issues found

Weeks 4-8: Complete Recovery:

  • Monitor for full index migration
  • Check rankings stabilization
  • Plan removal of temporary redirects
  • Document lessons learned

Implementing Redirects Correctly

Server-Level Implementation

Apache (.htaccess):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.old-domain\.com$
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

# Specific URL redirects
Redirect 301 /old-page https://new-domain.com/new-page
Redirect 301 /old-product https://new-domain.com/new-product

Nginx:

server {
    listen 80;
    server_name old-domain.com www.old-domain.com;
    return 301 https://new-domain.com$request_uri;
}

location /old-page {
    return 301 https://new-domain.com/new-page;
}

Using PHP for Dynamic Redirects

If migration involves changing URL parameters or structure:

<?php
// Redirect old URL structure to new
if (isset($_GET['id'])) {
    $id = $_GET['id'];
    // Look up where this ID maps in new structure
    $new_url = lookup_new_url($id);
    header('HTTP/1.1 301 Moved Permanently');
    header('Location: ' . $new_url);
    exit;
}
?>

Using CDN Redirects

If using Cloudflare or similar CDN:

Cloudflare Rules:

URL: domain.com/old-page
Redirect to: https://domain.com/new-page
Status code: 301

Cloudflare allows bulk import of redirects via CSV for large migrations.

Handling Special Migration Scenarios

Scenario: Domain Migration

Old: example.com → New: newexample.com

Implementation:

HTTP or Server: Redirect all HTTP requests to HTTPS
Domain Redirect: Redirect all requests from old domain to new domain
Example: 301 https://example.com/* → https://newexample.com/*

Considerations:

  • Keep old domain active and redirecting for at least 1-2 years
  • Update DNS records carefully (both sites might be in DNS temporarily)
  • Ensure SSL certificates valid for both domains during transition

Scenario: URL Structure Reorganization

Old: /category/item → New: /items/category/item

Implementation:

  • Map individual old URLs to new structure
  • Can use regex rewrite rules if structure is predictable:
RewriteRule ^category/([a-z-]+)$ /items/category/$1 [R=301,L]

Scenario: CMS Migration

Old: Static site → New: WordPress/Drupal/etc.

Considerations:

  • CMS may have its own URL structure requirements
  • Consider 301-redirecting old URLs to CMS-friendly structure
  • Some CMSs have built-in redirect management tools

Scenario: HTTPS Migration

Old: HTTP site → New: HTTPS site

Implementation:

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Considerations:

  • Install valid SSL certificate before migration
  • Redirect both old domain AND HTTP/HTTPS variations

Monitoring the Migration

Google Search Console

Critical Checks:

  1. Ensure new domain/property created in GSC
  2. Upload new sitemap
  3. Monitor "Crawl Errors" for unexpected issues
  4. Watch "Coverage" to ensure pages indexed
  5. Check "URL Inspection" for specific pages
  6. Monitor "Core Web Vitals" for performance impact

Expected Timeline:

  • Immediate: First crawls of new URLs
  • 1-2 weeks: Most pages re-indexed
  • 2-6 weeks: Rankings stabilize
  • 6+ weeks: Complete transition

Server Log Analysis

What to Monitor:

  • 404 errors (broken redirects, missing pages)
  • 301 response codes (verify redirects working)
  • 500 errors (server issues)
  • Request volume changes (unexpected drops)
  • Referrer patterns (tracking user behavior)

Tools:

  • Analyze raw logs with command-line (grep, awk)
  • Use log analysis services (Splunk, ELK)
  • Platform analytics (Google Analytics, Hotjar)

Traffic Monitoring

Expected Patterns:

  • Initial dip (common during migration)
  • Recovery over 2-6 weeks
  • Return to pre-migration levels by month 2-3
  • New domain traffic gradually building

Warning Signs:

  • Traffic doesn't recover after 4 weeks
  • Specific pages losing traffic significantly
  • Bouncing between old and new domains
  • 404 errors increasing instead of decreasing

Post-Migration Cleanup

When to Remove Redirects

Timeline:

  • Keep 301 redirects minimum 1 year (ideally 2-3 years)
  • Never remove redirects in first 6 months
  • At 1-2 years, assess if redirect traffic still exists
  • Remove redirects to broken links (404s), but keep to valid pages

How to Remove:

  • Gradually transition (monitor traffic first)
  • Use 404 response instead of redirect if page truly gone
  • Or simply remove redirect rules and let browser handle 404

Post-Migration:

  • Search for all old URLs in content
  • Update internal links to point to new URLs
  • Reduces redirect chains (improves performance)
  • Can improve crawl efficiency

Tools:

  • Find & Replace in CMS
  • Custom scripts searching and updating
  • Automated tools for link fixing

Monitoring Ongoing

Ongoing Checks:

  • Monitor error logs monthly
  • Check GSC quarterly
  • Update redirect rules as needed
  • Plan redirect removal timeline

Common Migration Mistakes

1. Not Testing Redirects Before Deployment

  • Always test redirect chains before going live
  • Use redirect checker tools
  • Verify from multiple locations

2. Wrong Redirect Type (302 Instead of 301)

  • Use 301 for permanent moves
  • Temporary 302s lose ranking authority
  • Update to 301 if extending past "temporary" period
  • If you are unsure which code applies, see 301 vs 302 vs 307 vs 308

3. Redirect Chains

  • URL1 → URL2 → URL3 (bad)
  • Update to URL1 → URL3 directly (good)
  • Reduces crawl budget waste and improves performance

Chains are the single most common defect a migration introduces, because new redirects get stacked on top of redirects that were already there. Run your old URL list through a checker before and after cutover to catch chains and loops:

Loading interactive tool...

4. Not Keeping Old Domain Active

  • Removing old domain too quickly
  • Keep redirecting for 1-2 years minimum
  • Some users still have bookmarks/references

5. Insufficient Monitoring

  • Don't assume migration went smoothly
  • Monitor actively in first weeks
  • Address issues promptly before they compound

Conclusion

Successful site migrations require careful planning of your redirect strategy, meticulous implementation of redirect rules, and diligent post-migration monitoring. By conducting thorough URL audits, creating detailed mapping documents, choosing appropriate redirect strategies for your situation, and monitoring the transition carefully, you can migrate websites while preserving SEO visibility, maintaining user experience, and ensuring search engines successfully crawl and index the new structure. The effort invested in proper redirect planning and implementation pays dividends in smooth migrations with minimal traffic loss and ranking fluctuation.

Frequently Asked Questions

What redirect should I use for a site migration?

Use a 301 (permanent) redirect for essentially every URL that moves in a migration. A 301 tells search engines the move is permanent, so they transfer the old URL's ranking signals to the new URL and eventually replace the old URL in the index. A 302 or 307 signals a temporary move, so Google keeps the old URL indexed and does not fully consolidate ranking authority — the wrong choice for a migration, where the old URLs are gone for good. The only time you would reach for a 302 is a genuinely short-lived move you intend to reverse.

Do redirects hurt SEO during a migration?

A correctly implemented 301 redirect passes essentially all ranking authority to the new URL, so a well-planned migration causes little or no lasting loss. Modern Google guidance is that PageRank is not diluted by 3xx redirects. Damage comes from mistakes, not from redirects themselves: missing redirects that leave old URLs 404ing, redirect chains and loops, redirecting everything to the homepage instead of the matching page, or using temporary (302) codes. Expect a short ranking wobble for a few weeks while Google recrawls, then recovery.

How long should I keep migration redirects in place?

Keep them for at least one year, and ideally two to three, or permanently if the cost of keeping them is low. Search engines need multiple crawls to fully transfer signals and drop the old URLs, and external backlinks and bookmarks to the old URLs can keep sending traffic for years. Never remove redirects in the first six months. When you do prune, remove only redirects whose old URLs no longer receive traffic, and keep the ones that still do.

Should I redirect old URLs to the homepage?

No — redirect each old URL to the closest matching page on the new site, not to the homepage. Mass-redirecting many old URLs to the homepage is treated by Google as a 'soft 404': the redirect target is irrelevant to what the user asked for, so those redirects pass little or no ranking value and frustrate visitors. If a page has no equivalent on the new site, redirect it to the most relevant parent category, or return a proper 410 Gone if the content is genuinely retired.

What is a redirect chain and why should I avoid it?

A redirect chain is when one URL redirects to a second URL that redirects to a third (A → B → C) instead of pointing straight to the final destination (A → C). Chains waste crawl budget, add latency for every visitor, and can leak a small amount of ranking signal at each hop. During a migration they appear when you stack new redirects on top of old ones. The fix is to flatten every chain so each old URL points directly to its final live destination in a single hop.

How do I map old URLs to new URLs?

Crawl the old site (Screaming Frog, Sitebulb) and pull every indexed URL from Google Search Console and your analytics, then build a spreadsheet mapping each old URL to its single best new destination. Prioritize the pages with the most traffic and backlinks first — those are where a mistake costs the most. For predictable structural changes you can express the mapping as a regex rewrite rule instead of listing thousands of rows individually, but always spot-check the high-value pages by hand.

Will I lose rankings after a site migration?

A short-term dip is normal while Google recrawls and reindexes the new URLs, typically recovering within two to six weeks for a clean migration. A permanent loss usually signals a real problem: broken or missing redirects, chains and loops, thin or changed content on the new pages, blocked crawling (robots.txt or noindex left on from staging), or a temporary redirect type. Monitor Search Console and server logs closely for the first eight weeks and fix issues fast before they compound.

Do I need to update internal links after adding redirects?

Yes. Redirects are a safety net for external links and bookmarks you cannot edit, but your own internal links should point directly at the new URLs. Leaving internal links pointing at old URLs forces every internal click through an unnecessary redirect, wastes crawl budget, and slows pages. After the cutover, find-and-replace old URLs in your content, navigation, sitemaps, and canonical tags so internal links hit the final destination in zero hops.

How do I monitor redirects after migrating?

Watch four things for the first eight weeks: Search Console crawl-error and coverage reports for spikes in 404s or 'not indexed' pages, server logs for 404 and 5xx responses and to confirm 301s are firing, organic traffic and rankings for unexpected drops on key pages, and a redirect-checker tool to catch chains and loops. Submit the new XML sitemap immediately, and re-crawl the old URL list to confirm every one returns a single 301 to a live page.

site migrationredirectsSEObest practices