Back to blog

technical SEO migration checklist

Technical SEO Migration Checklist for Site Redesigns and Platform Moves

8 min read1,851 words
Technical SEO migration checklist displayed as a phased workflow diagram covering pre-migration audit, redirect mapping, staging validation, launch day, and

A site redesign or platform migration is one of the highest-risk events in organic search. Done without a structured plan, it can erase years of accumulated ranking authority in days. A thorough technical SEO migration checklist is the difference between a seamless transition and a six-month traffic recovery project.

Quick answer: A technical SEO migration checklist is a phase-by-phase set of tasks teams complete before, during, and after a site redesign or platform move to protect organic rankings. The core phases are: (1) pre-migration crawl audit to document existing URL structure and performance baselines; (2) 301 redirect mapping from every old URL to its new equivalent; (3) staging environment validation of canonical tags, XML sitemaps, and structured data schema; (4) launch-day execution with Google Search Console verification; and (5) post-launch monitoring of crawl errors, keyword rankings, and Core Web Vitals for at least 90 days. Skipping any phase risks permanent link equity loss.

Site migrations fail not because teams lack effort, but because they lack a repeatable framework. The checklist below is organized by phase so every stakeholder — developer, SEO, and project manager — knows exactly what to own and when.


Why Technical SEO Migrations Go Wrong

Most ranking drops after a redesign trace back to a handful of predictable failures: broken redirect chains, missing canonicals on the new platform, XML sitemaps that still reference old URLs, and structured data that was stripped during a theme change. Each failure sends a different negative signal to Googlebot, and the combined effect compounds quickly.

Understanding the failure modes is the first step. The second is following a checklist that addresses every one of them before a single URL goes live.


Phase 1: Pre-Migration Audit

Before touching a staging environment, document the current state of the site completely. You cannot protect what you have not measured.

What to Capture in Your Baseline

  • Full crawl export: Use a technical audit tool to crawl every indexable URL. Export status codes, titles, meta descriptions, canonical tags, internal link counts, and inbound link counts per URL. This becomes your redirect mapping source of truth.
  • Google Search Console data: Export the top 500–1,000 URLs by impressions and clicks over the last 12 months. These are your highest-risk pages — any that lose their URL without a redirect will bleed traffic immediately.
  • Backlink profile: Export all referring domains and the specific URLs they point to. Redirecting a page that has 200 referring domains is not optional.
  • Core Web Vitals baseline: Record LCP, CLS, and INP scores per template type (homepage, category, product/post). Your new platform must match or beat these scores.
  • Structured data inventory: Document every schema type currently deployed — Article, Product, FAQ, BreadcrumbList, Organization. Rebuilding schema after launch is far harder than migrating it intentionally. See the Google Search Central structured data guide for schema requirements by type.

If you are evaluating which tool to use for this audit phase, the comparison at best SEO audit tools compared covers the leading options by feature depth.


Phase 2: 301 Redirect Mapping

Redirect mapping is the single most consequential task in any migration. A complete, accurate redirect map preserves link equity and tells Google where content has moved rather than disappeared.

Building the Redirect Map

Create a spreadsheet with four columns: old URL, new URL, HTTP status of the old URL, and priority tier (based on traffic and backlinks). Every URL returning a 200 status on the current site needs a destination. Redirects should be:

  • Direct (one hop): Old URL → New URL. Chains (Old → Intermediate → New) dilute equity and slow crawl.
  • Semantically matched: A blog post about keyword research should redirect to the equivalent new blog post, not the homepage.
  • Comprehensive: Include paginated URLs, filtered URLs, and legacy campaign URLs that still receive backlinks.
Redirect ScenarioCorrect ActionCommon Mistake
URL slug changes301 to exact new slugRedirecting to homepage
Page consolidated into another301 to the surviving pageLeaving old URL as 404
Category restructured301 each subcategory to new pathRedirecting all to category root
Platform move (e.g., Shopify to custom)301 every product and collection URLOnly redirecting top-level pages
Pagination removed301 page 2+ to page 1 or canonicalNo redirect, orphaned pages

Phase 3: Staging Environment Validation

Never validate SEO configuration on a live site. The staging environment is where you catch errors before they cost rankings.

Canonical Tags and Crawl Budget

Every page on staging should have a self-referencing canonical tag pointing to the intended production URL — not the staging domain. A staging site that accidentally goes live with canonicals pointing to staging.example.com will tell Google to ignore the production site entirely.

Crawl budget matters most for large sites (10,000+ URLs). Audit the staging crawl to confirm that:

  • Faceted navigation and filtered URLs are either canonicalized or blocked via robots.txt
  • Pagination uses rel="next" / rel="prev" or is handled with canonicals per your platform's approach
  • Thin or duplicate pages are not consuming crawl budget that should go to high-value content

XML Sitemap Validation

Generate a fresh XML sitemap from the new platform and validate it against these criteria per Google sitemap guidance:

  • Contains only canonical, indexable URLs (no noindex pages, no redirects)
  • Reflects the new URL structure, not the old one
  • Is split into logical sub-sitemaps if the site exceeds 50,000 URLs
  • Is referenced in robots.txt

