Technical SEO · Part 13

Site Migration SEO Checklist: Domain Changes, Redesigns & URL Moves

~17 min read Updated 2026-06-24 MagicSEO Editors · Human Reviewed Practical Guide

Site migration is one of the riskiest operations in technical SEO: changing domains, redesigning, restructuring URLs—one mistake can evaporate years of accumulated rankings and traffic overnight. But with thorough preparation and rigorous process, migrations can be completed smoothly. This article ties together the entire Technical SEO section, giving you a complete migration checklist from prep to wrap-up—and serves as the finale of this section.

Migration Types#

"Site migration" is a broad term—different types carry different risks and priorities. First, identify which type you're doing (often multiple combined):

Migration TypeWhat ChangesRisk Level
Domain ChangeDomain changes, URL paths stay sameMedium (simple mapping but site-wide)
HTTP → HTTPSProtocol changeLow (see HTTPS Migration)
URL RestructurePath/level changesHigh (complex mapping, easy to miss URLs)
Redesign/RebuildDesign, templates, content structure changesHigh (content and signals both change)
Platform/CMS ChangeUnderlying platform replacementHigh (rendering, URLs, features all change)
Merge/Split SitesMultiple sites into one, or one into manyVery High (multiple signal reorganizations)
Fewer Changes = Less RiskIf you can change one thing at a time, don't stack domain change, redesign, URL restructure, and platform replacement all together. With multiple overlapping changes, if rankings drop, you'll struggle to identify which element caused the problem. For major migrations, stage them—complete and verify one type of change before proceeding to the next.

Pre-Migration: Preparation#

Migration success is 80% preparation. Before taking action, complete these steps:

  1. Full crawl of existing site: Use tools like Screaming Frog to crawl all URLs, status codes, titles, meta descriptions, and canonicals—save as a baseline snapshot.
  2. Identify important pages: Combine GSC and analytics data to list high-value pages that drive traffic and rankings—prioritize protecting them.
  3. Export backlink data: Use backlink tools to export links pointing to your site; identify which pages are link targets—after migration, these URLs must have destinations.
  4. Record baseline metrics: Document pre-migration traffic, rankings, index count, Core Web Vitals—your reference for post-migration comparison.
  5. Prepare staging environment: Build the new site in staging, protecting it with noindex or access control to prevent indexing (see Crawling & Indexing).
Don't Let Staging Get IndexedIf your staging environment gets crawled and indexed by search engines, it creates duplicate content with your live site and can even hijack rankings. Protect staging with HTTP basic auth or noindex. But remember: at launch, remove these noindex blocks—otherwise your live site won't get indexed either. This is the most classic migration failure.

Core: URL Mapping & 301s#

This is the heart of the entire migration. Every old URL must have a clear destination, pointed via 301 permanent redirect one-to-one to the new URL.

url-mapping.csv
Old URL                          New URL                         Type
/old-blog/seo-tips             /articles/seo-tips             301
/products/shoes.php?id=5       /shop/shoes/running            301
/about-us.html                /about                         301
/discontinued-product         /shop/category                 301  (no exact match→related page)

Key mapping principles:

  • One-to-one, use 301: Permanent migration requires 301 (not 302) to transfer signals to the new URL—see HTTP Status & Redirects.
  • Map to most relevant page: When no exact match exists, redirect to the most relevant page (such as a related category)—don't redirect everything to homepage—that's treated as a soft 404.
  • Avoid redirect chains: Old URL should reach the final new URL in one hop—no A→B→C.
  • Really no equivalent content: If content is permanently deleted with no replacement, let it return 404/410—don't force a redirect.
  • Cover backlink targets: All old URLs with external links must be in your mapping table to preserve equity.

Migration Day#

Choose a low-traffic period and have a rollback plan ready. At launch, verify each item:

  1. Deploy 301 redirects: Enable all redirects per your mapping table.
  2. Remove staging protections: Delete staging-phase noindex and robots blocks—ensure new site is crawlable and indexable.
  3. Update canonicals: All pages' canonical should point to the new URL itself.
  4. Update internal links: Internal links should point directly to new URLs, not rely on redirect hops.
  5. Update and submit new sitemap: New sitemap should contain only new URLs—submit to GSC.
  6. Update robots.txt: Verify nothing is incorrectly blocked; Sitemap URL points to new domain.
  7. Check hreflang: For multilingual sites, update hreflang to new URLs.
  8. GSC Change of Address: For domain changes, use the Change of Address tool in GSC once both old and new properties are verified.
  9. Update third-party: Analytics tools, ads, CDN, API callbacks, social profiles pointing to new domain.
Post-launch spot checks
# Verify old URL 301s to new URL in one hop
$ curl -IL https://old-domain.com/old-page
HTTP/2 301
location: https://new-domain.com/new-page
HTTP/2 200

# Verify new page returns 200, canonical points to self, no noindex

Post-Migration: Monitoring & Fixes#

