Guide

Site Migration Guide

Last updated

A site migration is any significant change to a website’s URL structure, domain, protocol, CMS, or hosting that affects how search engines crawl and index the site. The term covers a wide range of changes — from switching HTTP to HTTPS on a single domain, to a full rebrand involving a new domain and a redesigned site architecture.

Migrations are high-risk. Done well, they are largely invisible to search engines. Done badly, they can cost months or years of ranking recovery.

Types of migration

Domain migration. Moving from one domain to another — a rebrand, a consolidation of multiple domains, or a market expansion. The highest-risk migration type.

Protocol migration. Moving from HTTP to HTTPS. Now standard, but still requires a complete redirect map and verification.

Subdomain to subfolder. Moving content from blog.example.com to example.com/blog/. Generally positive for SEO as it consolidates authority to one domain.

CMS migration. Switching platforms (WordPress to Webflow, Magento to Shopify, etc.) while keeping the same domain. Lower risk if URLs are preserved; high risk if they change.

URL restructure. Reorganising the URL hierarchy without changing domain. Common during information architecture overhauls.

Full rebuild. Domain change, CMS change, URL restructure, and redesign simultaneously. The highest-risk scenario. Avoid combining multiple migration types where possible.

Pre-migration

Baseline your current state

Before changing anything, document where you are:

  • Export all indexed URLs from Google Search Console (Coverage report)
  • Crawl the existing site with Screaming Frog or Sitebulb
  • Export current rankings for target keywords (Ahrefs, Semrush, or Search Console)
  • Document organic traffic by page in GA4
  • Record Core Web Vitals scores
  • Export all backlinks from Ahrefs or Majestic for your highest-authority pages

This baseline is what you measure recovery against. Without it, you cannot diagnose problems post-launch.

Build the redirect map

A redirect map is a document matching every existing URL to its destination on the new site. It is the single most important migration deliverable.

Rules:

  • Every URL that has ever ranked, earned links, or received meaningful traffic needs a redirect
  • Redirect to the most semantically equivalent page, not just the homepage
  • If no equivalent page exists, redirect to the closest parent category
  • Homepage is a last resort, not a default
  • Include pagination, filtered URLs with significant link equity, and RSS feeds
  • Use 301 redirects for all permanent moves

Test the redirect map against your crawl export before launch. Every URL in the crawl should have a destination.

Technical pre-checks

  • Confirm the new site is blocked from crawling during development (noindex meta tags, password protection, or robots.txt disallow — never rely on robots.txt alone for staging)
  • Verify the new site passes a technical SEO audit: no broken links, correct canonical tags, valid XML sitemap, HTTPS throughout
  • Check Core Web Vitals on the new site before launch
  • Confirm structured data is present and valid on key page types
  • Verify hreflang implementation if the site targets multiple languages or regions

Launch

The launch checklist

  1. Remove crawl blocks (robots.txt disallow, noindex, password protection) on the new site
  2. Implement all 301 redirects from old to new URLs
  3. Update the XML sitemap to reflect new URLs and submit to Search Console
  4. Update canonical tags to point to new URLs
  5. Verify HTTPS is configured correctly (no mixed content, valid certificate, HSTS enabled)
  6. Submit a change of address in Google Search Console (for domain migrations only)
  7. Update hreflang tags if applicable
  8. Notify key link partners of URL changes for high-equity backlinks

Timing

Launch on a Tuesday, Wednesday, or Thursday. Avoid Fridays — if something breaks, you want your full team available to respond. Avoid major holidays and peak trading periods.

Keep the old server live and serving redirects for a minimum of 12 months. Google needs time to recrawl and transfer signals. Decommissioning the old server early is one of the most common causes of migration-related ranking loss.

Post-migration monitoring

Immediate (first 72 hours)

  • Crawl the new site to confirm redirects are working
  • Check Google Search Console for crawl errors, coverage issues, and manual actions
  • Verify key pages are indexed on the new URLs
  • Monitor organic traffic in GA4 for unexpected drops
  • Check Core Web Vitals in Search Console

First four weeks

  • Monitor rankings daily for target keywords
  • Watch Search Console for URL discovery rate on new URLs
  • Check that Google is crawling new URLs, not just following redirects to old ones
  • Verify old URLs are dropping from the index (gradual, not immediate)

Ongoing (four to twelve weeks)

Full recovery typically takes four to twelve weeks for a well-executed migration. Rankings for individual pages may fluctuate significantly in the first two weeks before stabilising.

If traffic has not recovered to within 20% of baseline by week twelve, investigate:

  • Incomplete redirect map (orphaned old URLs with no redirect)
  • Crawl blocks on the new site (robots.txt, noindex)
  • Canonical tags pointing to wrong URLs
  • Significant content quality difference between old and new pages

Common mistakes

Redirecting everything to the homepage. A mass redirect to the homepage destroys all page-level signals and looks like a spam signal to Google. Always redirect to the equivalent page.

Decommissioning the old server too early. Any link pointing to the old domain becomes a dead end. Keep redirects live for at least 12 months, ideally 24.

Launching without a baseline. Without pre-migration data, you cannot tell whether a traffic drop is migration-related or coincidental.

Combining multiple migration types at once. Changing domain, CMS, URL structure, and design simultaneously makes it impossible to diagnose what caused a problem. Separate migration types where possible.

Not monitoring immediately post-launch. Problems identified in the first 72 hours can be fixed before Google recrawls at scale. Problems identified at week four are far more damaging.

Forgetting pagination, filters, and facets. These pages may carry link equity or ranking signals. Include them in the redirect map.

Domain migrations: change of address

For domain-to-domain migrations, submit a change of address in Google Search Console. This accelerates the transfer of signals from the old domain to the new one. Requirements:

  • You must verify ownership of both domains in Search Console
  • The change of address tool is in the old domain’s Search Console settings
  • Implement 301 redirects first, then submit the change of address
  • The tool remains active for approximately 180 days

Change of address is not a substitute for redirects — it is an additional signal on top of them.