SEO Migration Checklist: Risk-Managed Runbook

A well-run SEO migration protects your organic visibility when you change domains, redesign, switch CMS, or replatform to new tech. This guide gives you a pragmatic, execution-ready runbook. It spans planning, launch, and recovery, so you can ship on time without losing rankings, revenue, or data.

Overview

An SEO migration is the coordinated process of preserving search visibility while your website undergoes a significant change. The upside is faster, safer evolution; the risk is avoidable traffic loss from issues like broken redirects, indexability mistakes, or analytics gaps. Expect some short-term volatility for large moves. Stabilization typically occurs within 2–8 weeks when redirects, sitemaps, and monitoring are on point.

Success looks like crawl parity between old and new, fast redirect resolution, stable indexing of priority URLs, preserved Core Web Vitals, and conversion continuity. In this guide, you’ll find the pre-launch safeguards, launch-day checklist, and post-launch diagnostics that make a complex site migration predictable and reversible.

What is an SEO migration

An SEO migration is the structured set of steps to retain organic performance when your website changes in a material way. Examples include a domain or subdomain move, a redesign that alters templates and internal links, a CMS/platform change, an HTTP to HTTPS migration, or a re-architecture to a JavaScript framework.

When you move domains or subdomains, Google’s Change of Address tool can help signal the move. It does not apply to path-only changes (see Google’s Change of Address help center). See Google’s docs on site moves and redirects for scope and caveats.

When you should (and shouldn’t) migrate

The best time to migrate is when business impact outweighs risk and your team is staffed to manage that risk. Strong drivers include a rebrand, international expansion, sunsetting legacy systems, or performance/security gains that materially affect revenue. Conversely, avoid cutovers near peak season, major promotions, or when prerequisites like redirect mapping, load testing, and analytics QA aren’t complete.

Use these decision criteria to time the project and set gates:

1. Business urgency vs. seasonality: avoid blackouts; choose low-traffic windows.
2. Readiness: redirect map ≥95% complete for indexed URLs; staging crawl parity ≥90% for priority templates.
3. Resourcing: named owners for SEO, dev, analytics, PM; clear on-call “war room” coverage.
4. Rollback ability: toggles, backups, and a tested reversion plan within your CDN/app infra.

If any single criterion is red, defer the launch window. Time spent de-risking here is cheaper than post-launch firefighting.

Types of website migrations and SEO risk profiles

Not all site migrations carry the same SEO risk. URL-changing migrations—domain moves, path structure changes, or CMS/platforms that alter routing—carry the highest risk because they depend on redirects and reindexing. Non-URL changes—template redesigns, performance work, or infrastructure moves—carry medium risk but can still impact rankings via internal links, renderability, or Core Web Vitals.

Consider these complexity factors up front:

1. Scale: the more URLs, the more edge cases and crawl budget considerations.
2. International: hreflang and alternates multiply mapping complexity.
3. JavaScript frameworks: SSR/hydration quality and router behavior can affect crawl and render. Google has deprecated dynamic rendering; prefer server-side rendering or hybrid rendering patterns.
4. eCommerce: faceted navigation, parameters, pagination, and product variants require explicit canonical and robots strategies.

Understanding your migration type and complexity sets the scope for redirect strategy, testing depth, and monitoring intensity.

Roles, RACI, and timelines

SEO migrations succeed when ownership is explicit. A lightweight RACI helps: SEO Lead (Responsible for mapping, QA, monitoring), Dev/Infra (Responsible for redirects, deploys, DNS/CDN, performance), PM (Accountable for timeline, gates, comms), Analytics (Responsible for GA4, tags, consent, conversion QA), Stakeholders (Consulted), and Support/Comms (Informed).

For timelines, small sites (<5k URLs) often need 4–6 weeks, mid-market (5k–100k) 8–12 weeks, and enterprise (100k+) 12–20 weeks. Include content inventory and phased testing in your plan.

Use a gate model to reduce risk:

1. Gate 1: Architecture freeze and URL scheme approval.
2. Gate 2: Redirect map v1 complete and validated on staging.
3. Gate 3: Technical QA pass on staging (indexability, CWV, structured data).
4. Gate 4: Go/no-go review with rollback rehearsal and on-call roster confirmed.

Tie each gate to measurable thresholds and sign-offs so launch-day decisions are clear, not subjective.

Pre-launch planning and environment setup

Start by building a complete URL inventory and content parity baseline. Crawl the current site and the staging site to understand template coverage, internal links, and metadata consistency. This becomes your source of truth for redirect mapping and QA.

