An SEO website migration is one of the highest-risk events an ecommerce brand can undertake. Done well, it protects your rankings and sets the foundation for long-term organic growth.
Done poorly, it can wipe out years of accumulated search equity, sometimes permanently.
This checklist covers the critical steps your team needs to complete before going live with your website migration.
Types of SEO Migrations
Before you open a spreadsheet or touch a single redirect, it’s worth being clear on what kind of migration you’re actually doing. The steps below apply broadly, but the effort, the risk, and the people you need involved vary significantly depending on scope.
- A domain name migration moves your entire site to a new URL. Every backlink, every indexed page, every ranking signal has to follow you. The SEO risk is high and the redirect map is non-negotiable.
- A redesign or rebrand migration changes both the look and structure of your site at the same time. This is one of the riskier types, not just because URLs change, but because the CMS build can limit what content you’re able to add or optimise later. Any SEO requirements that aren’t scoped before the design is locked will need to be retrofitted, and that costs time and budget.
- A CMS migration moves your site from one platform to another, for example Neto to Shopify. These come with the highest technical complexity because you’re working with a new tech stack from the ground up. SEO needs to be part of the platform decision, not an afterthought once development has started.
- A server migration changes your hosting infrastructure without touching the site itself. The main SEO concern is speed. Your SEO team doesn’t need to lead this one, but they should check performance before and after.
- A design-only migration with minimal content changes is the lowest-risk option. If your URL structure stays the same and fewer than 20% of your on-page content is changing, your existing SEO equity is largely intact. An SEO review of the wireframes before build is still worth doing.
- A content migration involves restructuring, consolidating, or merging existing pages. This sits mostly within SEO and can usually be handled without heavy dev involvement, though it’s worth keeping dev in the loop on any technical constraints.
The type of migration you’re running should determine who’s involved and how deep the process goes. Skipping that conversation upfront is one of the most common reasons migrations go over budget or require work to be redone.
1. Benchmark Your Existing Site
For a full redesign, CMS change, or domain move, you’ll want SEO, design, and development aligned before anything is built.
For a server migration or a design refresh with no URL changes, the process is lighter and the team is smaller. Getting the right people involved at the right time is what separates a clean migration from one you’re still fixing months later.
Before any structural changes are made, document everything. Pull a full URL inventory by cross-referencing your XML sitemap, Google Search Console coverage reports, and GA4 organic traffic data. Identify which pages drive the most sessions, revenue, and inbound links – these are your highest-risk assets and require the most careful handling during the migration.
Further, before you move, export all historical query and page performance data from your existing GSC profile. Once the domain is migrated, the old property will stop collecting new data and Google only retains 16 months of history. Once that window closes, that data is gone permanently.
SEO doesn’t operate in isolation. Before launch, audit and update URLs across every channel that references your old site: Google Ads and Meta Ads destination URLs and UTM parameters, automated email flows, and social media bios and pinned posts. Sending paid traffic through a 301 redirect can strip tracking parameters like UTMs and GCLIDs, breaking attribution and slowing landing page load times.
2. Build and Lock Your Redirect Map
Your redirect strategy is the single most critical factor in preserving SEO equity during a migration. Not every page needs a redirect. Outdated pages with zero traffic, expired promotions, or irrelevant legacy content should either be allowed to return a 404 or be deliberately served a 410 (Gone) status code. A 410 tells search engines the page has been permanently removed, which helps conserve crawl budget and keeps your new site’s architecture clean. Only redirect pages where a relevant destination actually exists.
Avoid the temptation of wildcard or “fuzzy match” redirects – where multiple legacy pages are bulk-redirected to a single category page or the homepage. Search engines treat this as a soft 404, interpreting the original content as deleted and stripping the associated rankings immediately.
Key rules for your redirect map:
- Use 301 (permanent) redirects only – never 302s
- Map every URL on a strict one-to-one basis
- Eliminate redirect chains (A → B → C adds authority decay at every step)
- Enforce consistent HTTPS and lowercase URL formatting
3. Secure Your Staging Environment
Your new site must be built and tested in a staging environment before launch. If search engine bots discover and index your staging site, Google will treat your live site as duplicate content on launch day – triggering algorithmic penalties.
Protect the staging environment with:
- Server-level password (htaccess) protection
- A global noindex meta tag across all page templates
Important: just before running pre-launch crawl audits, temporarily remove password protection to allow your SEO tools to access the staging environment. Confirm the noindex tags are functioning correctly, then restore protection until you’re ready to go live.
4. Audit Technical SEO Elements
Run a full technical crawl of the staging environment using a tool like Semrush or Ahrefs. You are looking for:
- Broken internal links and orphan pages
- Update all internal links to point directly to the final destination URL on the new site. Do not rely on 301 redirects to handle internal navigation.
- Missing or duplicate meta titles and descriptions
- Incorrect or missing H1 tags
- Schema markup that hasn’t transferred correctly
- Rogue noindex tags in X-Robots-Tag HTTP headers (these override HTML tags and will de-index your site)
- Invalid canonical tags – ensure these use absolute URLs and that only one canonical tag exists per page
Also audit your image alt text. Alt attributes must transfer to the new CMS intact. They should be descriptive, under 125 characters, and written as natural sentences – not keyword strings.
5. Verify Core Web Vitals on the New Build
Technical performance is a primary ranking factor in 2026. A migration that causes your site to regress on Core Web Vitals will result in a ranking regression, regardless of how strong your backlink profile is.
Before launch, confirm your staging environment meets these thresholds:
Metric | Good Threshold |
Largest Contentful Paint (LCP) | ≤ 2.5 seconds |
Interaction to Next Paint (INP) | ≤ 200 milliseconds |
Cumulative Layout Shift (CLS) | ≤ 0.10 |
Pay particular attention to layout stability throughout the full user session — not just on initial page load. Unexpected visual shifts during scrolling and interactive state changes are now factored into Google’s performance evaluation.
6. Prepare Your XML Sitemaps
On launch day, submit two sitemaps simultaneously via Google Search Console:
- Your legacy sitemap: containing all old URLs, which forces crawlers to rapidly discover and process your 301 redirects
- Your new sitemap: containing all updated URLs to accelerate indexation of the new site structure
Each sitemap file must use UTF-8 encoding, contain fewer than 50,000 URLs, and remain under 50MB.
Also verify your robots.txt file references the new sitemap and does not carry over any Disallow: / directives from the staging environment – a mistake that would block search engines from crawling your live site entirely.
Also test the new robots.txt file explicitly to confirm it is not accidentally blocking CSS files, JavaScript, or CMS-specific cart and checkout functionality. Blocking these resources can prevent Google from rendering your pages correctly and cause indexation issues that are easy to miss on launch day.
7. Verify Your New Google Console Property
If your migration involves a domain change or a move from HTTP to HTTPS, you must create and verify the new Google Search Console property before launch day. You cannot submit a sitemap or use the Change of Address tool until the new property is verified. Doing this early prevents any launch-day bottlenecks.
8. Lower Your DNS TTL Before Launch
If your migration involves switching hosting providers, lower your DNS Time to Live (TTL) values with your current registrar at least 48 hours before the IP switch. This ensures your updated DNS records propagate across global servers quickly, minimising potential downtime for users at launch.
How deep you go depends on what you’re changing.
A minimum viable migration covers the essentials: a full URL inventory, a clean one-to-one redirect map, a protected staging environment, and both sitemaps submitted on launch day. This is appropriate for lower-risk scenarios like a server move or a design refresh where URLs and content are staying put. SEO leads it, dev involvement is light.
An in-depth migration goes further. It includes a full technical audit, keyword research and mapping, a review of site architecture before build, SEO input on wireframes at both low and high fidelity, content requirements scoping across key pages, and post-launch monitoring across an 8 to 12 week stabilisation window. This is the standard for domain changes, CMS migrations, and full redesigns where your organic performance is genuinely at stake.
The difference between the two isn’t just effort. It’s timing. An in-depth migration requires SEO input at the design stage, not just before go-live. If the design is finalised before SEO has reviewed it, you’ll likely end up with content space limitations, structural compromises, and tasks that need to be done twice.
Launch Day and Beyond
- Ready for your new website to go live? Here’s what you need to do.The moment your site goes live, immediately remove all staging noindex tags and password protection.
- Submit both XML sitemaps in Google Search Console. If you are changing your root domain, activate the Change of Address tool in Search Console to formally notify Google of the transition.
- Plan for an 8-12 week stabilisation window. Some ranking fluctuation during this period is normal as search algorithms re-crawl and re-evaluate the domain. If your redirects are clean, your metadata is intact, and your Core Web Vitals are strong, rankings will stabilise and recover.
- Monitor server logs daily in the first two weeks for 404 errors, unusual crawler behaviour, and response latency. Verify that GA4 tracking and conversion events are firing correctly on the new environment.
- 301 redirects pass authority, but a direct link is always stronger. Identify your top 50-100 most valuable external backlinks pointing to the old domain and contact those webmasters directly to request a URL update. Prioritise any page that holds significant link equity.
- If the business has physical locations, update the website URL on the Google Business Profile and core local citation directories including Yelp and Apple Maps on launch day. These references do not update automatically and are a commonly overlooked step in ecommerce migrations.
Talk to the SEO Experts at Pattern
A site migration is not a set-and-forget project. It requires meticulous planning, rigorous pre-launch testing, and close monitoring after go-live. If you want support executing a migration that protects your organic performance, contact us.
