Site Migration SEO Playbook

Updated 2026-09-06 · guide · SEO, site migration, redirects, technical SEO

A safe site migration protects existing demand while improving the platform, design, domain, or information architecture. Treat migration as controlled change management, not a launch-day DNS task. Inventory every URL, map each destination, test rendering and conversion on staging, freeze changes, run a checklist cutover, then monitor crawl, index, rankings, conversions, and errors daily.

This playbook covers discovery, redirect design, staging tests, governance, cutover, rollback, monitoring, and recovery. It is written for AI product sites, service businesses, documentation hubs, and content-heavy platforms where losing organic demand has direct revenue consequences.

Define migration type and success criteria

Different migration risks need different controls.

Common migration types

Scope statement

• Domain migration.
• Protocol or subdomain change.
• Platform or CMS migration.
• Replatforming or framework rewrite.
• IA and URL structure redesign.
• Content consolidation.
• Brand merge or product split.
• International site restructuring.
• Hosting or CDN change.
• Headless architecture migration.

Write a one-page scope before work begins:

• Migration type.
• Business goal.
• In-scope properties and locales.
• Out-of-scope properties.
• URL change level: none, partial, or full.
• Design change level.
• Data and integration changes.
• Freeze window.
• Success threshold.
• Rollback trigger.
• Owner for each workstream.
• Communication plan.

A migration fails more often from unclear scope than from one bad redirect.

Build the source inventory

You cannot protect what you cannot see.

Inventory sources

Collect and reconcile:

• XML sitemaps.
• Crawl of the current site.
• Search Console pages and queries.
• Log-file evidence.
• Analytics landing pages.
• Internal search queries.
• Backlink link tables.
• CMS exports.
• Docs navigation and redirects.
• App deep links and email links.
• Paid landing pages.
• PDFs and downloadable assets.
• Legacy domains and subdomains.
• Staging or UTM archives.
• Print, packaging, contracts, and offline URLs.

Deduplicate by normalized URL, then classify by:

Define priority tiers

• Organic sessions and conversions.
• Search impressions and clicks.
• Backlinks.
• Internal links.
• Revenue or inquiry influence.
• Strategic importance.
• Content freshness.
• Migration risk.
• Destination exists or needs creation.
• Tier 1: top revenue, inquiry, traffic, or conversion paths.
• Tier 2: mid-demand docs, integrations, comparisons, and support pages.
• Tier 3: valid long-tail assets.
• Tier 4: noindex, expired, duplicate, spam, or low-value pages to remove or consolidate.

Priority tiers determine test depth and cutover order.

Create a destination architecture

Do not map old chaos onto new chaos.

Destination design rules

Content disposition

• Keep valuable URLs unchanged when possible.
• Use one canonical URL per content item.
• Remove duplicate parameter paths.
• Create category and topic structure around demand.
• Preserve language and region logic.
• Keep docs versions and changelog accessible.
• Separate product, docs, blog, community, and support paths.
• Avoid unnecessary pagination and filter URLs.
• Make key conversion pages reachable in one or two clicks.
• Ensure every valuable old page has an actual new home.

For each source URL, choose:

1. Keep URL: no redirect needed.
2. Redirect: one relevant destination.
3. Merge: consolidate into a stronger page.
4. Split: move sections to separate pages.
5. Noindex: useful for signed-in users only.
6. Remove: no user or business value.
7. Create: destination needed but missing.

Record the reason. Do not use redirects to hide missing content.

Build and test the redirect map

Redirects are the migration contract.

Redirect map columns

At minimum include:

Redirect rules

Test the map