Establish analytics and search baselines—rankings cohorts, organic sessions by top paths, conversion rates, and crawl/index stats. With clean baselines, you can compare “before vs. after” with confidence.

Lock down staging from indexing with authentication and noindex directives. Ensure data-layer parity so your analytics will work on day one.

Coordinate infrastructure early. DNS TTLs, CDN edge rules, TLS/SSL and HSTS, and cache purge sequencing all affect how smoothly search engines and users experience the cutover. Build your rollback switches now: feature flags, CDN route reversions, and snapshot backups.

Crawl parity baseline and content inventory

Your goal is to prove the staging site can replace the current site without losing findability, context, or conversions. Run comparative crawls across both environments and reconcile head terms, long-tail pages, and critical templates like product, category, blog, and hub pages. Measure parity on titles, meta descriptions, headings, internal links, canonicals, structured data, and navigation.

Track readiness with clear targets:

1. Priority templates: ≥95% parity on indexability, canonicals, and internal links.
2. Priority URLs: ≥98% mapped with one-hop redirects; 0 loops/chains for top pages.
3. Metadata and schema: ≥90% parity on titles/H1s and required schema properties.
4. XML sitemaps: generated on staging with correct lastmod, split by type for large sites.

These thresholds keep the discussion objective and help you decide when to open the launch window.

URL mapping and redirect strategy

Redirect mapping is the backbone of an SEO site migration. Inventory all indexable and high-traffic URLs, then map each to its final destination with preferred casing, trailing slash policy, and normalized parameters.

Handle edge cases like legacy m-dot subdomains, uppercase paths, and mixed file extensions. Solve them with canonical routing rules at the edge/CDN to prevent chains and case drift.

Choose status codes with a simple decision guide:

1. 301 or 308: permanent move; Google supports both for site moves. Use 301 if behavior is already standard; 308 maintains method/body and is ideal for strict APIs or form posts.
2. 302/307: temporary; avoid for migrations unless you are intentionally testing a short-lived path.
3. 410: gone; use when content is permanently removed with no replacement (reduce soft-404s).
4. 200 + rel=canonical: for duplicate management where redirecting is impossible (e.g., parameters you still need for UX).

Document regex rules for scalable routing. Ensure only one hop from any legacy URL to its new canonical destination.

Staging protections and data layer parity

Protect staging from indexing with authentication, x-robots-tag: noindex headers, and robots.txt disallow. Do not rely on robots.txt alone; it doesn’t prevent indexing of externally linked URLs.

Mirror your production tag manager containers and GA4 config in staging, but point to a separate property/stream. Validate events, parameters, and consent behavior without polluting live data. Confirm that transaction IDs, ecommerce events, and custom dimensions match your production dataLayer contract.

Infrastructure and DNS considerations

Smooth cutovers depend on predictable DNS and CDN behavior. Lower DNS TTLs 48–72 hours before launch so changes propagate quickly. Pre-stage edge redirect rules in your CDN to avoid origin bottlenecks.

Configure TLS/SSL and enable HSTS after confirming all subresources resolve over HTTPS. Set cache purge sequencing so old assets and HTML are invalidated in the right order. Maintain a rollback toggle to revert routes or disable new edge rules within minutes if critical errors surface.

Include these infra tasks in your plan:

1. Lower DNS TTL to 300 seconds pre-launch; restore after stabilization.
2. Preload and test CDN redirect rules; validate cache key normalization for case/params.
3. Schedule global cache invalidation at T0; purge HTML first, then critical assets.
4. Implement HSTS and ensure canonical https redirects are enforced.
5. Keep a kill switch for new edge rules and a blue/green or feature-flag rollback.

These controls prevent stale caches, redirect storms, and mixed-content failures during the cutover.

Pre-launch technical QA

Consolidate your QA into a single sign-off so everyone agrees the site is indexable, internally coherent, and fast. Validate robots directives, canonical integrity, XML sitemap readiness, structured data preservation, and renderability. For JavaScript apps, confirm server-side rendering is in place.

For large sites, verify sitemap index architecture. Split by type, keep files under 50k URLs or 50MB, maintain correct lastmod dates, and include alternates for hreflang sets where applicable.

Performance matters as much as content parity. Benchmark Core Web Vitals from field and lab sources and set budgets you won’t exceed at launch. If moving to a JS framework, confirm SSR/hydration is stable and that critical content is available in the initial HTML. Dynamic rendering is deprecated, so rely on modern rendering patterns. Establish a monitoring cadence to catch regressions fast after go-live.

