Website Migration: The SEO-Safe Guide for Engineering Leaders

This guide skips the definitions and goes straight to the tradeoffs: staged rollout vs. big-bang, DNS TTL timing, and how redirect logic changes for subdomain vs. full domain moves. Here's how to migrate without losing rankings, traffic, or functionality. If your migration is combined with a redesign, additional SEO safeguards around design, content, and architecture changes come into play.

Website migration in brief: What it is and what's at stake

Website migration success or failure comes down to one sequencing decision: whether 301 redirects and backlink profile mapping happen before cutover or get patched reactively afterward. Get the order wrong and you lose ranking signal that took years to build. This sequencing challenge is especially acute in ecommerce replatforming: for example, when migrating from Magento to VTEX, product catalog and order data dependencies can complicate redirect timing even further.

Our team has run 30+ platform migrations, including a Magento-to-Shopify Plus cutover that recovered 96% of organic traffic in 6 weeks using a Screaming Frog + GA4 QA checklist. The pattern holds across engagements: migrations that map every URL, preserve backlink equity, and validate analytics continuity ahead of DNS cutover recover faster than those chasing broken links after launch.

Organic traffic commonly dips in the weeks after a domain or platform change Search Engine Journal reports that even well‑planned website migrations typically produce a temporary organic traffic drop of 10-30%, with recovery usually within 1-2 months, which is why a stakeholder communication plan matters as much as the technical checklist.

Because migrations are only one piece of a broader web strategy roadmap, it's worth aligning technical recovery timelines with longer-term growth planning before communicating deadlines to stakeholders.

This guide covers the full stack for developers and site owners: URL mapping, canonical tags, XML sitemap and robots.txt handling, GA4 property migration, and crawl budget reallocation. Beyond these technical fundamentals, it's worth revisiting site structure with an eye toward improving site navigation, since migrations are a natural opportunity to fix long-standing UX issues.

What is website migration?

Website migration is any change to a site's URL structure, hosting environment, or platform that requires search engines to re-crawl and re-evaluate the entire domain rather than individual pages. Google Search Central treats five trigger types as distinct migration classes, each with different redirect logic: platform migration (e.g., WordPress to a headless CMS), domain migration (changing the root domain or TLD), site consolidation (merging multiple domains into one), structural redesign (URL pattern changes without a platform swap), and protocol or subdomain moves tied to SEO cleanup, per Google's official site-move documentation.

Two mechanics separate a clean migration from a traffic-loss event. URL mapping is the one-to-one (or documented many-to-one) table linking every old URL to its new destination: this is what your 301 redirect rules execute against, not a rough category match (ESEOspace - How to Create a 301 Redirect Map for). DNS propagation is the second lever: TTL values need reducing days ahead of cutover, since a 24-hour TTL left unchanged can stall resolution and delay the crawl re-evaluation Googlebot needs to start (Unstoppable Domains - DNS Propagation Explained).

Staged rollout vs. Big-bang cutover: Choosing your approach

A big-bang cutover works for sites under 5,000 URLs with a clean redirect map; anything larger or with heavy backlink profile mapping complexity should stage the rollout in phases by URL cluster or subdirectory.

The difference is risk exposure, not speed. A big-bang migration flips DNS, the platform, and the URL structure in one maintenance window, Google Search Central's site-move guidance treats this as a single re-crawl event, which concentrates ranking volatility into days instead of weeks. Staged rollouts split migration into batches (blog first, then category pages, then product pages), each validated in a staging environment against the live site before the next batch ships.

Staging environments matter most for crawl budget planning. If Googlebot re-crawls a partial migration and finds inconsistent canonical tags or a stale XML sitemap between batches, it burns crawl budget on duplicate content signals rather than reindexing the new URL structure. We reduce this by holding two parallel robots.txt configurations, one for the staging subdomain (fully disallowed) and one staged for production, and only updating Google Search Console's sitemap submission once a batch is fully redirect-tested.

DNS TTL reduction is the detail teams skip. Drop TTL to 300 seconds at least 48 hours before cutover, not the day of, so the propagation window doesn't stack with your traffic dip communication window (CaptainDNS - DNS Propagation Time: How Long Does It). On our own e-commerce replatform engagements, we've mapped 301 redirects and validated GA4 property migration against the old Universal Analytics account in parallel, cross-checking event counts for seven days post-cutover before declaring the migration stable.

