A Phase-by-Phase SEO Website Migration Checklist

A website migration can succeed technically and still create SEO problems if search engines encounter broken redirects, changed URLs, conflicting canonical signals or pages that are no longer indexable. Google explicitly warns that significant site changes can cause temporary ranking fluctuations while it recrawls and reindexes pages, with even a medium-sized site potentially taking a few weeks for most URLs to move through its index.

That makes SEO migration all about preserving the signals search engines need to understand what changed and where content moved.

This SEO website migration checklist breaks that work into four phases: planning, staging, launch and post-launch monitoring. It covers the essentials for any migration while going deeper on WordPress and Drupal CMS moves, where URL behavior, redirects, templates, metadata and platform configuration can all change at once.

Phase 1: Build the pre-migration SEO baseline and migration map

Before an SEO website migration, document what exists, decide what will change, and create a URL-level plan to preserve important pages and search signals. This work becomes the baseline for every staging, launch-day, and post-launch check that follows.

Establish a pre-migration benchmark

You need to know what “normal” looks like before you can recognize a migration problem. Export and preserve baseline data for:

• Organic clicks, impressions, and important queries from Google Search Console.
• Organic sessions and conversions from Google Analytics or your analytics platform.
• Indexed and excluded URLs.
• XML sitemaps and robots.txt directives.
• Current canonical tags, hreflang annotations, structured data, titles, and meta descriptions.
• Key landing pages and URLs receiving meaningful organic traffic or backlinks.
• Crawl errors, HTTP status codes, and current performance metrics.

For large sites, server logs and CMS exports can help uncover URLs that a standard crawl or sitemap might miss. Google specifically recommends using sitemaps, analytics, server logs, Search Console link data, and the CMS when building an inventory for complex migrations.

Decide exactly what is changing

A migration becomes harder to diagnose when a team changes the domain, CMS, site architecture, content, and design simultaneously. Google recommends changing one major element at a time when possible because separating changes makes their effects easier to identify. Scheduling the migration during a predictably lower-traffic period can also reduce the number of users affected if something goes wrong.

Define the scope before development begins: 

• Are URLs changing? 
• Is only the hosting infrastructure moving? 
• Are pages being consolidated or removed? 
• Is the domain changing? 

The answers to these questions determine which SEO controls the migration requires.

Build the old-to-new URL map

If URLs will change, create a mapping that assigns every important existing URL to its intended destination.

The destination should be the closest relevant replacement, not simply the homepage. Pages with no appropriate replacement can return 404 or 410 – redirecting large numbers of unrelated pages to one destination can be interpreted as a soft 404.

Use the map to prepare:

• Permanent server-side 301 or 308 redirects where pages have genuinely moved.
• Direct redirects to the final destination rather than unnecessary redirect chains.
• Updated internal links.
• Self-referencing canonicals using the new URLs.
• Updated hreflang annotations where applicable.
• A new XML sitemap containing canonical destination URLs.

Google recommends permanent server-side redirects for permanent moves and advises keeping migration redirects in place for at least one year and potentially longer for users who still follow old links.

Prepare your measurement and launch controls

Before launch, verify the relevant old and new properties in Search Console, including domain variants that matter to the migration, and make sure analytics tracking will continue working on the new site.

Additionally, assign owners for redirects, DNS, analytics, crawling, and rollback decisions, and agree on what would justify stopping or reversing the launch. At this point, the SEO migration plan should be concrete enough that the staging environment can be tested against it URL by URL rather than evaluated by appearance alone.

Phase 2: Test SEO on staging before launch

The staging site is where the migration plan becomes testable. Crawl and inspect the staging site as if it were production, comparing the results against the URL inventory and benchmarks established in Phase 1.

Confirm crawl and indexing controls

A staging site should not accidentally compete with the live site in search results. Password protection is the strongest option when the environment should remain private. A noindex directive can prevent indexing when the site must remain publicly accessible, but Google must be able to crawl the page to see that directive. Blocking a URL in robots.txt does not guarantee that the URL cannot appear in search results.

At the same time, prepare the production versions of these controls. Google explicitly recommends having the launch-ready robots.txt file prepared and identifying any development noindex directives that must be removed when the migration begins.

Crawl the staging site and compare it with production

Run a full crawl and look for differences that were not part of the migration plan. Check that:

• Important pages return the intended HTTP status codes.
• Titles, meta descriptions, headings, and primary content migrated correctly.
• Internal links point to the intended new URLs rather than old URLs, staging URLs, or redirecting URLs.
• Canonical tags identify the correct production URLs.
• Images, CSS, JavaScript, PDFs and other important resources are present and accessible.
• Hreflang annotations remain reciprocal and point to the correct localized URLs where used.
• The planned XML sitemap contains only canonical, indexable production URLs.

Canonicalization deserves particular attention because redirects, rel="canonical" annotations, and sitemap inclusion all contribute signals about which URL Google should treat as representative. Conflicting signals make the preferred URL less clear.