Hreflang for Multilingual Sites

If the site serves multiple languages or regions, validate hreflang annotations on every page. Each language variant must reference all other variants, including itself. A broken hreflang implementation on a redesign is one of the most common causes of international traffic collapse.

Structured Data Schema

Re-implement and validate all schema types identified in Phase 1. Use Google's Rich Results Test on staging URLs before launch. If your team uses schema automation, the post on AI schema automation for SEO and AI answer engines explains how to maintain schema at scale across a new platform.


Phase 4: Launch Day Execution

Launch day is not the time for discovery. Every action should follow a pre-written runbook.

Launch Day Checklist

  • Remove noindex from staging configuration before DNS switch
  • Verify robots.txt on production allows Googlebot access to all intended paths
  • Confirm all 301 redirects are live and returning the correct status codes
  • Submit the new XML sitemap in Google Search Console immediately after DNS propagation
  • Verify Google Search Console ownership on the new domain or property if the domain changed
  • Test a sample of high-priority URLs manually for correct canonical tags, title tags, and structured data
  • Check page speed on production (not staging) — server environments differ

The Google SEO Starter Guide remains the authoritative reference for what Googlebot expects to find on a well-configured site.


Phase 5: Post-Launch Monitoring

A migration is not complete at launch. The monitoring phase determines whether the execution held.

What to Monitor and When

Days 1–7: Check Google Search Console daily for crawl errors, coverage drops, and any manual actions. Watch for a spike in 404s that indicates redirect gaps.

Days 8–30: Track keyword rankings daily. A well-executed migration typically shows ranking fluctuation in the first two weeks before stabilizing. For accurate rank tracking methodology, see how to track keyword rankings accurately.

Days 31–90: Audit redirect chains weekly — new content additions can accidentally create chains. Monitor Core Web Vitals in Search Console's Page Experience report. Compare organic traffic week-over-week against the pre-migration baseline.

For teams that want AI-assisted audit coverage during this monitoring phase, how to use AI for technical SEO audits covers how automated crawl analysis can surface issues faster than manual review.


Technical SEO Migration Checklist: Summary

Pre-Migration

  • Complete crawl export with all URL metadata
  • Google Search Console traffic and impression export
  • Backlink profile export by URL
  • Core Web Vitals baseline by template
  • Structured data schema inventory

Redirect Mapping

  • Map every 200-status URL to a new destination
  • Eliminate redirect chains
  • Prioritize high-traffic and high-backlink URLs

Staging Validation

  • Canonical tags pointing to production URLs
  • XML sitemap contains only canonical, indexable URLs
  • Hreflang annotations validated (if applicable)
  • All schema types re-implemented and tested
  • Crawl budget waste identified and addressed

Launch Day

  • noindex removed, robots.txt correct
  • All redirects live and verified
  • New sitemap submitted in Google Search Console
  • GSC ownership confirmed

Post-Launch

  • Daily rank tracking for 30 days
  • GSC crawl error monitoring
  • Weekly redirect chain audit
  • Core Web Vitals comparison against baseline

Frequently Asked Questions

What is a technical SEO migration checklist?

A technical SEO migration checklist is a structured, phase-by-phase list of tasks — covering crawl audits, redirect mapping, canonical tags, sitemap updates, and post-launch monitoring — that teams follow when redesigning a site or moving to a new platform to prevent ranking and traffic loss.

How long does it take to recover rankings after a site migration?

Most sites see Googlebot re-crawl and re-index key pages within 2–8 weeks after a well-executed migration. Full ranking stabilization typically takes 3–6 months. Poorly mapped redirects or missing canonicals can extend recovery to 6–12 months or cause permanent traffic loss.

What is the most common SEO mistake during a site migration?

The most common mistake is failing to implement a complete 301 redirect map before launch, leaving old URLs returning 404 errors. This destroys accumulated link equity and signals to Google that content has disappeared rather than moved.

Do I need to resubmit my sitemap after a site migration?

Yes. After a site migration you should generate a fresh XML sitemap reflecting all new URLs, submit it in Google Search Console, and verify that Googlebot can access and crawl it without errors. Per Google's sitemap guidance, an updated sitemap accelerates discovery of new URL structures.

How do I monitor SEO performance after a site migration?

Monitor post-migration SEO by tracking keyword rankings daily for the first 30 days, watching Google Search Console for crawl errors and index coverage drops, checking Core Web Vitals on new page templates, and auditing redirect chains weekly until traffic stabilizes.

Sources and Further Reading


If you are planning a migration in the next 90 days, start with the pre-migration crawl audit now — before any design decisions are finalized. The earlier you document your current URL structure and traffic baselines, the more complete your redirect map will be. For teams that want a single platform to run the audit, track redirects, monitor rankings, and validate schema across the entire migration lifecycle, explore how choosing the right SEO audit tool affects the quality of every phase in this checklist.