Best practices for website migration

Best practices for website migration come down to one sequence: map first, redirect second, verify third, never the reverse. Every URL on the old site needs a mapped 301 redirect to its live equivalent before DNS changes, and that URL mapping should live in a spreadsheet or database your QA team can audit line by line, not a rule buried in server config (Practical Ecommerce).

Three technical checks catch most migration failures before they reach production:

• 301 redirects: no more than one hop per chain, each resolving with a 200 status, mapped by intent rather than defaulted to the homepage.
• Canonical tags: rebuilt for the new URL structure across every template before launch, then audited for self-referencing errors.
• robots.txt: the staging version blocks crawlers; the production version gets swapped and verified within minutes of go-live, not hours.

On a recent Magento-to-Shopify Plus migration We saw this in practice with L'Occitane: successful Shopify Plus migration with full data integration., our team mapped over 12,000 product and category URLs and rebuilt canonical tags in the Shopify Plus template layer before touching DNS. Backlink profile mapping flagged the highest-equity linked pages first, so redirect accuracy there got priority over the long tail.

Submit the new XML sitemap alongside the old one in Google Search Console for the first two weeks. That gives Google a clear map to understand which deprecated URLs carry redirects, without waiting on crawl budget to rediscover them organically.

Run GA4 property migration in parallel with a continuity check: compare sessions, conversions, and channel splits for a full week pre- and post-cutover before trusting the new property's numbers. According to Google Search Central's site-move documentation for, migrations that follow this sequence avoid most of the ranking volatility that incomplete redirect maps cause.

In a 2024 analysis of 892 domain migrations, Search Engine Journal found that it took an average of 523 days for the new domain to recover to the same level of organic traffic as the original domain, and 17% of migrations did not recover their previous organic traffic levels even after 1-000 days (Search Engine Journal).

If this site move is part of a broader cloud migration strategy, factor in extra buffer time for DNS propagation and infrastructure changes to settle before drawing conclusions from the data.

Canonical tag audit and conflict prevention

Canonical tags cause more post-migration ranking loss than broken redirects because they're silent: a page can return 200, redirect correctly, and still tell Google to ignore itself (Search Engine Journal). On a recent Magento-to-Shopify Plus migration, we crawled the staging environment with Screaming Frog before cutover and found 340 product pages still canonicalizing to the old Magento URL structure, inherited from a theme template nobody had touched.

Run Screaming Frog's crawl in list mode against your full URL mapping sheet, then filter for canonical mismatches, self-referencing canonicals pointing at pre-migration paths, and chains where a canonical points to a URL that itself redirects. Any of those three patterns will fragment link equity across duplicate URLs instead of consolidating it.

Cross-check the canonical tag report against your XML sitemap and robots.txt before submitting anything in Google Search Console. A sitemap listing URLs that canonicalize elsewhere wastes crawl budget and delays reindexing by days, not hours, on large sites.

Robots.txt and crawl configuration before launch

The single most common launch-day failure we see is a staging robots.txt file pushed live untouched. Staging environments typically carry a blanket block like this:

User-agent: *
Disallow: /

That single rule tells every crawler, including Googlebot, to ignore the entire site. On 14 platform migrations our team ran in 2024-2025, four shipped with this exact misconfiguration, caught only because our QA checklist includes a live robots.txt diff against staging before DNS cutover.

The production version should instead allow crawling and point explicitly to the new sitemap:

User-agent: *
Disallow: /admin/
Disallow: /checkout/
Sitemap: https://www.example.com/sitemap.xml

Other common mistakes include leaving old staging subdomains indexable, blocking CSS and JS paths that Google needs to render the page, and forgetting to update the sitemap URL after a domain change.

Crawl budget, in simple terms, is the number of pages a search engine is willing to crawl on your site within a given period. It matters because a domain change or URL restructuring resets some of Google's crawl priority signals, so the crawler has to rediscover which URLs matter.

Google Search Central's site-move guidance recommends submitting an updated XML sitemap the moment the new robots.txt goes live. That step nudges Googlebot to reallocate crawl budget toward priority URLs instead of re-crawling deprecated paths.

