SEO Migration Playbook 2026

An SEO migration is any site change that can alter the URLs, crawl paths, canonical signals, content, internal links, rendering, language targeting, or measurement setup search systems rely on. The safest migrations are managed as evidence projects: inventory the current site, map every important old URL to its best new destination, protect indexation signals, launch in controlled stages, and monitor recovery with Search Console, crawl data, logs, analytics, and business metrics.

The common failure is treating migration as a development release with a redirect spreadsheet attached. Search engines do not only need a new site to work. They need a stable explanation of what changed, which URLs replaced which old URLs, which pages should be indexed, which pages should be ignored, and whether users still get a better answer after the move.

Use this playbook for domain moves, replatforms, redesigns, URL restructures, HTTP-to-HTTPS migrations, CMS changes, subdomain-to-subfolder moves, ecommerce taxonomy changes, faceted navigation rebuilds, and international or hreflang migrations.

The migration risk model

Score every migration across six risk dimensions before launch.

1. URL change risk: how many indexable URLs change.
2. Content change risk: how much copy, media, template, structured data, or product data changes.
3. Crawl path risk: how much navigation, internal linking, pagination, and sitemap structure changes.
4. Signal transfer risk: how well redirects, canonicals, hreflang, and backlinks map.
5. Rendering risk: whether critical content depends on new JavaScript, hydration, personalization, or blocked assets.
6. Measurement risk: whether analytics, Search Console properties, rank tracking, log access, and conversion tracking survive launch.

Low-risk migrations change one layer at a time. High-risk migrations combine several layers: new domain, new CMS, new URL structure, new templates, new content, and new tracking. If more than two risk dimensions are high, split the release or create a rollback path.

Google's site-move documentation treats moves with URL changes as a specific class of migration, including HTTP-to-HTTPS changes, domain changes, host merges, and path changes (Google site move with URL changes). That definition is useful because it keeps the team focused on URL-level evidence, not just design acceptance.

Phase 1: scope the migration

Start with the question: what is actually changing?

Create a scope table with these columns:

• Change type: domain, protocol, path, CMS, template, content, language, rendering, tracking.
• Affected URL set: all pages, one directory, product pages, blog posts, locale folders, or parameter URLs.
• Indexation status: indexable, noindex, canonicalized, redirected, blocked, or orphaned.
• Business value: revenue, leads, traffic, links, brand, support, or legal requirement.
• SEO owner: the person who can approve the rule.
• Engineering owner: the person who can implement and test it.
• Rollback option: redirect revert, route fallback, template rollback, content restore, or no rollback.

Do not let "the whole site" be the only scope. Even whole-site migrations have priority groups: homepage, top revenue pages, top linked pages, top non-brand landing pages, product/category templates, local pages, support docs, and pages that earn AI or featured-answer visibility.

Phase 2: baseline the current site

Before changing anything, capture the evidence you will need when someone asks whether rankings are down because of the migration.

Minimum baseline:

• Full crawl of indexable and non-indexable URLs.
• XML sitemap URLs.
• Google Search Console top pages and queries for at least 16 months where available.
• GA4 or analytics landing-page sessions, conversions, and revenue.
• Backlink export for linked URLs.
• Server log sample for Googlebot and other important crawlers.
• Current robots.txt, meta robots, canonical tags, hreflang tags, structured data, status codes, and page titles.
• Rank tracking for critical query groups.
• Screenshots or rendered HTML samples for important templates.

Add a "migration critical" flag to URLs that meet any of these conditions: high revenue, high organic clicks, strong backlinks, strategic keyword, important local page, important product/category page, high AI citation or brand mention value, or legal/compliance importance.

Phase 3: build the redirect map

The redirect map is the migration's core document. Google says redirects tell users and Google Search that a page has a new location, and its redirect documentation explains that redirects are useful when moving a site to a new domain, merging sites, deleting pages, or changing URL structure (Google redirects and Search).

Build redirects with this rule order:

1. One-to-one equivalent: old page to the same topic on the new site.
2. Consolidated equivalent: multiple old pages to one stronger replacement.
3. Parent category: only when no close equivalent exists.
4. Gone or noindex: when the old page should not be replaced.
5. Homepage fallback: almost never; use only for true brand-home replacements.

Redirect map fields:

• Old URL.
• Old status code.
• Old canonical.
• Old indexability.
• Old organic clicks.
• Old backlinks.
• New URL.
• Redirect type.
• Match type: exact, consolidated, parent, gone, or temporary.
• Owner.
• QA status.
• Notes.

Avoid redirect chains, mixed protocols, redirected canonicals, redirecting removed pages to irrelevant destinations, and redirect rules that only work with trailing slash variants. Test representative rules in staging and the full export before launch.

