SEO Migration Checklist 2026: Don't Lose Traffic

SEO migrations have a brutal track record. Industry-wide, 50%+ of site migrations result in measurable traffic drops in the 3-6 months following launch. Many of those drops are permanent — the site never returns to pre-migration baseline. The damage comes from preventable mistakes: missed redirects, lost canonical signals, structural changes that broke crawl paths. With discipline, migrations can preserve traffic completely or even use the migration to improve it. Without discipline, multi-year traffic loss is the default.

This guide is the comprehensive migration checklist. Pre-migration prep, launch execution, post-launch monitoring.

Site migration planning meeting

Migration types and risk profile

Different migrations carry different risks:

Domain change (example.com → newexample.com): high risk. Authority transfer requires careful redirect mapping and rebuilding of brand signals.

Platform change (WordPress → Shopify → custom): medium-high risk. URL structures usually change; templates differ.

URL structure change (same domain, different URL patterns): medium risk. Redirect-heavy but contained.

Subdomain consolidation (blog.example.com → example.com/blog): medium risk. Authority transfer dynamics.

Protocol/host change (HTTP → HTTPS, www → non-www): low-medium risk if redirects done properly.

Visual/template refresh (no URL changes): lowest risk. Mostly content and rendering changes.

Plan effort proportional to risk. Domain change = 3-6 months of work; visual refresh = 2-4 weeks.

Pre-migration: weeks 1-4

Step 1: Document the current state

Before any changes, capture baseline:

Complete URL inventory (crawl with Screaming Frog or Sitebulb)
Top traffic pages from Search Console
Top ranking keywords per page
Backlink profile (Ahrefs, Semrush)
Technical SEO baseline (Core Web Vitals, schema, hreflang)
Conversion data per page
Internal linking structure
Current canonical URLs
404 errors currently present (clean up before migration if possible)

This baseline lets you measure post-migration performance accurately.

Step 2: Map URLs old → new

For every old URL, map to its new URL. Build a complete spreadsheet:

Old URL                                     | New URL                                  | Status
https://example.com/blog/post-1            | https://example.com/articles/post-1     | 301
https://example.com/category/x/post-2      | https://example.com/x/post-2            | 301
https://example.com/old-product-page       | https://example.com/products/new-page   | 301
https://example.com/deprecated             | (gone)                                  | 410

For pages with no direct equivalent, decide: 301 to closest related page, or 410 if truly removed.

Don’t redirect everything to the homepage. That’s the lazy approach that loses ranking power for every redirected page.

Step 3: Plan content preservation

Decide for each page:

Keep as-is: same content, same URL (or new URL via 301)
Update: content refresh, new URL or same
Consolidate: merge multiple pages into one
Remove: 410 or 404; not redirected

Inventory the decisions. Lost or consolidated pages need redirect targets defined.

Step 4: Technical SEO planning

For the new site, plan:

URL structure: cleaner, more logical, SEO-friendly
Page templates: SEO essentials (title, meta description, H1, schema) baked in
Schema markup: per page type, Article / Product / Organization
Hreflang (if multi-language): full bidirectional implementation
Sitemap: dynamically generated, accurate
Robots.txt: configured correctly
Internal linking strategy: hub-and-spoke patterns intact

Step 5: Staging environment

Build the new site fully in staging:

Same content as production (or near-final)
Same templates
Same schema
Same URL structures

Block search engines from indexing staging (robots.txt disallow + meta noindex).

This lets you test thoroughly before production cutover.

Pre-launch site review

Pre-launch: weeks 5-7

Step 6: Staging audit

Run full crawl of staging. Verify:

All URLs match the migration map
No unexpected URLs (orphans, parameter explosions)
Status codes correct (200 for content, 301 for redirects, 404 for not found)
Canonical tags self-reference correctly
Meta tags populated
Schema valid (test with Rich Results Test)
Page speed acceptable
Mobile rendering correct

Fix every issue before launch.

Step 7: Internal linking validation

Crawl staging to confirm:

No broken internal links
All important pages reachable in 3 clicks from homepage
No orphaned pages (pages with no incoming internal links)

Step 8: Test redirect mapping

Before launch, test redirects systematically. Sample 100 old URLs across your priority pages and verify each redirects correctly to the new URL in staging.

Automate with a script if possible. Manual spot-checking misses cases.

Step 9: 410 vs 404 vs redirect decisions documented

For pages not migrated:

410 (Gone): for permanently removed content. Google deindexes faster than 404.
404: acceptable but slower deindexation
301 to relevant alternative: usually best when a successor exists

Document the decision per affected URL.