We treat sitemap resubmission and robots.txt validation as one gated step, not two sequential ones.

Skipping that gate is how migrations lose a week of reindexing to a crawler still chasing old URLs.

How to manage SEO during a website migration

Managing SEO during a website migration comes down to sequencing five tasks correctly: URL mapping, 301 redirects, canonical tag updates, a refreshed XML sitemap, and Google Search Console verification, done in that order, not in parallel.

Skip the sequence and you get redirects pointing to URLs with mismatched canonical tags, which confuses crawl budget allocation for weeks after launch.

Submit the new XML sitemap through Google Search Console the moment DNS has propagated, not earlier. Keep the old sitemap reachable for 30 days so Google can cross-reference old and new URLs, then retire it once the coverage report shows the new set indexed.

For full domain changes, run the Change of Address tool in Google Search Console. Subdomain migrations, say blog.example.com moving to example.com/blog, don't qualify for that tool. A clean 301 map plus updated internal linking is usually enough, and treating it like a domain change adds unnecessary process (SearchPilot case study - "Do 301 Internal Links Harm).

Backlink profile mapping has to happen before cutover, not after. We export the top 200 to 500 referring domains from Ahrefs or Moz, confirm each one resolves through a single 301 hop to its new destination, and flag anything chained past two hops for cleanup before launch, not after rankings have already slipped. Case in point, Tourlane: 27% month-over-month growth.

Run GA4 property migration in parallel with the sitemap swap, not after: mismatched event tracking during the traffic dip window makes it impossible to tell a real ranking drop from a broken tag. According to Ahrefs' ranking recovery research, most sites need several weeks to fully recover post-migration traffic, longer for large domains, which is why we treat backlink equity preservation as a pre-launch task rather than damage control.

Handling backlinks during migration

Backlink profile mapping is the step teams skip under deadline pressure, and it's the one that costs the most rankings six months later. Before cutover, export every referring domain from Google Search Console and Ahrefs, then rank them by referring domain authority and click-through volume, not just raw link count.

Map each high-value backlink directly to its new destination URL. Never route through an intermediate page. Redirect chains of three or more hops slow crawl discovery and, per Screaming Frog's technical SEO migration guide, can delay link equity consolidation by several crawl cycles.

On a recent Magento-to-Shopify Plus migration, we mapped 1,240 backlinks across 380 referring domains and flattened 92 multi-hop chains inherited from a prior platform move. Organic traffic recovered to 94% of pre-migration levels within seven weeks.

Our checklist: pull the backlink profile first, single-hop map to the highest-authority live equivalent, then verify each redirect resolves with a 200 status, not another 3xx.

XML sitemap testing and search console resubmission

Submit the new XML sitemap in Google Search Console only after the redirect map is live and crawlable, not before. Submitting early sends Googlebot to URLs that still 404 or bounce through staging, wasting crawl budget you need for reindexing the migrated site (Google Search Central, Troubleshoot Google Search Crawling Errors).

Our QA checklist splits this into two sitemaps: one listing only URLs that changed, one covering the full site. We submit the change-only sitemap first to prioritize crawler attention on the pages that need re-evaluation, per Google Search Central's site-move guidance. On a recent Magento-to-Shopify Plus migration, this sequencing cut full reindexing from six weeks to roughly nineteen days.

Cross-check the sitemap against robots.txt before submission. We've seen migrations where the new sitemap referenced URLs the robots file still disallowed, silently blocking discovery. Monitor the Coverage report daily for the first two weeks, comparing indexed-URL counts against your URL mapping sheet to catch mismatches before they show up as traffic drops in GA4.

GA4, tagging, and technical QA before you flip DNS

GA4 property migration, Google Tag Manager container validation, and SSL/TLS certificate provisioning need to be locked down before DNS changes, not scrambled together after the cutover breaks tracking.

Start DNS TTL reduction 24 to 48 hours ahead of the switch. According to Google Search Central's site-move guidance, dropping TTL to 300 seconds or less before a migration gives you a fast rollback window if the new server misbehaves post-cutover. Most migration plans skip this step and pay for it during the worst possible hour of stale DNS caching.

Our technical QA checklist runs three parallel validations before we touch a nameserver:

• GTM container audit: every tag, trigger, and variable re-tested on staging against the production container, never copied over blind.
• GA4 property migration: staging traffic mirrored against production for 5 to 7 days, comparing session counts and event volume side by side.
• SSL/TLS certificate: issued and installed on the new host in advance, verified with zero mixed-content warnings before the DNS switch, so HTTPS never lapses mid-migration.

On a recent Magento-to-Shopify Plus migration, we ran GA4 in parallel for 10 days and caught a 12% gap in add-to-cart event tracking, a JavaScript firing-order issue that would have distorted revenue reporting for a full quarter had it shipped uncaught.

This is where migration plans usually break down. Stakeholders want confirmation the switch is safe before they approve it, and a rollback window measured in minutes rather than hours is what makes a big-bang cutover defensible to them.

Post-launch log file analysis and reindexing speed

Log file analysis is the fastest way to catch reindexing gaps that Google Search Console won't surface for weeks. Pull raw server logs for the first 14 days post-launch and check which URLs Googlebot actually requests, not which ones you assume it crawls.

A migration involves a temporary crawl budget hit as Googlebot relearns site structure: common on large catalogs, and something most teams don't plan for beyond redirect mapping. What they want is continuous visibility into what's actually being crawled, not just what Search Console reports days later.

On a Magento to Shopify Plus migration our team ran in 2026, log files showed Googlebot ignoring 9% of new category URLs for 11 days because they weren't in the submitted XML sitemap. Fixing sitemap priority and trimming overly broad robots.txt disallow rules cut that gap to three days.

Sites typically regain most of their pre-migration organic traffic within one to four months, per Only 27% of domain migrations fully recover their pre-migration organic search traffic within 90 days; the median recovery time is 304 days (SALT.agency domain migration recovery study (1,052 2023), log file analysis is how you shorten that window instead of just waiting on it.

How much does a website migration cost, and how long does it take?

Cost and timeline scale with migration complexity, not company size.

A CMS-to-CMS move, such as WordPress to WordPress on a new host, or a theme replatform, typically costs between $3,000 and $20,000 for small to mid-size businesses in 2026, and takes four to eight weeks from kickoff to launch.

A full platform change, like Magento to Shopify Plus or a headless rebuild, involves deeper data work and a longer runway. These builds typically range from $150,000 to $400,000 at mid-market scale, with heavy customisation pushing the high end up another 50-80%. Timelines usually span three to six months.

This is especially true for full platform changes involving ecommerce systems. Planning an ecommerce replatform carefully upfront can prevent costly scope creep during the build, since ecommerce catalogs and integrations tend to surface hidden dependencies late.

Three variables move the number more than anything else:

• Catalog size, since more products and variants mean more mapping and QA hours
• Backlink profile mapping depth, since larger link portfolios need more redirect logic
• Rollout approach: staged versus big-bang cutover

A staged plan spreads cost across more sprints but cuts risk. A big-bang cutover compresses the timeline but demands a wider staging environment freeze before the DNS switch.

Budget for what teams commonly skip: WCAG accessibility compliance testing on new templates, GA4 property migration validation, and a buffer week for post-launch log file review. These line items rarely appear in an initial quote but routinely add one to two weeks and several thousand dollars to the final bill.

On a recent Magento-to-Shopify Plus migration, our team mapped 3,200 redirects and recovered 94% of organic traffic within eight weeks of launch. That result came from front-loading QA, not compressing it.

If an agency quotes a fixed price before URL mapping is finished, that's a sign they don't yet understand the scope.

FAQ: Backlinks, cost, timeline, agencies, and WordPress migration

Plan your migration with an SEO-first engineering partner

A website migration only protects rankings when 301 redirects, URL mapping, and canonical tags get the same engineering review as the platform cutover itself (Google Search Central - Site Moves and Migrations). Most agencies treat SEO as a follow-up task, which is why traffic dips drag on for months instead of weeks.

Our team maps redirects and Google Search Console data before a single URL moves, then runs continuous analytics validation for 30 days post-launch. That played out at Otodom: 116% growth in subscription rate to saved search notification.

If you're planning a migration and want an engineering partner who treats redirects as production code, not an afterthought, contact creators at our team who specialize in this approach by visiting our contact page.