Test the redirect map

For every URL that will change, validate the planned old-to-new redirect against the mapping created in Phase 1. Look specifically for missing redirects, loops, chains, incorrect destinations, and redirects that collapse unrelated pages into a generic page.

Also check the site's internal links. Visitors and crawlers should ideally reach the final URL directly instead of relying on a redirect every time they navigate through the new site.

Validate structured data and rendering

Migration work can change templates even when the visible content appears identical. Test representative page types with Google's Rich Results Test, URL Inspection tool, or another schema validator and confirm that the markup still describes content that is actually visible on the page. 

For JavaScript-heavy sites, also verify that critical content and links are present in the rendered output rather than assuming that a successful browser render means every crawler will receive the intended page.

Test tracking, functionality and performance

Confirm that analytics, consent management, conversion tracking, forms, navigation, search and other business-critical functionality work before launch. Then compare representative templates against the performance baseline established before the migration.

Staging tests are useful for catching regressions, but they are not a replacement for post-launch field data. For Core Web Vitals, Google currently defines a “good” experience at the 75th percentile as:

• Largest Contentful Paint (LCP): 2.5 seconds or less.
• Interaction to Next Paint (INP): 200 milliseconds or less.
• Cumulative Layout Shift (CLS): 0.1 or less.

By the end of this phase, you should have a resolved issue list and a staging site that matches the migration specification.

Phase 3: Run the SEO launch-day checklist

Launch day is about confirming that search engines and users can reach the new site exactly as planned. Once the cutover begins, prioritize checks that could immediately prevent crawling, indexing or traffic from reaching the correct URLs.

Activate and test redirects

If URLs changed, enable the redirect rules prepared earlier and test them immediately. Google recommends permanent server-side redirects such as 301 or 308 for permanent moves.

Spot-check high-value URLs manually, then test the complete redirect map programmatically. Confirm that:

• Every old URL reaches its intended new destination.
• Redirects point directly to the final URL wherever possible.
• There are no loops or broken destinations.
• Removed pages without a relevant replacement return an appropriate 404 or 410.
• HTTP, HTTPS, www, non-www, and other relevant hostname variants resolve as intended.

Keep permanent migration redirects in place for at least one year so Google has sufficient time to recrawl old URLs and transfer signals to their replacements.

Remove staging restrictions

One of the most damaging launch mistakes is carrying staging controls into production.

Immediately verify that production pages intended for search are not blocked by a leftover noindex directive or an overly restrictive robots.txt rule. Then check that canonical tags reference the final production URLs rather than the staging domain or old URLs.

Also verify that internal links, hreflang annotations, images, scripts, and other resources resolve against the production environment.

Crawl the live site

Run a fresh production crawl as soon as the site is available. This catches issues that staging testing cannot expose, including deployment-specific configuration errors.

Compare the crawl against your pre-launch findings and investigate unexpected:

• 4xx and 5xx responses.
• Redirect chains or loops.
• Non-indexable important pages.
• Missing or incorrect canonicals.
• Old-domain or staging-domain internal links.
• Missing titles, metadata, structured data, or content.
• Blocked CSS, JavaScript, and image resources.

For the most important templates and landing pages, use Search Console's URL Inspection tool to confirm how Google can access them.

Submit the new sitemap and Search Console signals

Submit the production XML sitemap in Google Search Console so Google can discover the new canonical URLs more efficiently. During the transition, keep the old-URL sitemap submitted too – it helps Google find the redirects and lets you watch old-URL indexing fall as the new URLs climb (see Phase 4). Remove the old sitemap once the move is complete.

For a domain migration, submit Google's Change of Address request once the redirects are working. Google recommends submitting the change for applicable subdomains and www/non-www variants of the old domain. However, Change of Address is not required for an HTTP-to-HTTPS migration.

Verify tracking and production health

Make sure analytics, conversion tracking, consent tooling, forms, and other critical integrations are collecting data on the live site. Check server errors, uptime, response times, and infrastructure capacity as well.

Google notes that crawling can increase temporarily after a migration because Googlebot needs to process both old URLs and their new destinations. Ensuring the production infrastructure can handle that additional crawling helps the migration proceed without avoidable availability or performance problems.

Once these launch checks pass, the migration moves from implementation to observation.

Phase 4: Monitor SEO after the migration

After launch, monitor whether search engines are discovering the new URLs, dropping the old ones and transferring organic visibility as expected. Some ranking volatility is normal during a migration, so the goal is to distinguish temporary reprocessing from technical problems that require intervention.

Track organic traffic and search visibility

Compare post-migration performance against the baseline from Phase 1. In Google Search Console, watch:

• Organic clicks and impressions.
• Average positions for important queries.
• Performance of high-value landing pages.
• Branded versus non-branded search trends.
• Differences between device types and countries where relevant.

