The 22-Step SEO Checklist for Website Migration in 2026

Every SEO who has run more than a couple of migrations has the same story: a client or team assumes the new site “just needs to go live,” and three weeks later organic traffic is down 40% with no one quite sure why. It is almost never one catastrophic mistake. It is usually five small ones, a missed redirect segment, a robots.txt rule copied from staging, a sitemap still pointing at old URLs, that compound into a real ranking loss.

This is built to be the most complete, practical SEO checklist for website migration you will find, structured around the three points in a migration where things actually break: before you touch anything, the moment the new site goes live, and the weeks after launch when Google is still deciding how much to trust the new URLs. It also covers what most website migration checklists skip entirely: real redirect code you can copy, platform-specific notes for WordPress and Wix, a copyable checklist template, and what a migration means for how AI systems like ChatGPT, Perplexity, and Google’s AI Overviews see your site, not just classic search rankings.

What Counts as a “Website Migration” (And Why the Type Changes Your Risk)

Not every migration puts the same amount of ranking equity at stake, and treating a simple redesign with the same paranoia as a domain change wastes time you could spend elsewhere. The type of migration you are running should set the scope of your checklist.

Why Website Migrations Actually Lose Rankings

Google does not penalize migrations. What causes the visible traffic drop is almost always one of a small set of preventable technical errors, understanding them upfront makes the rest of this checklist make sense rather than feeling like an arbitrary list of tasks.

• Missing or incomplete redirects. Every unredirected old URL becomes a 404, and every incoming link and bit of ranking history pointing at it goes nowhere.
• Noindex tags left on from staging. The single most common launch-day failure: a staging environment’s noindex meta tag or robots.txt disallow rule ships to production untouched.
• Redirect chains and loops. Old URL to intermediate URL to final URL wastes crawl budget and can silently drop link equity at each hop.
• Metadata that never migrated. Titles and descriptions reverting to CMS defaults instead of the tuned versions that were ranking.
• A new site architecture that orphans previously well-linked pages. A page that ranked partly because of strong internal linking can lose that support if the new navigation and related-content links do not carry it forward.

Pre-Migration SEO Checklist: Before You Touch Anything

This is the phase that determines whether the rest of the migration goes smoothly, and it is also the phase teams under deadline pressure are most tempted to shortcut. Do not.

1. Benchmark Everything You Are About to Change

Export and save, outside the CMS you are migrating away from, your current organic traffic by landing page, your ranking keyword list, your indexed page count from Search Console, and your backlink profile. Without this baseline, “did the migration hurt rankings” becomes a guess instead of a measurement.

2. Crawl and Inventory the Current Site

Run a full crawl (Screaming Frog, Sitebulb, or a similar tool) of the live site before migration and export every indexable URL, its title, meta description, canonical tag, and internal link count. This crawl becomes the source list for your redirect map in the next step, missing this means guessing at URLs from memory, which is how pages get silently dropped.

3. Build a Complete Redirect Map

Map every URL from your crawl to its closest-matching URL on the new site, 1:1 where possible. “Closest matching” means actual topical equivalence, not just a convenient catch-all redirect to the homepage, redirecting everything to the homepage is treated by Google as close to not redirecting at all and forfeits the ranking value those pages built up.

4. Set Up a Staging Environment That Mirrors Production

Password-protect it, block it from search engines with both a site-wide noindex and a robots.txt disallow, and use it to validate every item in the launch-day checklist below before the real cutover. Set a calendar reminder to remove both blocks the moment the site actually goes live, this exact step is where most launch-day noindex disasters originate.

The Redirect Mapping Process, With Real Code

Most migration checklists tell you to “set up 301 redirects” without showing what that actually looks like. Here is the real implementation for the two most common server setups.

Apache (.htaccess), single-URL redirect:

Redirect 301 /old-page-url/ https://www.example.com/new-page-url/

Apache (.htaccess), pattern-based redirect for a moved directory:

RewriteEngine On
RewriteRule ^old-category/(.*)$ /new-category/$1 [R=301,L]

Nginx, single-URL redirect:

location = /old-page-url/ {
    return 301 https://www.example.com/new-page-url/;
}

• Always use 301, not 302, for a permanent migration. A 302 tells search engines the move is temporary, so they keep the old URL indexed and do not transfer ranking signals the way a 301 does.
• Avoid redirect chains. If page A redirects to B, and B is also being redirected to C, point A directly at C. Each extra hop adds latency and risks losing link equity along the way.
• Preserve query parameters used for tracking (UTM codes especially) unless you have a specific reason to strip them, losing them breaks attribution in analytics for anyone who bookmarked or shared a tagged URL.
• Never mass-redirect everything to the homepage. It is faster to set up, but it discards the topical relevance that made each page rank in the first place.

Launch Day SEO Checklist: The Critical Few Hours