• Source URL.
• Destination URL.
• Status code.
• Match type: exact, path, wildcard, computed.
• Priority tier.
• Owner.
• Reason.
• Last tested date.
• Result.
• Exception handling.
• Launch state.
• Post-launch state.
• Use 301 for permanent moves.
• Use 302 only for genuinely temporary changes.
• Redirect to equivalent content, not the homepage.
• Avoid redirect chains and loops.
• Keep one hop wherever possible.
• Do not redirect blocked URLs into a canonical target.
• Do not send all removed pages to the homepage.
• Preserve lowercase and trailing-slash rules.
• Document wildcard exceptions before broad rules.
• Protect top backlink and conversion URLs first.
• Keep old domains redirecting for as long as the business owns the equity.
• Add monitoring for new 404s.

Before launch:

• Test every Tier 1 URL.
• Sample every redirect pattern.
• Test every locale and protocol combination.
• Test with and without query strings where valid.
• Test uppercase, lowercase, trailing slash, and encoded characters.
• Check final status code and final URL.
• Confirm canonical on the final destination.
• Confirm page render and primary CTA.
• Confirm tracking and schema on destination.
• Measure redirect depth.
• Check loops and wildcard overrides.

A redirect map is not done because it was exported. It is done because it was tested.

Protect crawl, index, and canonical integrity

Search engines need an unambiguous new environment.

Pre-launch checks

• Remove noindex from production-ready pages.
• Remove staging canonicals and disallow rules.
• Confirm production robots.txt.
• Confirm XML sitemaps include final URLs.
• Submit new sitemaps after cutover.
• Verify both old and new properties in Search Console.
• Validate canonical tags across templates.
• Validate hreflang and self-canonicals.
• Check pagination and filtered paths.
• Confirm internal links use final URLs.
• Remove temporary placeholders.
• Confirm JavaScript rendering and server responses.
• Ensure structured data matches visible content.
• Confirm AI crawler policy deliberately.

Do not rely on redirects alone. Internal links and sitemaps should point to final destinations.

Test staging against the real success path

A page can return 200 and still fail the business.

Functional and SEO tests

For each template and Tier 1 page, test:

Conversion tests

• Server status.
• Rendered content.
• Title and description.
• Canonical URL.
• Hreflang.
• Structured data.
• Internal links.
• Images and media.
• Forms.
• Authentication.
• Search.
• Checkout or trial path.
• Demo or intake path.
• Localization.
• Analytics events.
• Consent behavior.
• Error states.
• 404 and 410 pages.
• Search and filter behavior.
• API calls that populate content.

Complete at least one full path per buyer stage:

• New visitor to trial.
• Technical buyer to docs and sandbox.
• Enterprise visitor to security and demo.
• Existing user to login or release note.
• Service inquiry to intake.
• Failure path for invalid form and payment errors.

Track the expected event at every step. A migration can lose rankings and revenue even when traffic remains stable if conversion tracking breaks.

Freeze content and technical changes

A migration needs a stable source baseline.

Freeze scope

Before final inventory and redirect-map testing, freeze:

Exceptions

• New top-level pages.
• IA changes.
• Global navigation changes.
• Template redesigns.
• URL naming rules.
• Core product pricing and packaging changes.
• Major docs reorganization.
• Domain, protocol, and platform changes.

Allow:

• Urgent security fixes.
• Critical bug fixes.
• Legal or compliance corrections.
• Tier 1 content corrections.
• Fact updates on existing URLs.

Record every exception. Unmanaged changes invalidate the redirect map and post-launch diagnosis.

Plan governance and ownership

Migrations cross engineering, content, SEO, support, sales, and legal.

RACI model

Assign named owners for:

• Scope and timeline.
• Source inventory.
• Destination IA.
• Redirect map.
• Content migration.
• Docs migration.
• Media and assets.
• Technical implementation.
• Analytics and tracking.
• QA.
• Security and privacy.
• Search Console and sitemaps.
• DNS and certificates.
• Support and help center.
• Communications.
• Launch decision.
• Rollback decision.
• Post-launch monitoring.

Every artifact needs one accountable owner. Committees do not test redirect maps.

Release gates

Do not launch until gates pass:

Design the cutover sequence

