SEO Migration Checklist: Avoid Traffic Loss

Why Migrations Go Wrong

Every site migration—whether it’s a platform change, domain move, redesign, or URL restructuring—carries risk to organic traffic. Search engines have indexed your current site structure, URLs, content, and internal linking patterns. When those change, Google needs to reprocess everything.

In our experience managing migrations for businesses across New York, the most common causes of migration traffic loss are:

1. Missing or incorrect redirects — Old URLs returning 404 errors instead of 301 redirects
2. Content changes during redesign — Text removed or significantly altered, breaking the keyword-to-page associations Google has established
3. Technical regressions — New platform introducing crawl issues, slower page speed, or broken structured data
4. Internal linking changes — Navigation restructuring that reduces link equity flow to key pages
5. Premature launch — Going live before redirect maps, canonical tags, and sitemaps are verified

This checklist is organized into three phases: pre-migration, migration day, and post-migration monitoring.

Phase 1: Pre-Migration (4-8 Weeks Before)

Baseline Documentation

Crawl the current site completely. Use Screaming Frog, Sitebulb, or a similar crawler to capture every URL, its status code, title tag, meta description, canonical tag, and internal links. Export this data—it’s your reference point for everything that follows.

Export Search Console data. Download:

• All indexed pages (Coverage report)
• All queries and landing pages (Performance report, last 16 months)
• All internal links, external links, and sitemaps data
• Core Web Vitals data
• Any existing manual actions or security issues

Document current rankings. Track rankings for your top 50-100 keywords. Use Ahrefs, SEMrush, or STAT to establish a baseline you’ll compare against post-migration.

Record current traffic. Screenshot or export monthly organic traffic by landing page. Identify your top 50 pages by organic traffic—these are the pages you absolutely cannot lose.

Redirect Planning

Create a comprehensive redirect map. Every URL on the current site needs a destination on the new site. Map old URLs to their direct equivalent on the new site. Where no equivalent exists, map to the most relevant alternative page.

Rules for redirect mapping:

• Use 301 (permanent) redirects, not 302 (temporary)
• Map to the most specific equivalent page, not a generic catch-all
• Never redirect everything to the homepage—this is treated as a soft 404
• Avoid redirect chains (old URL → intermediate URL → final URL). Each redirect should go directly to the final destination
• Handle query parameters explicitly if your current URLs use them

Identify pages with no equivalent. If the new site structure eliminates pages that currently receive organic traffic, decide whether to:

• Create equivalent content on the new site
• Redirect to the nearest relevant page
• Accept the traffic loss (rarely advisable for pages with significant organic traffic)

Content Preservation

Audit content changes. Compare the content on your current top-performing pages with the planned content on the new site. Flag any cases where:

• Page titles are changing significantly
• H1 headings are changing
• Body content is being reduced or substantially rewritten
• Meta descriptions are missing or changed

Preserve critical on-page elements. For pages that rank well, keep these elements as close to identical as possible:

• Title tags
• H1 headings
• Key body content and terminology
• Internal link anchor text pointing to these pages

Small improvements are fine—adding content, improving structure. But removing content or changing core messaging on pages that rank well is risky without careful consideration.

Technical Preparation

Test the staging site. Before going live, the new site should be on a staging environment. Verify:

• All pages load correctly
• Robots.txt allows crawling (on the live domain—staging should block crawlers)
• XML sitemap is generated and includes all new URLs
• Canonical tags point to the correct live URLs (not staging URLs)
• Structured data is implemented and valid
• Mobile rendering works correctly
• Page speed meets or exceeds current site performance
• SSL certificate is properly configured (no mixed content warnings)
• hreflang tags are correct (for international sites)

Prepare the XML sitemap. Generate a sitemap for the new URL structure. Also prepare an updated sitemap with the old URLs temporarily, so Google can discover the redirects.

Test redirects in staging. Verify that your redirect rules work correctly before launch day. Test a representative sample covering:

• Regular pages
• Blog posts
• Category/tag pages
• Images and PDF files
• URLs with parameters
• URLs with and without trailing slashes
• HTTP and HTTPS variants