Launch during a low-traffic window (commonly a weekend night) so you have time to catch problems before peak traffic hits, and work through this in order.

• Remove every noindex tag and staging robots.txt block the moment the new site is live, not “soon after.” This is the single highest-frequency launch-day mistake.
• Activate the full redirect map and spot-check a representative sample, homepage, a few category pages, a few deep individual pages, across the old URL list.
• Crawl the new live site to confirm titles, meta descriptions, canonical tags, and heading structure came across correctly and were not reset to CMS defaults.
• Generate and submit a fresh XML sitemap containing only your new, live, 200-status URLs with self-referencing canonicals, then submit it in Google Search Console.
• If the domain changed, use Search Console’s Change of Address tool on the old property to tell Google explicitly where the site moved, this is a distinct step from redirects and easy to forget.
• Verify analytics and tracking codes are firing correctly on the new site before you consider the launch complete, a broken tracking snippet means you fly blind during the most important monitoring window.
• Confirm SSL is properly configured with no mixed-content warnings if the migration included an HTTP to HTTPS switch.

Post-Migration SEO Checklist: The First 30, 60, and 90 Days

Migration SEO does not end at launch, most of the actual recovery and stabilization work happens in the weeks after, and the checklist changes as you move further from launch day.

How to Diagnose a Post-Migration Traffic Drop

A traffic dip after migration is common enough that you should not panic at the first sign of one, but you also should not assume it will fix itself. Work through this order.

1. Check the timing first. Does the drop line up precisely with the launch date, or with a known, unrelated Google algorithm update that happened to land the same week? These require completely different fixes.
2. Crawl the live site for 404s. A spike in 404 errors in Search Console’s Coverage report almost always means a gap in the redirect map, not a ranking penalty.
3. Check for an accidental noindex or robots.txt block. This single issue explains a large share of “we launched and rankings vanished overnight” cases.
4. Compare indexed page count before and after. A sharp drop in indexed pages points to a crawling or indexing block; a roughly stable count with lower rankings points more toward a ranking-signal issue, like lost internal linking structure.
5. Give genuine technical fixes 2-4 weeks to show results before concluding they did not work, Google needs to recrawl and reprocess the corrected signals, this is not instantaneous.

Schema Markup and Structured Data During a Migration

Structured data frequently gets rebuilt from scratch during a platform migration, and a broken or missing schema implementation on launch day is easy to miss because it does not throw a visible error to a normal site visitor.

• Re-validate every schema type that was live on the old site, Organization, Article, FAQ, Review, LocalBusiness, on the new site using Google’s Rich Results Test before and after launch.
• Confirm the WebSite and Organization schema’s url and @id values point to the new domain if it changed, stale @id references pointing at the old domain silently break the entity graph connecting your schema blocks together.
• Rebuild BreadcrumbList schema to match the new URL structure exactly, a breadcrumb schema that still reflects the old site hierarchy actively misleads search engines about your new site structure.

Example: WebPage Schema Confirming a Migrated URL (JSON-LD)

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "@id": "https://www.example.com/new-page-url/#webpage",
  "url": "https://www.example.com/new-page-url/",
  "name": "Page Title Here",
  "isPartOf": {
    "@id": "https://www.example.com/#website"
  },
  "datePublished": "2024-03-10",
  "dateModified": "2026-09-04"
}
</script>

Validate the updated markup with Google’s Rich Results Test immediately after launch, not days later, since a broken @id reference is invisible to visitors but very visible to search engines. If you are rebuilding schema from scratch on the new platform, our schema markup setup guide walks through the exact JSON-LD to use.

What a Migration Means for AI Search Visibility, Not Just Google Rankings

Classic SEO migration checklists were written before AI crawlers and AI Overviews became a meaningful share of how people find content, and most of them have not caught up. A domain or URL change affects how ChatGPT, Perplexity, and Google’s AI systems recognize your business as the same entity, not just how classic search ranks your pages.

• Check your robots.txt for AI crawler access (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) on the new site immediately, a robots.txt copied over from a locked-down staging environment can accidentally block them.
• Update sameAs links and cross-platform mentions if the domain changed, an AI system trying to confirm your business is the same entity it saw before relies heavily on these consistent cross-references.
• Keep your Organization schema’s name, logo, and description identical across the transition, a migration that quietly rewrites your business description breaks entity continuity right when you need it most.

We cover this in far more depth, including the full crawler-access and entity-consistency checklist, in our guide to AI search visibility strategy, worth reading before a migration, not just after. If you are also rethinking your broader search strategy alongside the migration, our GEO vs AEO vs SEO comparison explains how these disciplines fit together.

Common Website Migration Mistakes That Tank Rankings