Google notes that URL migrations can cause temporary ranking fluctuations while it recrawls and reindexes the site. For a medium-sized website, Google says this process can take a few weeks, while larger sites may take longer.

That means a small short-term decline does not automatically indicate a failed migration. A sustained or disproportionate loss across important pages, however, warrants investigation.

Monitor indexing and URL replacement

Search Console should gradually show Google moving from the old URL set to the new one. During a URL migration, monitor both old and new sitemaps – over time, indexed URLs from the old sitemap should decline while indexing of the new URLs increases. Warnings about redirected URLs in the old sitemap are expected during this process.

Regularly check for:

• Important new URLs that remain unindexed.
• Old URLs that still return 200 instead of redirecting.
• Unexpected 404, 5xx or soft-404 responses.
• Canonical URLs Google selects differently from the ones you specified.
• Pages accidentally excluded by noindex or robots directives.

For a handful of business-critical pages, URL Inspection can help confirm Google's current view of the URL. For large sets of URLs, rely on sitemaps rather than repeatedly requesting individual indexing; Google notes that repeated requests do not make recrawling happen faster.

Keep checking redirects and crawl activity

Redirect testing should continue after launch rather than ending on launch day. New issues can surface as Googlebot reaches deeper or less frequently crawled URLs.

Monitor server logs or other crawl data where available to confirm that search bots are reaching the new site and that requests to old URLs receive the expected redirects. Also, track traffic on both the old and new sites, with old-site activity declining as the new site takes over.

Do not remove migration redirects as soon as traffic appears stable. Google recommends maintaining them for at least one year.

Compare conversions and site experience too

SEO visibility is only part of a successful migration. Compare organic conversions, engagement, and other business KPIs with the pre-migration baseline and continue monitoring production performance and Core Web Vitals.

Search Console and analytics answer different questions. Search Console shows how users discover the site through Google Search, while analytics shows what happens after they arrive. Looking at both makes it easier to determine whether a change originates in search visibility or in the new site's user experience.

The migration is complete when crawling, indexing, visibility and business performance have stabilized – and the team has verified that important old URLs consistently resolve to their intended new destinations.

How Pantheon helps reduce risk during complex website migrations

An SEO migration plan is only as strong as the development and deployment process behind it. Redirect maps, canonical rules, metadata, internal links and indexing controls all have to survive the move from development to production exactly as intended.

Pantheon gives development and SEO teams controlled environments for validating migration changes before launch and safeguards for the cutover itself for WordPress, Drupal and Next.js sites. Instead of treating SEO validation as a final pre-launch check, teams can build it into the same workflow used to develop, test, deploy and recover the site.

Pantheon supports that process with:

• Dev, Test, Live environments: Pantheon separates development, testing, and production so teams can validate templates, redirects, metadata, canonicals, structured data, and performance before changes reach the live site. Multidev can provide additional isolated environments for parallel workstreams.
• Structured launch support: Pantheon provides documented guidance for domains, DNS, HTTPS, redirects, launch testing and relaunches.
• Git-based deployment workflow: Code changes move through a version-controlled workflow from Dev to Test to Live, while the database and uploaded files are managed separately. That gives teams a clearer record of what changed and reduces the need for direct production development.
• Backups and recovery: Pantheon supports backups of code, databases, and files across site environments, giving teams recovery points if a migration introduces a serious issue.
• Performance monitoring and CDN: New Relic helps teams investigate application-level performance problems after launch, while Pantheon’s Global CDN handles caching and content delivery at the edge.

Together, these capabilities give SEO and development teams a more controlled path from pre-launch validation to production cutover and post-launch recovery.

And for teams that need hands-on help with the technical move, Pantheon Professional Services can migrate site code, databases, and files, assist with redirect handling, support user acceptance testing, resync content around launch, and provide launch support. Premium Migrations are also available for larger or more complex sites.

For instance, O2E Brands needed to move multiple Drupal sites from its existing hosting environment and worked directly with Pantheon’s migration team rather than managing the entire process internally. After the move, O2E Brands also reported uptime above 99.99% and lower ongoing site-management overhead.

Migrating all of our sites was a large undertaking, and we didn’t want to do it completely in-house. We had a really good experience with Pantheon’s migrations team. The process ran much smoother and was much less stressful than we expected, and the support was amazing.”

 – Ed Alvarez, Senior Drupal Developer at O2E Brands

Make SEO part of the migration plan from day one

A successful website migration preserves more than pages. It preserves the technical signals, URLs, content, and user journeys that search engines and visitors already rely on.

That is why an SEO website migration checklist should guide the project from the first inventory through staging, launch, and post-migration monitoring.

The infrastructure underneath that process matters too. Pantheon gives teams isolated development environments, Git-based deployments, backups, performance monitoring, and a structured path from development to production.

Ready for a faster, more reliable way to build, launch and manage WordPress and Drupal sites? Explore Pantheon today and see how its WebOps platform helps teams ship with confidence at scale!