Indexability and canonicalization

Indexability errors are the most common migration failures. Confirm robots.txt allows essential paths, meta robots are correct for each template, and canonical tags are self-referential and consistent with redirects. Avoid canonical conflicts between paginated, parameterized, and faceted URLs by enforcing one canonical target per intent.

Use this quick pass before sign-off:

1. robots.txt: verify production-ready rules; block only what must be blocked.
2. Meta robots/x-robots-tag: correct noindex on staging; removed for production.
3. Canonicals: self-referential on canonical URLs; consistent with redirect destinations.
4. XML sitemaps: clean, deduped, and submitted-ready; include priority URLs first.

A clean canonical layer aligns with your redirect strategy to speed reindexing.

Internationalization and accessibility checks

For international sites, ensure hreflang alternates are correct, reciprocal, and match canonical URLs. If URLs are changing, update sitemap alternates or on-page tags at scale and validate country/language pairs. Follow Google’s localized versions guidance to keep regional content discoverable.

Preserve accessibility signals through the migration. Check alt text, ARIA labels, heading hierarchy, link focus states, and breadcrumb markup parity. Accessible templates are more robust to rendering edge cases and improve UX metrics that correlate with rankings.

Structured data and SERP features preservation

Schema markup often powers rich results for products, FAQs, how-to guides, and articles. Validate that required and recommended properties are present post-migration, especially price/availability for product pages and author/date for articles. Use Google’s testing tools to confirm eligibility and fix templating gaps that can silently remove enhancements.

Maintain consistent entity references (Organization, WebSite, BreadcrumbList) and ensure your brand signals—logo, sameAs profiles—remain intact. This helps stabilize brand SERPs through the transition.

Performance and Core Web Vitals

Migrations are a prime time to improve or protect performance. Benchmark LCP, CLS, and INP in staging and compare to production. INP became a Core Web Vital in 2024, and keeping interaction latency low often requires input delay budgeting and careful hydration.

Adopt practical targets and cadence:

1. Targets: LCP < 2.5s, CLS < 0.1, INP < 200 ms for 75th percentile users.
2. Safeguards: serve critical HTML server-side, preconnect important origins, and lazy-load below-the-fold media.
3. Cadence: monitor field data daily for 2 weeks post-launch, then weekly for 8 weeks; set alerts for regressions ≥10%.

Treat performance budgets as launch gates, not suggestions.

Launch day runbook

Launch day is about choreography: one deploy, one cache plan, one monitoring console, and fast decision-making. Schedule an off-peak window, put named owners on each step, and keep the list short enough to execute under pressure. Have a comms channel and a recovery plan ready before you flip the switch.

After cutover, stay in a controlled “war room” for the first hours. Verify the critical path—homepage, top categories, top products, blog hubs, and key conversions—before declaring success. If core thresholds fail and you cannot remediate quickly, use your rollback toggles.

Deployment window, checkpoints, and go/no-go

Confirm environment readiness, then proceed through this ordered checklist:

1. Freeze content and code; confirm backups and rollback toggles.
2. Lower DNS TTL (if not already), warm CDN, and enable edge redirect rules.
3. Deploy application changes; purge CDN caches (HTML first), verify TLS/HSTS.
4. Validate top redirects (old → new) for priority URLs; check for loops/chains.
5. Submit updated XML sitemaps; verify robots.txt and meta robots in production.
6. Run smoke tests for CWV-critical pages; confirm GA4/consent events fire.
7. Check GSC crawl stats and server logs begin showing 200s/301s, not 404/5xx.
8. Hold go/no-go: if any blocker exceeds thresholds (e.g., 404 rate >1% of requests on top paths), fix or rollback.

Close with a timestamped launch note and assignment of the next monitoring intervals. Keep stakeholders informed but focused—avoid ad-hoc changes during the window.

Redirects activation and validation

Turn on redirects at the edge and the application layer as planned, then test at scale. Start with your revenue-driving and most-linked URLs to ensure they resolve in a single hop and return cacheable 301/308 responses. Validate case normalization, trailing slash and http→https policies, and strip or preserve parameters according to your canonical rules.

Use a tight spot-check list:

1. Sample 50–100 top pages: confirm one-hop 301/308 to the intended canonical.
2. Crawl a mapped subset to detect unexpected 404s, 302s, or chains.
3. Inspect server headers for cache-control and HSTS; confirm no mixed content.
4. Re-check robots and canonicals on destination pages match redirect intent.