Phase 2: Migration Day

Deployment Sequence

1. Deploy the new site to production
2. Implement all 301 redirects immediately—no delay between the new site going live and redirects being active
3. Submit the new XML sitemap to Google Search Console
4. Request indexing for your most important pages via Search Console’s URL Inspection tool (limited to a handful of URLs per day)
5. Update Google Business Profile links if any URLs changed (especially for Local SEO)
6. Update robots.txt if needed—remove any staging restrictions
7. Verify canonical tags are pointing to the correct new URLs on live

Immediate Verification

Test redirects on live. Spot-check at least 50 redirects across different page types to confirm they’re working in production.

Test critical pages. Load your top 20 organic traffic pages on the new site. Verify content, title tags, structured data, and internal links.

Check for crawl errors. Use Google Search Console’s URL Inspection tool to test key URLs. Check for any immediate indexation issues.

Monitor server performance. Watch server response times during the migration. A sudden spike in 301 redirects can strain servers if not properly configured.

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

Week 1: Daily Monitoring

Crawl errors. Check Search Console daily for new 404 errors, server errors, and redirect issues. Fix critical errors immediately.

Index coverage. Monitor how quickly Google discovers and indexes your new URLs. The Coverage report in Search Console shows indexed, excluded, and error pages.

Redirect verification. Run a full crawl of your old sitemap URLs and verify that every one returns a 301 redirect to the correct destination.

Traffic comparison. Compare daily organic traffic to the same days in the previous period. Some fluctuation is normal during migration—a 10-20% dip in the first week is common even for well-executed migrations. A 50%+ drop indicates a problem.

Weeks 2-4: Weekly Monitoring

Ranking recovery. Compare current rankings to your pre-migration baseline. Rankings typically dip during migration and recover within 2-4 weeks for well-executed migrations.

Crawl budget. Monitor how frequently Googlebot crawls your new site (Search Console > Settings > Crawl stats). Ensure Google is actively discovering and processing your new URLs.

Backlink verification. Check that external links to your old URLs are being properly redirected. Major backlinks that return 404 instead of 301 represent significant lost link equity.

Search Console errors. Address any new issues flagged in Core Web Vitals, Mobile Usability, or Enhancement reports.

Weeks 4-12: Monthly Monitoring

Traffic normalization. By week 4-6, organic traffic should be returning to pre-migration levels. If not, investigate specific pages or sections that haven’t recovered.

Content performance. Compare top-page performance (traffic, rankings, conversions) against the pre-migration baseline. Identify any pages that dropped significantly and investigate causes.

Technical health. Run a full Technical SEO audit on the new site to catch any issues that weren’t apparent immediately after launch.

Common Migration Scenarios

Platform Change (e.g., WordPress to Shopify)

URL structures almost always change between platforms. Priority: comprehensive redirect mapping and preserving content on key pages. Watch for platform-specific issues like canonical tag handling, sitemap generation, and JavaScript rendering differences.

Domain Change

Domain migrations carry additional risk because link equity is tied to the old domain. Use Google’s Change of Address tool in Search Console. Keep redirects active for at least one year—ideally indefinitely. Expect a longer recovery period (3-6 months).

HTTP to HTTPS

Relatively lower risk but still requires redirects from all HTTP URLs to their HTTPS equivalents. Update internal links to use HTTPS. Update canonical tags and sitemaps. Submit the HTTPS property in Search Console.

Site Redesign (Same URLs)

The lowest-risk migration scenario if URLs don’t change. Still verify: content hasn’t been removed, internal linking structure is intact, page speed hasn’t degraded, and structured data is preserved.

When to Call for Help

If your site generates significant revenue from organic traffic and you’re planning a migration, the cost of professional SEO migration management is a fraction of the revenue at risk. A migration that goes wrong can take months to recover from—and some traffic losses from botched migrations are permanent.

Get SEO involved at the planning stage, not after the new site is built. The most expensive migration mistakes are the ones baked into the new site’s architecture before anyone checks them against SEO requirements.