SEO Site Migration Checklist for Enterprises

A site migration changes core parts of your website. Those changes can affect how search engines crawl, index, and rank your pages. This SEO site-migration checklist covers the work that keeps rankings, organic revenue, and analytics intact through the move. It applies to a replatform, redesign, domain change, or URL restructure.

Migrations carry downsides when SEO isn't built into the plan. Google notes that combining a move with URL or design changes can cause a temporary traffic loss. Its systems need time to relearn and reassess each page. A structured checklist can help enterprise teams keep that dip small and short.

This guide walks through every phase of an enterprise migration. You'll plan and benchmark before launch, then run SEO checks on staging. On launch day you confirm the essentials, then monitor through the first 30 to 90 days. Each phase lists the specific tasks, owners, and checks that protect organic performance.

What is a website migration?

Awebsite migration is a change to a core part of your site's infrastructure. It often means moving from one hosting environment or platform to another. Migrations change how search engines crawl and read your content, so SEO belongs in the plan from the start.

Migrations come in several forms, and each one affects search differently:

• Platform or content management system (CMS) change: Moving from one platform to another, such as a replatform to Shopify, changes templates and URL structures. (Templates are the layouts behind page types like your product, collection, and content pages.) Plan redirects and template-level SEO checks.
• Domain change: Switching domains needs full redirect coverage and a Change of Address request in Google Search Console.
• URL or structure change: Reorganizing folders or URLs requires a complete URL map. Redirect each old URL to its new one so the page keeps the search ranking it built up.
• Site redesign or rebuild: New templates and content can change headings, internal links, and on-page signals, even when the URLs stay the same.
• HTTP-to-HTTPS move: Moving to HTTPS changes every URL, so each one needs a redirect to its secure version.

When to migrate your website

Migrations take time and careful planning. They make the most sense when a clear need drives them, like the three situations below.

You're rebranding

A rebrand brings substantial changes to your site: navigation, imagery, and product collections. It's a natural point to rethink your site's structure and content. Migrate if your new brand needs a different website experience to match.

You need functionality your platform doesn't support

To sell subscriptions, build a custom design, or integrate a specific analytics tool, you need a platform that supports it. Review your current platform's apps and developer options before you decide. Sometimes a third-party app fills the gap without a full migration.

Your site has performance issues

Slow load times can raise bounce rates. Crawl problems can stop search engines indexing key pages. When fixing them inside your current platform isn't working, migrating can be more effective than continuing to patch the old one.

Online gardening retailer Willemse needed a more flexible, mobile-friendly platform. After migrating to Shopify, they doubled their site's loading speed on launch day. They also measured a 10% rise in organic traffic the next quarter.

Why SEO matters during a site migration

A migration changes the URLs, redirects, content, and internal links that enterprise SEO depends on. Below, you’ll see five major risks that can do the most damage when SEO isn't part of the plan (and how to mitigate them).

Duplicate content and canonical risk

If old and new pages stay live at the same time, search engines can't tell which version is authoritative. Set canonicals and redirects so only one version is indexable.

Crawlability and indexation risk

A new site can drop out of the index fast if it launches with crawl blocks still active from staging. Changed URLs with no redirects do the same. Make the new site crawlable on day one. Redirect every changed URL to its new address with a 301, so search engines and shoppers reach the new page.

Content and metadata risk

When new pages lose content, title tags, or headings, search engines may rank them below the originals. Recreate on-page SEO elements template-by-template before launch.

Analytics and revenue-tracking risk

Broken tags and missing events leave you blind to how the new site performs, right when you need the data. Plan the tracking migration and verify that events fire after launch.

Backlink and authority risk

Backlinks will initially point to old URLs. Without redirects, the authority they pass is lost and so are the rankings it supports. Redirect your linked pages and update the highest-value links directly.

SEO site-migration checklist

This checklist runs in four phases, from early planning to post-launch monitoring. It puts the technical moves in a sequence built for an enterprise ecommerce migration.