1. Source inventory complete.
2. Destination IA approved.
3. Redirect map built and tested.
4. Tier 1 staging tests pass.
5. Conversion tracking verified.
6. Noindex and robots checks pass.
7. Legal, security, and accessibility approvals complete.
8. Monitoring dashboards ready.
9. Rollback plan tested.
10. Support and communications prepared.

A cutover is an operation, not a celebration.

T-minus checklist

T-7 days

• Finalize scope.
• Complete Tier 1 inventory.
• Build redirect map.
• Prepare monitoring.
• Notify support, sales, and engineering.
• Confirm freeze start.

T-3 days

• Run full redirect map test.
• Test staging templates and conversion paths.
• Validate schema, analytics, and consent.
• Verify DNS, TLS, hosting capacity.
• Prepare rollback commands and backups.
• Rehearse cutover steps.

T-1 day

• Re-test Tier 1 URLs.
• Snapshot analytics and Search Console baselines.
• Finalize sitemaps.
• Confirm ownership and escalation contacts.
• Decide go/no-go based on release gates.

T-0

• Deploy migration.
• Apply redirects.
• Update DNS and TLS.
• Deploy production robots.txt.
• Update canonicals.
• Deploy final sitemaps.
• Update internal links and app links.
• Trigger smoke tests.
• Monitor error rates.
• Notify stakeholders.

T+1 hour

Monitor the first 30 days

• Check homepage and top templates.
• Check Tier 1 URLs.
• Check final status codes and canonicals.
• Check tracking events.
• Check CDN and cache rules.
• Check error and form submissions.
• Review DNS propagation where relevant.

Use a fixed review rhythm.

First 24 hours

Days 2–7

Days 8–30

Metrics to compare

• Crawl Tier 1 URLs.
• Test redirect map.
• Confirm 200 vs 301 vs 404 counts.
• Review server errors.
• Confirm new sitemap submission.
• Review Search Console crawl stats.
• Check analytics real-time and conversion events.
• Test forms and checkout.
• Review DNS, TLS, cache, and CDN.
• Capture screenshots and evidence.
• Monitor index coverage.
• Compare impressions and clicks to baseline.
• Review top landing pages.
• Check ranking changes by URL cluster.
• Review 404s and new redirect gaps.
• Check log files for crawl behavior.
• Verify internal search and support tickets.
• Fix Tier 1 regressions first.
• Submit corrected sitemaps.
• Compare week-over-week by template and intent.
• Audit changed URLs, lost traffic, and lost conversions.
• Check backlink equity to redirected pages.
• Review canonical and hreflang drift.
• Analyze crawl budget and duplicate paths.
• Review docs and support ticket volume.
• Measure organic conversions against pre-migration baseline.
• Update stale redirect destinations.
• Decide whether any failures need deeper recovery.
• Indexed pages.
• Crawled pages.
• impressions.
• Clicks.
• Average position by cluster.
• Organic sessions.
• Engaged sessions.
• Trial starts.
• Demo requests.
• Intake submissions.
• Sales qualified leads.
• Paid customers.
• Server errors.
• Redirect depth.
• Core Web Vitals.
• Support tickets.
• CTA click-through rate.

Do not compare only the homepage. Group pages by template, topic, locale, and commercial intent.

Create a tested rollback plan

A rollback is not a sign of failure if triggers are clear.

Rollback triggers

Roll back when:

Rollback requirements

Recovery instead of rollback

• Critical pages return errors or wrong content.
• Private data becomes publicly accessible.
• Checkout, trial, demo, or intake fails.
• Redirect map fails for a large Tier 1 cluster.
• Analytics and conversion tracking cannot be fixed quickly.
• Core Web Vitals degrade so severely that the site is unusable.
• Legal, security, or accessibility gates fail.
• Old environment or snapshot remains recoverable.
• DNS TTL is understood.
• Database and content backups are tested.
• Redirect maps can be enabled or disabled safely.
• Domain and certificate configurations are reversible.
• Cache can be purged.
• Analytics can distinguish periods.
• Owners can execute within an agreed window.