Step 10: Backup everything

Before launch:

Full database backup
Full file system backup
Site export
Current redirect rules (if any)

Migration recovery may require restoring elements.

Launch day: week 8

Step 11: Deploy in staging-to-production manner

Best practice: cutover during low-traffic period (often late night Sunday for B2B; weekday low-hours for ecommerce).

Step 12: 301 redirects live immediately

The most critical migration element. Every old URL must 301 to its new equivalent at the moment of cutover. Not later.

Verify with a script post-launch: pull 100 random old URLs; confirm each 301s correctly.

Step 13: Sitemap submitted

Submit new sitemap to Search Console immediately.

Step 14: Robots.txt verified

Confirm robots.txt allows crawling (not the staging robots.txt with disallow rules).

Step 15: Canonical tags verified

Sample top 50 pages: confirm canonical tags point to correct new URLs.

Step 16: Search Console URL inspection

Use URL Inspection tool on top 10 pages. Confirm Google can fetch and render correctly.

Post-launch: weeks 9-24

Step 17: Daily monitoring (first 2 weeks)

Check daily:

Search Console: coverage report, errors trending
GA4: organic traffic vs. baseline
404 errors in server logs

Some traffic dip in first 2-4 weeks is normal as Google re-indexes. Beyond 15-20% drop, investigate.

Step 18: Weekly monitoring (weeks 3-12)

Watch:

Indexation status (Google indexing new URLs)
Ranking trends (top keywords)
Backlink updates (old links resolving to new URLs)
Organic conversions

Step 19: Fix issues as they surface

Common post-launch issues:

Missed redirects (404s on old URLs)
Canonical errors
Schema validation failures
Internal links pointing to old URLs

Each requires fix-and-resubmit cycle.

Step 20: Outreach for high-value backlinks

For your most important external backlinks pointing to old URLs:

301 ensures users land on new pages
But updating the link source to point at new URL preserves link equity better

Reach out to top 20-50 linking sites; ask for URL updates.

Common migration mistakes

1. No URL mapping. Migration done ad hoc; many old URLs lost.

2. Redirecting everything to homepage. Loses ranking power per page.

3. No staging environment. Bugs discovered in production.

4. Insufficient monitoring post-launch. Issues compound silently.

5. Migration during peak season. Q4 ecom migration = self-inflicted wound.

6. Underestimating timeline. Complex migrations take months; rushing means missing things.

7. Skipping the backlink update outreach. Quick effort, real impact.

8. Not maintaining old redirects long-term. Some sites turn off redirects after 12 months. Don’t — Google still benefits from them for years.

When migrations go wrong

If you see significant traffic drop (>20%) post-migration:

Diagnose:

404 errors increasing?
Indexed page count dropping?
Specific high-value pages disappeared from rankings?
Schema or technical issue site-wide?

Fix:

Restore redirect map gaps
Re-submit URLs to Search Console
Fix template-level technical issues
Re-verify canonical and schema

Recovery timeline: 30-90 days typically once issues fixed.

If specific high-value pages can’t be recovered, consider re-creating them at new URLs and rebuilding signal.

A 90-day migration plan

Weeks 1-2: Audit and inventory Weeks 3-4: URL mapping, content planning, staging build start Weeks 5-6: Staging build complete, internal testing Week 7: Pre-launch audit, stakeholder review Week 8: Launch day Weeks 9-12: Daily monitoring, issue resolution Weeks 13-24: Long-tail monitoring, backlink outreach, performance recovery validation

Tight migrations can compress to 6-8 weeks; complex migrations stretch to 6 months.

Frequently asked questions

How long until traffic recovers post-migration? 2-4 months for clean migrations; 6-12 months for problematic ones; potentially never if migration was botched.

Should I migrate during low or high season? Low season. Q4 is worst time for ecommerce migration.

Do I need to keep old redirects forever? At least 12 months, ideally indefinite. Backlinks to old URLs continue forever; redirects preserve their value.

Can I migrate gradually? Yes, gradual migration (one site section at a time) reduces risk. Takes longer total but each phase is more recoverable.

Should I hire an SEO consultant for major migration? For domain changes or large site migrations: yes. The cost ($5K-$30K typically) is small vs. cost of a botched migration.

SEO migrations are unavoidable for most growing businesses. Platform changes, rebrands, URL restructures — all happen eventually. The brands that protect their traffic during migration are the ones treating it as a multi-month project with explicit checklists, staging environments, and post-launch monitoring. The brands that improvise lose months or years of traffic. Follow the checklist; the migration becomes a routine project, not a near-disaster.