Phase 1: Prep checklist (6–12 weeks before launch)

Use this window to set benchmarks, plan SEO best practices, and back up the data you'll compare against after launch.

Set migration goals and success metrics

Define what the migration must protect and what it should improve. Write down target numbers for organic sessions, keyword rankings, conversion rate, and revenue. Add the date you expect to hit each one. These targets become the benchmark you measure against after launch.

Assign owners across teams

Name a single owner for each workstream: SEO, engineering, analytics, content, and ecommerce operations. Each owner needs a defined task list and visibility into the shared launch timeline. Clear ownership will keep redirects, tags, and metadata from slipping through cross-team handoffs.

Create a rollback plan

Decide in advance how you'll revert if launch goes wrong. Document the trigger conditions plus the steps to restore the previous site. Also define who can authorize the call. A rollback plan will turn a bad launch into a delay rather than a crisis.

Benchmark traffic, rankings, and Core Web Vitals

Record 12 months of organic sessions, keyword rankings, conversion rate, and revenue for your key templates. Capture desktop and mobile Core Web Vitals for the homepage, collection pages, product pages, and checkout-adjacent pages. Store these benchmarks so you can prove parity or spot regressions after launch.

Crawl the current site and export every URL

Crawl your live site with Screaming Frog SEO Spider or a comparable crawler. This builds a full inventory of pages and internal links. Pull the same URLs from Google Search Console, GA4, your XML sitemaps, and your CMS export. Multiple sources will catch pages that a single crawl misses, including orphaned and high-traffic URLs.

Identify high-value pages and backlink assets

Flag the URLs that earn the most organic traffic, revenue, and external links. These pages should get priority for redirect testing and post-launch monitoring. Export your backlink profile, too, so you know which referring domains to update later.

Build the URL map

Map every old URL to its destination on the new site. Classify each one as keep, redirect, consolidate, or remove, and record the matching 301 target. Pay closest attention to your high-value pages, where a broken mapping costs the most traffic.

Plan the analytics and tag migration

List every tracking code, tag, and integration the new site needs: GA4, your tag manager, and conversion pixels. Note who owns each one and how you'll verify that it fires after launch. Missing tags will create blind spots exactly when you need data most.

Audit structured data, hreflang, and canonicals

Inventory the structured data, hreflang tags, and canonical tags on your current pages. You'll need to recreate each one on the new site. Note your robots.txt directives and any noindex rules. Carrying these over correctly will protect rich results and keep regional pages pointing to the right URLs.

Phase 2: Staging checklist (before launch)

Complete these checks on the staging build, before any pages of the new site reach search engines.

Keep staging out of the index

Protect your staging site with password protection or a noindex rule while it's private. Robots.txt alone won't keep pages out of Google. Blocking a page in robots.txt can stop Google from seeing the noindex rule. The URL can then still get indexed through other signals.

Apply metadata, headings, and alt text

Add title tags and meta descriptions to every template, and confirm they fit within recommended length limits. Check that H1s and headings carry the right keywords and that images have descriptive alt text. Replace any placeholder copy like "Test page" before it ships.

Test 301 redirects and status codes

Implement the redirects from your URL map and test them on staging. Confirm that old URLs return a single 301 to the correct destination, with no chains or loops. Check that live pages return 200 and that removed pages return 404 or 410.

Update internal links, canonicals, and hreflang

Repoint internal links to the new URLs so they don't pass through redirects. Set self-referencing canonical tags on the new pages. Update hreflang tags to the new domains where you run regional storefronts. Recreate and validate your structured data markup before launch.

Prepare the XML sitemap and robots.txt

Generate an XML sitemap that lists only the new, canonical URLs. Set robots.txt to allow crawling of the pages you want indexed. On Shopify, the sitemap.xml file is generated automatically and includes your products, product images, pages, collections, and blog posts. Shopify stores also have a default robots.txt file.