• Redirecting everything to the homepage instead of building a real 1:1 redirect map, the fastest way to forfeit the ranking equity every individual page had built up.
• Shipping staging’s noindex tag or robots.txt block to production and not catching it until traffic has already visibly collapsed.
• Changing URL structure and domain in the same launch as a full redesign, stacking three high-risk changes at once makes it nearly impossible to isolate what caused any specific problem afterward.
• Skipping the pre-migration crawl and relying on memory or an old sitemap for the list of URLs that need redirects, this is how entire page categories get silently dropped.
• Declaring victory after 48 hours and moving on, real migration recovery is a 30-90 day process, not a launch-night checklist.
• Forgetting internal linking, a new site architecture that does not carry forward the internal links that supported key pages removes a ranking signal even when the redirect itself works fine.

Platform-Specific Notes: WordPress, Wix, and Other Site Builders

The core checklist above applies no matter what you are migrating to or from, but the actual mechanics of setting up redirects and clearing caches differ enough by platform to call out separately.

SEO Checklist for Website Migration on WordPress

WordPress gives you the most direct control over redirects and metadata of any platform on this list, which makes it forgiving if you use the right tools.

• Use a dedicated WordPress redirect plugin like Redirection or RankMath’s built-in redirection manager to bulk-import your redirect map from a CSV instead of hand-editing .htaccess for hundreds of URLs.
• If you are moving hosts rather than changing content structure, a migration plugin like All-in-One WP Migration or Duplicator handles the file and database transfer, but it does not replace the redirect map, plan for both separately.
• Watch for caching plugins serving stale pages after launch, purge LiteSpeed Cache, WP Rocket, or whatever caching layer you run immediately after the redirects go live.
• Regenerate your XML sitemap through RankMath or Yoast after the migration completes, rather than assuming it updates automatically the instant URLs change.

If your migration is specifically a hosting move rather than a URL or platform change, our dedicated WordPress host migration guide covers the file-transfer and DNS side step by step.

SEO Checklist for Website Migration on Wix

Wix migrations carry a different risk profile because you have less low-level control than WordPress gives you.

• Use Wix’s built-in 301 redirect manager under SEO Tools, it supports bulk CSV import on most plans, confirm your specific plan’s redirect limit before committing to a full migration.
• Re-verify site ownership in Google Search Console after a domain change, Wix’s verification method can require re-doing this step even when the underlying content did not change.
• Check Wix’s automatic sitemap (usually at /sitemap.xml) reflects the new URLs before resubmitting it in Search Console, Wix regenerates this automatically but not always instantly.
• Confirm mobile URLs match desktop URLs, Wix has historically had separate mobile optimization settings that can drift out of sync during a redesign.

Website Migration SEO Checklist Template You Can Copy

Use this as your final pass before, during, and after launch, and as a website migration SEO checklist template you can copy into a spreadsheet or save as a PDF checklist for your team to work through item by item. Every item links back to the fuller explanation above.

Before migration (9 items)

• Benchmark current organic traffic, rankings, and indexed page count
• Export a full backlink profile for post-migration comparison
• Crawl and inventory every indexable URL on the current site
• Build a complete 1:1 redirect map, not a homepage catch-all
• Set up a password-protected, noindexed staging environment
• QA every redirect on staging before the real cutover
• Confirm metadata (titles, descriptions, canonicals) is ready to migrate, not reset to defaults
• Re-validate all schema markup on staging
• Set a launch window during low-traffic hours

Launch day (7 items)

• Remove every noindex tag and staging robots.txt block
• Activate the full redirect map and spot-check a representative sample
• Crawl the live new site to confirm metadata and headings came across correctly
• Generate and submit a fresh XML sitemap of new, live URLs
• Use Search Console’s Change of Address tool if the domain changed
• Verify analytics and tracking codes are firing correctly
• Confirm SSL and check for mixed-content warnings

Post-migration, 30-90 days (6 items)

• Monitor Search Console’s Coverage report daily for the first two weeks
• Compare traffic and rankings against your pre-migration benchmark weekly
• Fix any redirect chains, loops, or gaps as they surface
• Confirm backlinks are landing on the correct redirected URLs, not 404s
• Re-check AI crawler access and entity consistency (schema, sameAs links)
• Escalate to a full technical audit if traffic has not stabilized by day 60

Frequently Asked Questions

Final Verdict

A website migration is not inherently risky to your SEO, an unplanned one is. Every traffic-loss story in this article traces back to a small number of preventable causes: an incomplete redirect map, a noindex tag that should have been removed, metadata that never got carried over, or a team that stopped watching after the first 48 hours instead of the first 90 days.

If you are about to migrate, the highest-value place to spend your limited prep time is the redirect map and the staging QA pass, that single combination prevents the majority of the failures covered here. If you already migrated and traffic dropped, work through the diagnosis section in order rather than guessing, the cause is almost always findable, and almost always fixable. For the WordPress-specific side of a host or platform move, our guide to migrating WordPress to a new host covers the platform-level steps this checklist assumes you have already handled.