Skip to main content

Site migrations

A site migration is any significant change to a website's URL structure, domain, platform, protocol, design, or content that affects how search engines crawl, index, and rank the site. Migrations are high-risk SEO events. Poorly planned migrations are one of the most common causes of severe, long-lasting organic traffic loss.

Types of site migrations​

Understanding migration type is the first step in planning:

Migration typeExampleSEO risk
Domain migrationMoving from old.com to new.comVery high — all authority must transfer via redirects
Protocol migrationHTTP to HTTPSLow-medium if implemented correctly
Platform migrationWordPress to Headless CMSMedium-high — templates, URL structure, and rendering may change
URL restructureChanging /product/shoes/ to /shoes/High — all existing URLs must redirect
Design/template migrationNew theme, no URL changesLow — mainly rendering and content concerns
Content migrationMoving content to new sectionsMedium — internal links and URL changes need management
International migrationAdding or restructuring hreflangMedium — targeting and canonical risks

Each type carries different risks and requires specific pre-launch checks.

Learning objectives​

After completing this module, you will be able to:

  • Plan SEO-safe migrations for any migration type.
  • Build URL inventories, redirect maps, and launch QA checklists.
  • Monitor post-launch performance and diagnose issues quickly.

Phase 1: Planning and baseline​

Before any migration work begins:

Baseline current performance​

Capture all performance data before changes:

  • Total organic traffic by page (from GA4 or analytics).
  • Impressions, clicks, CTR, and average position per URL from GSC.
  • Referring domains and backlinks by URL (from Ahrefs/Semrush).
  • Current indexed URL count.
  • Top-performing pages by revenue or leads.

This baseline is your post-launch comparison point. Without it, you cannot tell whether a drop is caused by the migration or by other factors.

Crawl the old site​

Export a complete URL inventory:

  • All indexed URLs (from GSC and sitemap).
  • Status codes.
  • Title tags and H1s.
  • Canonical tags.
  • Internal links.
  • Structured data.

Phase 2: URL inventory and redirect mapping​

For any migration that changes URLs, every important URL needs a redirect to its new location.

URL inventory​

Create a spreadsheet with:

  • Old URL.
  • Traffic in the last 12 months.
  • Backlinks pointing to this URL.
  • Revenue or lead contribution.
  • New URL (mapping).

Prioritize high-traffic and high-backlink URLs. These must have correct redirects before launch.

Redirect mapping rules​

  • Map old URLs to the most relevant new URL — not to the homepage.
  • A 301 redirect should go to a functionally equivalent page.
  • If no equivalent exists, redirect to the closest parent category or section.
  • Redirect to the homepage only as a last resort for truly obsolete content.
  • Avoid redirect chains — map directly from old to new final URL.

Phase 3: Staging QA​

Never launch a migration without staging QA.

Technical checks on staging​

  • Robots.txt is not set to block all on staging (common mistake: staging Disallow: / left on production).
  • Canonical tags point to production URLs (or self-referencing on staging if appropriate).
  • All redirects in the redirect map return 301 correctly.
  • Important template pages (homepage, category, product/article, contact) render correctly.
  • Structured data (schema) is present and validates.
  • Hreflang is correct for international sites.
  • Analytics tags (GA4) are firing correctly.
  • Search Console is set up for the new domain or URL structure.
  • Sitemaps are prepared and ready to submit.

Crawl the staging site​

Use Screaming Frog or Sitebulb on the staging environment (with authentication if needed) to verify:

  • No important pages return errors.
  • Redirects map correctly.
  • Canonical tags are correct.
  • No accidental noindex on important pages.

Phase 4: Launch​

Launch window​

Choose a low-traffic period:

  • Avoid Fridays and pre-holiday periods — if something breaks, you want engineering available.
  • Launch during low-traffic hours (early morning or overnight for most sites).
  • Notify key stakeholders in advance.

Launch day actions​

  1. Deploy the migration with all redirects active.
  2. Update and submit XML sitemaps to Google Search Console.
  3. Request indexing for priority URLs via URL Inspection.
  4. Verify analytics and GSC tracking is working.
  5. Validate redirect behavior from old URLs.
  6. Check robots.txt on production immediately.

Phase 5: Post-launch monitoring​

First 48 hours​

  • Monitor GSC for crawl errors and index coverage changes.
  • Check server response codes via monitoring tools.
  • Verify important pages are returning 200.
  • Review analytics for traffic patterns.

First 30 days​

  • Compare traffic by URL to pre-migration baseline.
  • Monitor GSC for indexation of new URLs.
  • Check that backlinks pointing to old URLs are resolving correctly.
  • Review log files for unexpected Googlebot behavior.
  • Fix any redirect errors discovered.

Rollback planning​

Before launch, document a rollback plan. If traffic drops sharply in the first 24–48 hours due to a technical error:

  • What is the decision threshold for rollback?
  • Who has authority to approve rollback?
  • What are the steps to revert?

Not all drops require rollback — some are normal fluctuation. But having a plan prevents panic decisions.

Checklist​

  • URL inventory is complete for all important pages.
  • Redirect map is reviewed and covers high-traffic and high-backlink URLs.
  • Staging has been crawled and QA'd against the checklist.
  • Analytics and GSC verification is complete before launch.
  • Post-launch monitoring owner is assigned with a daily review cadence.

Measurement​

MetricWhat it tracks
Organic traffic by page (pre vs post)Traffic impact by URL and section
Indexed URL countMigration of index to new structure
Redirect acceptance rate in GSCAre new URLs replacing old ones in the index?
Crawl errors in GSCTechnical problems found post-launch
Backlink redirect resolutionLink equity passing through redirects
Ranking stability for priority keywordsLong-term recovery signal

Common mistakes​

Launching without a complete redirect map. High-traffic URLs without redirects lose organic traffic immediately. The redirect map is the single most important migration deliverable.

Accidentally leaving staging robots.txt rules on production. This is a frequent disaster: Disallow: / in robots.txt blocks all crawling. Always verify robots.txt immediately after launch.

Changing URLs unnecessarily. URL changes introduce risk. If a URL is performing well and there is no strong architectural reason to change it, do not change it. Prioritize stability.

Not capturing baseline performance data. Without baseline data, you cannot distinguish migration-caused drops from pre-existing trends or seasonal changes.

Making multiple changes at once. Combining a platform migration, URL restructure, and design refresh in one launch makes diagnosing problems nearly impossible. Stage changes where possible.