Phase 4: canonical, noindex, robots, and sitemap controls

Redirects are not the only signal. Canonical tags, noindex tags, robots rules, and XML sitemaps must agree.

Google's canonicalization documentation says site owners can signal canonical preference through redirects, rel=canonical, and sitemap inclusion, with different strengths (Google canonicalization methods). During a migration, the new canonical page should normally point to itself, not back to the old URL. Old URLs should redirect; they should not remain indexable with conflicting canonicals unless there is a specific staged migration reason.

Use noindex carefully. Google documents that noindex prevents a page from appearing in Search when Google can crawl and see the directive (Google noindex documentation). Do not block a staging site with robots.txt and then expect Google to see a noindex tag. For staging, use authentication whenever possible. For production, remove accidental noindex before launch.

Sitemap rules:

• Pre-launch: crawl old and new URL inventories separately.
• Launch: submit sitemaps containing canonical new URLs.
• After launch: keep old URLs out of new sitemaps.
• For large migrations: split sitemaps by template or section so monitoring is easier.
• For international sites: keep hreflang alternates synchronized with canonical new URLs.

Phase 5: international and hreflang migrations

International migrations fail when language, country, and canonical signals disagree. Google's localized-versions documentation says hreflang helps Google understand localized variations of the same content, while Google uses its own algorithms to determine page language rather than relying only on hreflang or HTML lang (Google localized versions). Google's multi-regional guidance also separates language, region, and site-structure decisions (Google multi-regional sites).

For international migrations:

• Map every old locale URL to its new locale equivalent.
• Keep canonical URLs within the same language/region version unless consolidation is intentional.
• Make hreflang return links reciprocal.
• Update x-default where used.
• Avoid auto-redirecting crawlers solely by IP or Accept-Language.
• Test language selectors and local navigation as crawlable links.
• Validate hreflang in rendered HTML or XML sitemaps after launch.

If the migration changes both URL structure and locale strategy, treat it as two migrations. First prove the URL mapping works, then adjust targeting.

Phase 6: staging QA

Staging QA should test search behavior, not just page rendering.

Run this checklist before launch:

• Important old URLs have mapped new URLs.
• New URLs return 200.
• Old URLs redirect to final new URLs in one hop.
• Canonicals on new pages are self-referential or intentionally consolidated.
• No production pages carry accidental noindex.
• Robots.txt does not block important production paths.
• XML sitemaps contain only canonical new URLs.
• Navigation links use final new URLs.
• Breadcrumbs, pagination, faceted navigation, and related links work.
• Structured data is valid and still describes the visible content.
• Hreflang is reciprocal and points to final URLs.
• Critical content appears in rendered HTML.
• Analytics, consent mode, conversion events, and ecommerce events fire.
• Search Console properties are ready.
• Log access is confirmed.

For ecommerce, add product availability, price, review, canonical, variant, faceted URL, and internal search tests. For publishers, add article schema, author pages, tag pages, archive pagination, and news sitemap checks. For SaaS, add docs, pricing, comparison, integration, and changelog pages.

Phase 7: launch-day control room

Launch day should have one decision owner, one engineering lead, one SEO lead, and one analytics owner. Use a shared checklist with timestamps.

Launch sequence:

1. Freeze non-essential content changes.
2. Export final old URL crawl and redirect map.
3. Deploy new site.
4. Enable redirects.
5. Crawl top old URLs and confirm final destinations.
6. Crawl top new URLs and confirm indexability.
7. Check robots.txt, sitemap index, canonical tags, noindex tags, and hreflang.
8. Submit new sitemaps.
9. Use the Change of Address tool for supported domain moves when appropriate. Google describes the tool as a way to tell Google about a domain-level site move and recommends following the site move steps first (Search Console Change of Address tool).
10. Annotate analytics and rank tracking.
11. Start log monitoring.

Do not make cosmetic SEO changes during launch unless they are required to fix migration defects. The goal is signal continuity. If titles, content, templates, and URLs all change at the same time, diagnosis becomes much harder.

Phase 8: post-launch monitoring

Monitor in windows.

First 24 hours:

• Are important old URLs redirecting?
• Are important new URLs returning 200?
• Did robots/noindex/canonical rules survive deployment?
• Are XML sitemaps accessible?
• Is Googlebot hitting new URLs?
• Are analytics and conversion events firing?

First week:

• Search Console indexing and crawl reports.
• Log-file crawl distribution.
• Redirect errors, chains, loops, and 404s.
• Organic landing-page sessions by template.
• Branded and non-brand query groups.
• Revenue or lead pages.
• International/hreflang errors.

First month:

• Query and page recovery by cluster.
• Backlink target recovery.
• Internal-link depth changes.
• Content sections that lost impressions.
• Pages Google chose different canonicals for.
• AI-answer and video visibility where relevant.

Expect some volatility. Do not panic after one day of noisy rankings. Act quickly on technical defects; be slower with content rewrites unless the evidence shows content quality or intent mismatch.

Recovery decision tree

If traffic drops, ask these questions in order:

1. Is analytics broken?
2. Did branded demand change?
3. Did the old URL redirect to the right new URL?
4. Does the new URL return 200 and allow indexing?
5. Does the new page self-canonicalize correctly?
6. Is the content equivalent or better?
7. Is the page still internally linked from important paths?
8. Did sitemaps and hreflang update?
9. Is Googlebot crawling the new URL?
10. Did an algorithm update, seasonality shift, or SERP layout change coincide with launch?

Only after those checks should you rewrite content broadly. Many migration losses are mechanical: bad redirects, noindex leakage, blocked assets, missing internal links, incorrect canonicals, lost templates, missing structured data, or broken measurement.

AI-search and citation preservation

Migrations now affect more than blue-link rankings. If AI systems cite your old URLs, summarize your old content, or rely on brand/entity consistency, a migration can break that evidence trail.

Protect AI-search visibility by:

• Redirecting cited old URLs to equivalent new URLs.
• Keeping author, organization, product, and entity facts consistent.
• Preserving high-value answer sections and FAQs.
• Keeping raw docs, transcripts, product specs, and comparison pages available.
• Updating internal links to entity pages, about pages, and source pages.
• Monitoring branded AI prompts and citation surfaces before and after launch.

If you delete the exact passage that made a page cite-worthy, redirects alone may not preserve the answer visibility.

Common migration failures

• Launching with staging noindex still present.
• Blocking crawlers from CSS, JavaScript, images, or rendered content.
• Redirecting many old URLs to the homepage.
• Creating redirect chains through old environments.
• Canonicalizing new URLs back to old URLs.
• Forgetting image, PDF, video, or documentation URLs with backlinks.
• Changing titles, content, and URLs at the same time.
• Removing internal links to priority pages.
• Publishing sitemaps with old or non-canonical URLs.
• Breaking hreflang reciprocity.
• Losing analytics events and blaming SEO.
• Waiting weeks to inspect logs.

Executive communication template

Use this format with stakeholders:

• What changed: domain, URL, CMS, template, content, tracking, or international setup.
• Expected volatility: which templates and query groups may move first.
• Protected assets: top pages, top links, top revenue URLs, and key entity pages.
• Launch status: redirects, canonicals, sitemaps, robots, noindex, hreflang, analytics.
• First-week risks: crawl delays, redirect errors, measurement noise, unexpected canonicals.
• Decision rule: what triggers rollback, patch, or wait-and-monitor.
• Next update: the exact time and metrics for the next report.

Good migration reporting reduces panic. It also stops the team from making ten unrelated fixes before the evidence is clear.

Final checklist

Before launch, confirm:

• Every priority old URL has a mapped destination.
• Redirects are one-hop and relevant.
• New pages are crawlable, indexable, and canonicalized correctly.
• Sitemaps contain final canonical URLs.
• Robots and noindex rules match the launch plan.
• Hreflang alternates use final URLs.
• Internal links point to final URLs.
• Structured data still matches visible content.
• Search Console properties and sitemaps are ready.
• Analytics and conversions are annotated and tested.
• Logs are accessible within hours of launch.
• A rollback or patch path exists for critical defects.

An SEO migration is successful when search engines, users, analytics, and the business all agree that the new site is the rightful replacement for the old one. That does not happen by luck. It happens because the migration explains itself clearly at every URL.

FAQ

How long does an SEO migration take to recover?

Small, well-mapped migrations can stabilize quickly. Large domain, CMS, or URL-structure moves can take weeks or longer while Google recrawls, processes redirects, and settles canonical choices. Monitor by URL group instead of declaring the whole migration recovered or failed.

Should every old URL redirect?

No. Every valuable old URL needs a decision. Redirect equivalent pages, consolidate overlapping pages, return an intentional gone state for content that should disappear, and avoid homepage fallbacks for unrelated URLs.

Should I use the Change of Address tool?

Use it for supported domain-level moves after following Google's site-move steps. It is not a substitute for redirects, sitemap updates, canonical consistency, and launch QA.

Should I noindex staging?

Authentication is safer for staging. If you use noindex, make sure Google can crawl the page to see it and remove the directive before production launch. Do not rely on robots.txt to communicate noindex.

What is the most common migration mistake?

Combining too many changes at once. URL changes, content rewrites, template changes, tracking changes, and internal-link changes all affect diagnosis. Separate them where possible and preserve evidence where you cannot.