When issues surface, fix rules at the highest layer possible (CDN > origin) to reduce latency and complexity.

Search Console tasks (including Change of Address for domain moves)

Right after launch, complete these Search Console steps to accelerate discovery:

1. Verify new property (domain or URL prefix) and confirm ownership.
2. Submit updated XML sitemaps and sitemap index files.
3. Use the Change of Address tool for domain or subdomain moves only.
4. Add URL removal requests for deprecated, error-prone legacy paths if needed.
5. Inspect a sample of redirected URLs and destination URLs to confirm signals.
6. Annotate launch date for future analysis.

These actions help Google crawl the new structure faster and reduce false positives in coverage reports.

Analytics, tags, and conversion validation

Your measurement must be continuous through the migration. Confirm GA4 events, ecommerce, and consent flows are firing and attributed as expected. For cross-domain moves, configure cross-domain measurement and referral exclusions so sessions don’t split when users traverse domains or payment providers.

Validate with this quick pass:

1. GA4: correct Measurement ID, duplicate-filtering, and enhanced measurement settings.
2. Cross-domain: configure measurement and referral exclusion for new and legacy domains; preserve UTM parameters.
3. Conversions: run test transactions and form submissions; confirm event parameters and IDs match pre-launch contracts.

With analytics confidence, you can separate true SEO issues from simple tracking noise in the first days after cutover.

Post-launch monitoring and stabilization

The first 72 hours are about catching high-severity issues early. Monitor crawl and server error rates hourly, validate redirect integrity at scale, and confirm that XML sitemaps are being fetched and parsed.

Days 4–14 focus on indexing deltas, ranking cohort trends, and conversion stability. Expect some position wobble for URL-changing moves while signals consolidate.

Weeks 3–8 are for optimization. Use log files and GSC’s Crawl Stats to tune internal linking and sitemaps so Googlebot spends time on canonical, high-value pages. Keep a weekly cadence for Core Web Vitals and structured data checks, and begin backlink remediation outreach to update top referrers to their new URLs.

GSC and GA4 monitoring targets

Post-launch success is measurable. Track these metrics closely and tie them to remediation if thresholds are breached:

1. Coverage: growth of “Indexed” for priority URLs; shrinkage of “Alternate page with proper canonical tag.”
2. Crawl Stats: steady or increased crawl of canonical paths; low 404/5xx rates (<0.5–1% of requests).
3. Sitemaps: regular fetches; high “discovered” and “indexed” ratios for sitemap URLs.
4. Rankings: cohort trends for top 100 keywords; stabilization by week 2–4 for non-domain moves.
5. GA4: organic sessions and conversion rate on top paths within ±10–15% of baseline.

If any metric drifts beyond thresholds without recovery, escalate to the troubleshooting section and consider partial rollback.

Log files and crawl budget tuning

Server logs are the fastest way to verify Googlebot behavior after a site migration. Parse logs to isolate Googlebot requests, then analyze status codes, redirect hops, and path coverage for your canonical sections. High 404 or multi-hop rates point to mapping gaps; low crawl on deep but important sections suggests internal link or sitemap improvements.

Use insights to tune discovery. Prioritize key sections in XML sitemaps, add contextual internal links from high-authority pages, and fix broken or orphaned URLs. Adjust crawl rate settings in Search Console only if your servers are stressed. Otherwise, let Google calibrate automatically based on consistent, fast responses.

Backlink updates and brand protection

Even perfect redirects can leave equity on the table if top backlinks never update. Identify your highest-value referring domains and pages, then request link updates to the new URLs. Start with partners, press, and owned profiles first because they respond faster. Monitor brand SERPs for sitelink health, knowledge panel integrity, and navigational query stability.

Prioritize these actions:

1. Outreach to top 50–200 referrers with specific new URLs.
2. Update owned channels: social profiles, app listings, email templates, and paid landing pages.
3. Monitor new 404s from referrers and add targeted redirects where needed.
4. Review disavow only if toxic link patterns cluster on deprecated paths.

These steps harden your brand signals and reduce long-tail link rot.

Troubleshooting traffic and rankings dips

Some volatility is normal; persistent dips signal specific issues. Diagnose in order: verify redirects and indexability, confirm rendering and content parity, then check analytics integrity. Use Search Console Coverage and Page Inspection to see what Googlebot sees. Correlate with server logs, and fix high-impact errors first.