Launch isn't the end—it's the start of monitoring. For weeks to months post-launch, watch closely:

  • Crawling & indexing: In GSC, observe new URL indexing progress and old URL drop-off; watch for anomalies like "Crawled - Not Indexed" or "Redirect Error".
  • 404 spikes: If Coverage Report shows many 404s, your mapping has gaps—add corresponding 301s immediately.
  • Redirect issues: Hunt down redirect chains, loops, and misplaced 302s.
  • Rankings & traffic: Compare against pre-migration baseline—minor fluctuation is normal; sustained significant decline means investigate immediately.
  • Crawl stats: Monitor Googlebot crawl volume and error rates—confirm server stability.
  • Core Web Vitals: Ensure new site performance meets thresholds—optimize if needed (see Site Speed).
Patience: Fluctuation is NormalPost-migration, Google needs time to recrawl, process redirects, and transfer signals—temporary ranking and traffic swings are common, typically recovering within weeks to months. Don't panic and make repeated changes due to short-term drops—that only creates more instability. Keep monitoring, and only fix genuine errors.

Keep Redirects Long-Term#

A critical afterthought often overlooked: 301 redirects must be kept long-term—don't remove them after migration completes.

  • Google needs time to transfer signals and fully update its index—removing redirects too soon aborts this process.
  • External links pointing to old URLs will persist for a long time—once redirects are removed, these links turn into 404s, wasting their equity.
  • Recommendation: Keep redirects for at least one year. For domain changes, retain ownership of the old domain and maintain redirects as long as possible—keep them if you can.

Complete Migration Checklist#

Pre-Migration

  • Full crawl of old site, save URL/status/meta baseline
  • Inventory high-value pages and keywords
  • Export backlink data, mark backlink target URLs
  • Record traffic, rankings, index count, CWV baseline
  • Build protected staging environment (noindex/auth)
  • Create complete old→new URL mapping table

Migration Day

  • Choose low-traffic window, prepare rollback plan
  • Deploy all 301s (one-to-one, no chains, no loops)
  • Remove staging noindex / robots blocks
  • Canonical, internal links point to new URLs
  • Submit new sitemap, update robots.txt
  • Update hreflang (for multilingual sites)
  • GSC verify new property + use Change of Address
  • Update analytics/ads/CDN/third-party configs
  • Spot-check redirects and new page status codes

Post-Migration

  • Monitor indexing progress and crawl errors
  • Fix 404 spikes, complete missing mappings
  • Hunt redirect chains/loops and incorrect 302s
  • Track rankings and traffic against baseline
  • Monitor CWV and server stability
  • Keep 301s long-term (minimum one year)

This Site & Migration#

This Site ExampleMagicSEO's stable, semantic URL structure (see URL Structure) is designed specifically to minimize future migrations—URLs are tied to content topics, free from dates or IDs, so they don't need changing after publication. If adjustments become necessary, the clear hierarchy makes URL mapping straightforward. This reinforces the core principle of this section: building technical foundations correctly from the start saves extensive remediation later.
Technical SEO Section CompleteThis is the final article in the Technical SEO section. From Crawling & Indexing, robots.txt, sitemap, to canonical, HTTPS, HTTP Status & Redirects, and now site migration—together they form the technical foundation of search visibility. Solid foundations enable content SEO and off-site efforts to truly deliver results.

Frequently Asked Questions#

Do rankings always drop after a site migration?

Properly executed migrations typically only see short-term, minor fluctuations that recover within weeks to months—there should be no long-term loss. Google needs time to recrawl, process redirects, and transfer signals, so temporary ranking and traffic fluctuations during this period are normal. What causes permanent loss are errors: missing or incorrect redirect types, omitted URL mappings, major content changes, forgetting to migrate backlinks, etc. Thorough preparation, complete mapping, and diligent monitoring minimize risk.

How long should I keep redirects from the old domain?

At least one year, longer if possible (many recommend permanent or multi-year retention). Google takes time to transfer signals and update its index, and external links pointing to old URLs may persist long-term. Removing 301 redirects too early turns these old links into 404s, losing their equity. When feasible, maintain ownership of the old domain and keep redirects active indefinitely.

Should I migrate the entire site at once or in stages?

Depends on site size and migration type. Pure domain changes (URL paths unchanged) typically can be done all at once since mapping is straightforward. But when multiple changes are involved—major URL restructuring, content reorganization, platform change—risks compound; staging the migration is recommended. Complete one type of change, verify stability, then proceed to the next, making it easier to isolate problems if something goes wrong. Regardless of approach, operate during low-traffic periods and have a rollback plan ready.

What should I do in Search Console during a migration?

For domain changes, use Search Console's Change of Address tool to notify Google, provided both old and new domains are verified in GSC. Also verify the new site property, submit the new sitemap, and check the Coverage report and crawl stats. Post-migration, continuously monitor index status, crawl errors, 404s and redirect issues, fixing promptly. GSC is the most critical monitoring tool during migrations.