If the new environment is sound but a subset regressed, fix forward:

Handle special migration cases

• Correct redirects.
• Restore missing pages.
• Resolve canonical conflicts.
• Remove accidental noindex.
• Rebuild internal links.
• Update sitemaps.
• Fix rendering or tracking.
• Refresh content.
• Monitor for at least 30 days.

Docs and version removals are a migration subset; the deprecation and docs-churn SEO guide defines the legacy lifecycle.

Different properties need additional controls.

Domain migration

Platform migration

Headless migration

Documentation migration

International migration

Use AI without losing evidence

• Keep old domain redirecting one-to-one.
• Verify both properties in Search Console.
• Submit old and new sitemaps.
• Update backlink-facing assets where feasible.
• Change email, docs, social profiles, and app links.
• Monitor branded search and direct traffic.
• Keep SSL and email authentication healthy.
• Preserve business-critical URL patterns where possible.
• Rebuild template-level metadata.
• Validate media and generated assets.
• Test search, login, and commerce paths.
• Confirm server response rules.
• Review CMS publishing workflow.
• Test server and client rendering.
• Confirm status codes at edge and origin.
• Validate canonicals and hreflang.
• Check dynamic routes and build failures.
• Monitor cache invalidation.
• Ensure metadata survives hydration.
• Preserve stable versioned URLs.
• Map removed versions to current or archived versions.
• Maintain code sample accuracy.
• Test anchors and API references.
• Update SDK and CLI docs.
• Keep changelog links intact.
• Preserve language and region targeting.
• Validate hreflang reciprocals and self-canonicals.
• Keep local currency and contact logic.
• Test localized redirect destinations.
• Avoid mixing locale and campaign parameters.
• Monitor each market separately.

AI can accelerate migration, but it cannot replace tested URLs.

Safe AI uses

Unsafe uses

• Summarize inventory clusters.
• Draft title and description variants.
• Suggest redirect destination candidates.
• Identify similar pages for consolidation.
• Draft QA checklists and stakeholder updates.
• Extract repeated errors from support tickets.
• Auto-approving redirects without URL evidence.
• Rewriting high-revenue pages during migration.
• Fabricating destination URLs.
• Hiding unresolved errors.
• Generating schema for unseen content.
• Replacing QA, analytics, or legal review.

Every AI suggestion must be tested against real URL behavior and conversion paths.

Common migration failures

Post-launch acceptance criteria

• No complete source inventory.
• Every removed page redirects to the homepage.
• Redirect chains created by broad rules.
• Staging robots.txt deployed to production.
• Staging canonicals left in templates.
• Accidental global noindex.
• Broken forms, checkout, or intake.
• Analytics events renamed or removed.
• Sitemaps contain old or blocked URLs.
• Internal links still point to old URLs.
• Private staging pages exposed.
• No rollback snapshot.
• Launch treated as the finish line.

Define what “done” means.

Migration is acceptable when

Maintain the system

• Tier 1 URLs resolve correctly.
• No critical conversion path is broken.
• Organic demand returns toward baseline or has an isolated explanation.
• Index coverage is stable.
• Redirect gaps are fixed.
• Server errors are within tolerance.
• Search Console and analytics are reliable.
• Support can handle remaining issues.
• Documentation and changelog match the new site.

After stabilization:

Bottom line

• Keep redirect map in version control.
• Monitor 404s monthly.
• Review old domain redirects annually.
• Update owner records.
• Add migration lessons to the runbook.
• Reuse the checklist for future releases.

A site migration succeeds through preparation, tested redirects, conversion QA, clear ownership, fixed release gates, and daily monitoring—not through launch-day heroics. Protect Tier 1 demand, isolate regressions quickly, and keep the old equity alive with stable, equivalent destinations.

Before migration, inventory the service business site architecture so service hubs, proof, and intake paths survive the change.

Migration requests should enter a formal impact review because SEO scope creep control separates assessment from implementation.

FAQ