← Back to Course Index

Module 5.2 — Site Migrations

Phase 5: Advanced Specialist Topics

A site migration is one of the highest-risk activities in technical SEO. Done well, it is invisible — rankings hold, traffic continues, and users notice nothing. Done poorly, it can erase years of accumulated authority, drop organic traffic by 50–80%, and take 6–18 months to recover from. This module treats migrations as a structured engineering discipline, not a checklist you run the week before launch.

The goal is to give you a repeatable framework that works whether you are changing a domain name, moving from HTTP to HTTPS, switching platforms (e.g., WordPress to headless), restructuring URLs, consolidating multiple sites, or doing all of the above at once.

1. What Counts as a Migration?

A migration is any change that causes URLs to move, disappear, or change their identity in a way that search engines must be instructed to follow. The most common types:

These types frequently combine. A replatforming from WordPress to Payload often means a new URL structure, new hosting, and sometimes a new domain — all at once. That compounding is where migrations become dangerous.

2. The Core Principle: One Variable at a Time (When Possible)

Every migration variable you change simultaneously makes diagnosis harder. If traffic drops after a migration that changed the domain, URL structure, platform, and hosting in one weekend, you cannot isolate the cause. Where possible, phase the changes:

  1. Move to HTTPS first, separately, and confirm rankings are stable before anything else.
  2. Restructure URLs in a second phase.
  3. Change domain (if required) in a third phase.

This is not always commercially feasible, but it is always the technically safer path. When you must do everything at once, your pre-launch preparation must be proportionally more thorough.

3. Phase Overview

Every migration follows the same four phases:

4. Phase 1: Discovery & Baseline

You cannot measure the success or failure of a migration without a baseline. Run all of the following before any work begins, and store the outputs.

4.1 Full crawl of the current site

Use Screaming Frog or Sitebulb to crawl the live site. Export every URL with:

This is your source of truth for redirect mapping. Every indexed URL that will change must appear in this spreadsheet.

4.2 GSC baseline export

From Google Search Console, export:

The top-pages-by-clicks list is your priority URL list. These are the pages where a redirect failure costs real traffic. They need individual QA before launch, not batch verification.

4.3 Backlink profile

Export the full backlink profile from Ahrefs, Semrush, or Majestic. Every external link pointing to a URL that will change must be redirected. Pay special attention to:

4.4 Rank tracking baseline

Set up position tracking for your top 50–100 keyword/URL combinations before the migration. You need a pre-migration snapshot to compare against post-migration data. Without it, you are guessing about recovery.

4.5 Analytics baseline

Record the current 90-day averages for: organic sessions, organic conversion rate, and revenue from organic. These become your recovery targets.

5. Phase 2: Planning & Build

5.1 URL mapping

The redirect map is the most critical deliverable of the planning phase. It is a spreadsheet with one row per URL that changes, structured as: 

old_url | new_url | redirect_type | priority | notes

Rules for redirect mapping:

5.2 Implementing redirects

The implementation method depends on the server environment:

For large-scale migrations (10,000+ redirects), server-level or CDN-level implementation is strongly preferred over application-level, both for performance and reliability.

5.3 New site configuration checklist

Before launch, every item on this list must be confirmed on the staging environment:

5.4 Redirect QA on staging

Before launch, crawl the old site's URL list against the new staging environment to verify redirects. In Screaming Frog, use List Mode with the old URLs, pointed at the staging host, to confirm:

6. Phase 3: Launch & Signalling

6.1 Timing

Schedule the launch cutover during your lowest-traffic window, typically Tuesday–Thursday early morning in the site's primary timezone. Avoid Fridays — if something goes wrong, you need the full engineering team available to revert or fix, and a weekend with degraded rankings is harder to monitor and respond to.

6.2 Launch sequence

  1. Flip DNS / point traffic to the new server or CDN.
  2. Confirm the new site is live on the correct domain with a valid HTTPS certificate.
  3. Confirm robots.txt on the new site now allows crawling (the staging block has been removed).
  4. Verify the old domain is redirecting (spot-check 10–15 priority URLs in a browser).
  5. Submit the new XML sitemap to Google Search Console immediately.
  6. If this is a domain change, use the Change of Address tool in GSC (Settings → Change of Address). This is a direct signal to Google that the domain has permanently moved. It is only available for domain-level moves and requires the new property to be verified in GSC.
  7. Request indexing on the most important 10–20 priority URLs via the URL Inspection tool in GSC.
  8. Annotate the migration date in your analytics platform.

6.3 The Change of Address tool

Google's Change of Address tool (available in GSC under Settings for domain migrations) instructs Google to transfer PageRank and signals from the old domain to the new one faster than it would discover them organically. You must:

Google's documentation states the tool is active for approximately 180 days. Use it even if you have correctly set up all redirects — it accelerates the recrawl-and-reassign process.

7. Phase 4: Post-Launch Monitoring

The migration is not finished at launch. The weeks immediately after launch are when most migration failures become apparent, and when fast intervention can limit damage. Define a monitoring cadence:

7.1 Daily (first two weeks)

7.2 Weekly (weeks 3–12)

7.3 What normal looks like

Even a well-executed migration causes a temporary dip. Understand the expected pattern:

7.4 Common post-launch problems and their fixes

8. HTTPS Migrations Specifically

HTTP → HTTPS migrations are simpler than domain migrations but have their own failure modes:

9. Platform Migrations (CMS to CMS)

When migrating platforms — for example, from WordPress to a Payload/Next.js stack — the URL and redirect concerns above still apply in full, but there are additional SEO-critical items that change ownership:

10. Phased Rollouts

For very large sites (100,000+ URLs), a big-bang migration — switching everything at once — is high-risk. Consider a phased rollout:

Phased rollouts require careful canonical management. During a partial migration, ensure old-domain URLs that have not yet moved still have their canonicals pointing to themselves (not pre-emptively pointing to the new domain before the content exists there).

11. Migration Pre-Launch Checklist (Summary)

This is a condensed version to be used as a go/no-go gate before flipping the switch:

12. Rollback Planning

Every migration must have a defined rollback plan before the launch date. This is not pessimism — it is engineering discipline. Define:

SEO-specific note: a rollback after a domain migration that has already been live for more than a few days gets complicated — Google may already be processing the redirect signals. For this reason, domain migrations in particular must be executed with confidence. The staging QA phase is where you build that confidence.

Milestone

You are ready to move on from this module when you can do the following without consulting notes:

  1. Given a real or sample site facing a domain change + URL restructure + platform migration simultaneously, produce a complete redirect map from a Screaming Frog crawl export, with no chains, no mass redirects to the homepage, and correct handling of pages with no direct equivalent.
  2. Write the pre-launch checklist for that specific migration and identify the three highest-risk items with mitigation steps.
  3. Describe what GSC signals you would monitor in the first 14 days post-launch and define what an anomaly looks like that requires intervention.
  4. Diagnose a post-migration traffic drop given a GSC Coverage report showing a spike in 404s, and describe the exact steps to resolve it.