For JS-heavy sites, compare raw HTML vs. rendered HTML for critical content and links to catch hydration mismatches. Keep a calm, methodical cadence. Implement fixes in small batches, annotate changes, and re-check logs and GSC after each push. If you cannot restore core KPIs within pre-agreed thresholds quickly, execute your rollback and regroup.

Decision tree: diagnose by symptom

Start from the observed signal and trace to the most probable root cause:

1. 404 spike: missing redirects or mismatched casing/trailing slashes; fix mapping/rules and recrawl.
2. Soft 404s in GSC: thin or mismatched content at destinations; strengthen content or redirect to more relevant targets.
3. Canonical drift: conflicting canonicals vs. redirects or parameters; align canonical tags and redirect destinations.
4. Render mismatch: critical content not in initial HTML; enable SSR or ensure hydration doesn’t defer key content/links.
5. Coverage stuck: sitemaps not fetched or poor internal links; re-submit sitemaps and add contextual links.
6. Rankings fall on select clusters: internal link equity lost in redesign; restore navigational links and breadcrumbs.

After each fix, validate with URL Inspection and logs to confirm Googlebot sees the improvement.

Rollback and remediation playbook

Rollback is a safety tool, not a failure. Define conditions for partial or full rollback, and rehearse the switch in a staging or blue/green environment so you know it works under pressure. When rolling back, pair technical changes with clear comms to stakeholders and a plan to reattempt the migration with corrected issues.

Use this structure if thresholds fail:

1. Conditions: 404/5xx >1–2% on top paths, critical conversion breakage, or indexing collapse on priority URLs for >48 hours.
2. Partial rollback: disable new edge rules or revert specific routes/templates while keeping unrelated improvements.
3. Full rollback: flip DNS/CDN routes to the prior environment; restore previous sitemaps and robots.
4. Comms: timestamped internal note, external status update if user-facing, and revised timeline with root cause analysis.

Track recovery back to baseline before re-opening a new launch window with updated safeguards.

Cost, effort, and realistic timelines

Cost and duration scale with URL count, complexity, and cross-functional scope. A small brochure site might take 4–6 weeks with a lean team, while a 100k–1M URL ecommerce or content site typically requires 12–20 weeks and phased validation. Major cost drivers include redirect mapping at scale, international/hreflang migration, JavaScript rendering/SSR work, and analytics/consent compliance.

Where expert help pays for itself is in planning and QA. That includes building resilient redirect frameworks, avoiding JavaScript rendering pitfalls, designing sitemap architectures for large sites, and setting up GA4 cross-domain measurement without conversion loss. The alternative—fixing a preventable 20–40% traffic dip post-launch—costs more in both revenue and time.

Templates and checklists you can copy

Below are the core documents teams use to ship confidently. Create copies for your stack and fill them with your URLs, owners, and thresholds.

1. Redirect map template (URL inventory, destination, status code, notes, regex rules).
2. RACI and on-call “war room” roster (owners, responders, approvers, informed).
3. Go/no-go checklist with KPI thresholds (crawl parity, 404/5xx ceilings, CWV, analytics).
4. Launch-day runbook (ordered steps, timestamps, and verification points).
5. Post-launch monitoring dashboard schema (GSC coverage/crawl, GA4 path KPIs, log summaries).
6. International sitemap plan (sitemap index splits, lastmod hygiene, hreflang alternates).
7. Analytics continuity checklist (GA4 cross-domain, referral exclusions, UTM parity, consent tests).

Keep these living documents in your project hub and require sign-offs at each gate.

References and further reading

1. Google: robots.txt and robots directives — https://developers.google.com/search/docs/crawling-indexing/robots/intro
2. Google: Localized versions and hreflang — https://developers.google.com/search/docs/specialty/international/localized-versions
3. Chrome/Web.dev: Interaction to Next Paint (INP) — https://web.dev/inp/
4. Google Analytics Help: Cross-domain measurement — https://support.google.com/analytics/answer/9191807
5. Google: Dynamic rendering deprecation and JavaScript guidance — https://developers.google.com/search/docs/crawling-indexing/dynamic-rendering

Notes:

1. Google supports 301/308 for permanent moves and treats them similarly for indexing speed and signal consolidation.
2. The Change of Address tool is only for domain or subdomain moves, not path changes.
3. INP became a Core Web Vital in 2024, and keeping it under 200 ms for the 75th percentile is a strong target.