Test mobile rendering and Google Core Web Vitals

Confirm Google can render your key templates on mobile. Mobile-first indexing means the mobile version is what Google indexes and ranks. Use PageSpeed Insights and Search Console's URL Inspection tool, plus manual checks on a phone. Benchmark Core Web Vitals against Google's thresholds: Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) under 0.1.

Test checkout, forms, search, and integrations

Place test orders to confirm checkout works from product page to order confirmation. Check that forms are submitted and the onsite search returns results. Collection filters need to behave as well. Verify that apps and third-party integrations carry over and fire correctly.

Phase 3: Launch-day checklist

Work through these checks within 48 hours before the new site goes live:

☐ Remove the temporary noindex rules and crawl blocks added on staging, so search engines can index the new site.
☐ Confirm status codes: Live pages return 200, redirected URLs return 301, and removed pages return 404 or 410.
☐ Submit the new XML sitemap in Google Search Console to speed up discovery.
☐ Run Google's Change of Address tool if the domain changed, so Google treats the new site as the successor.
☐ Verify key events are firing in GA4 DebugView, which shows conversions and events in real time.
☐ Spot-check redirects on your highest-traffic, highest-revenue, and most-linked pages.

Phase 4: Post-migration checklist (first 30–90 days after launch)

Most ranking and traffic problems surface in the weeks after launch, once search engines have fully reprocessed the new site. Check these through the first 30 to 90 days, with weekly reviews early on.

Monitor rankings, traffic, revenue, and conversion rate

Compare live performance against your pre-launch benchmarks, weekly at first. Watch organic sessions, keyword rankings, conversion rate, and revenue for your priority templates. Sudden drops tend to point to a redirect, indexing, or tracking problem you can still fix.

Review indexation and crawl issues

Check the indexing and crawl reports in Search Console for errors and coverage gaps. Confirm the new URLs are getting indexed and the old ones are dropping out. Watch for spikes in 404s, soft 404s, or pages excluded by noindex.

Fix broken links, redirect chains, and 404s

Crawl the live site again and compare it to your premigration inventory. Repair internal links that still point to old URLs, and collapse any redirect chains into a single hop. Set up redirects for high-value 404s that slipped through the URL map.

Request indexing for priority URLs

Use the URL Inspection tool in Search Console to request indexing for your most important pages. This nudges Google to crawl them sooner than it might on its own. Prioritize the high-value pages you flagged during prep.

Update backlinks and owned external links

Reach out to high-authority sites linking to your old URLs and ask them to update the link. Fix the links you control yourself: social profiles, business listings, email signatures, and ad destinations. Direct links carry more value than links that pass through a redirect.

Run a 30-day post-launch SEO audit

Thirty days in, run a full technical SEO audit to catch issues the weekly checks missed. Review redirects, canonicals, structured data, metadata, and Core Web Vitals against your benchmarks. If traffic hasn't recovered, work through a structured approach to recovering organic traffic after a web migration.

Common SEO migration mistakes to avoid

Each of these mistakes is avoidable with the checklist above. Watch for them as you plan and launch.

• Launching with noindex or robots.txt blocks still active: A leftover noindex tag or robots.txt block can hide the new site from Google. Remove staging crawl blocks first thing on launch day.
• Redirecting deleted pages to irrelevant pages: Mapping removed URLs to an irrelevant page wastes their value and can trigger soft 404s. Redirect to the closest relevant page, or return 410 when nothing fits.
• Forgetting internal links and canonicals: Internal links that pass through redirects will slow crawling and dilute signals. Repoint them to the new URLs and set self-referencing canonicals.
• Losing metadata, schema, or hreflang: Dropped title tags, schema, or hreflang tags cost rankings and rich results. Carry them over and validate before launch.
• Not testing checkout and analytics: A migration that breaks checkout or tracking costs revenue and hides the damage. Test transactions and confirm events fire before and after launch.