Every time a client tells me they are moving platforms, redesigning their store, or switching domains, the first question is always some version of the same thing, will we lose our rankings. My honest answer is that "100 percent" is the right goal to aim for, but it is earned through discipline before launch day, not luck on launch day itself. A migration only costs you traffic when something specific breaks, a missing redirect, a stripped title tag, a canonical pointing the wrong way, and every one of those failure points is preventable if you catch it before the new site goes live.
This guide is the exact process I run for ecommerce clients moving between platforms like Shopify, WooCommerce, Magento, and BigCommerce, or simply consolidating domains and restructuring a catalog. It covers the audit that has to happen first, how to build a redirect map that actually holds up at ecommerce scale, what to protect on launch day, and how to read the data afterward so you know within days, not months, whether the migration worked.
What Counts as an Ecommerce SEO Migration
I define a migration broadly, because the SEO risk is the same whether the trigger is a full platform switch or something that looks smaller on paper. That includes moving from one ecommerce platform to another, consolidating multiple domains or subdomains into one, restructuring your URL patterns or category hierarchy, or simply relaunching the same platform with a new theme and template structure.
The common thread across all of these is that search engines have to re-learn something about your site, a new URL, a new page structure, or new code they have never crawled before. The bigger that change, the more surface area there is for something to go wrong, and ecommerce stores tend to have far more surface area than a typical brochure site.
Why Ecommerce Sites Carry More Migration Risk Than Other Websites
I tell every client the same thing before we start planning, an ecommerce migration is not just a bigger version of a blog migration, it is a fundamentally riskier one. A content site might have a few hundred URLs to account for. An ecommerce catalog can have thousands of product pages, category pages, filtered and faceted URLs, and seasonal landing pages, many of which quietly carry meaningful organic traffic that nobody on the team remembers exists.
Product pages also come and go in a way blog posts do not, items get discontinued, categories get merged, and pricing pages get restructured for a new season. Each of those changes needs its own redirect decision, and at scale, that is thousands of individual choices rather than one clean list. This is exactly why the audit phase below has to be exhaustive rather than a quick spot check, because the pages most likely to get missed are usually the ones driving steady, unglamorous traffic in the background.
The Pre-Migration Audit: Your Traffic Insurance Policy
The work that happens before launch day determines the outcome far more than anything you do on launch day itself. I never let a migration project start without a full audit, because you cannot protect what you have not measured.
Crawl and Benchmark Everything
I start by crawling the existing site with a tool like Screaming Frog or Sitebulb and exporting every URL along with its title tag, H1, meta description, canonical tag, word count, and internal link count. I cross-reference that crawl against the XML sitemap and against Google Search Console and analytics, because a crawler alone will miss orphaned pages that still receive real traffic from an old campaign or a stray backlink.
Alongside the crawl, I pull a full performance benchmark, current organic traffic by page, current keyword rankings, current backlink profile, and current Core Web Vitals scores. This baseline is what I compare every post-launch metric against later, and without it, you have no objective way to tell whether a dip after launch is normal noise or a real problem.
Identify Your Highest-Value Pages
Not every page carries equal risk. I rank every URL by organic traffic and by the number and quality of backlinks pointing to it, then treat that ranked list as the priority order for the entire migration. A best-selling product page with dozens of referring domains gets far more scrutiny in the redirect map and far more attention on launch day than a low-traffic filter page nobody links to.
This prioritization also protects your time. On a catalog with thousands of SKUs, you cannot manually verify every single URL with the same intensity, so the highest-value pages get hand-checked while lower-value ones can move through a more automated, rule-based redirect process.
Building the Redirect Map That Actually Holds
The redirect map is the single most important artifact in the entire migration, and it is where I see the most expensive mistakes happen.
One-to-One Mapping Wherever a Match Exists
Wherever an old URL has a clear new equivalent, I map it directly with a 301 redirect, old product page to new product page, old category to new category. Search engines and shoppers both need to land on the closest possible match to what they were looking for, and a mismatched redirect, sending a specific product page to a generic category page, tends to recover rankings far more slowly than no redirect being needed at all.
Redirecting Discontinued or Merged Pages
Ecommerce catalogs always have pages with no clean one-to-one match, a discontinued product, or three old category pages consolidated into one. In these cases, I redirect to the closest relevant page rather than defaulting to the homepage. A discontinued product should point to its replacement or its parent category, never to the homepage, since a homepage redirect signals almost nothing about relevance and tends to get treated by Google as a soft 404 over time.
Avoiding Redirect Chains and Loops
I audit every redirect for chains, where URL A redirects to B, which redirects to C, and loops, where a chain eventually points back to its own starting URL. Each additional hop in a chain adds latency and dilutes the authority passed through the redirect, and a loop can silence a page's rankings entirely. My rule is simple, every redirect should resolve in a single hop, straight from the old URL to its final destination.
Testing the Map Before Launch, Not After
I test the full redirect map in a staging environment before it ever touches production, spot-checking the highest-value pages individually and running an automated crawl against the complete list to catch broken destinations, typos, and accidental loops. Finding a broken redirect after launch means it has already been live and failing for however long it took someone to notice.
Preserving Content, Metadata, and On-Page SEO
A redirect map protects the address a page lives at, but it does not protect what is actually on that page, and losing content quality during a migration is just as damaging as losing the redirect itself.
Metadata Parity, Not Just Migration
Every title tag, meta description, and H1 needs to carry over with the same intent, if not the exact same wording. I have seen migrations where a CMS default template silently overwrote every custom meta description with a generic one, and the ranking damage from that kind of mistake is often worse than a handful of missed redirects, because it touches every single page at once rather than a few.
Structured Data and Schema Markup
Product schema, review schema, and breadcrumb schema all need to migrate along with the visible content, since these feed the rich results, star ratings, and pricing details that make a listing stand out in search results. I validate every schema type on the new platform against Google's Rich Results Test before launch, because a platform switch can quietly drop a schema type the old platform supported natively.
Internal Linking and Navigation
Internal links carry authority between pages just as backlinks do, and a new site structure often reshuffles navigation menus, footer links, and related-product modules in ways that change which pages get linked to most. I map the old internal linking patterns against the new structure and make sure the pages that mattered most before the migration are still well linked after it, not accidentally pushed several clicks deep into a new hierarchy.
Images and Alt Text
Product images frequently get re-hosted, resized, or renamed during a platform move, and any of those changes can strip the alt text and file names that were contributing to image search traffic. I keep a mapping of old image URLs to new ones for anything already ranking in Google Images, since that traffic is easy to lose quietly and hard to notice missing.
Technical Foundations You Cannot Afford to Skip
Underneath the content and redirects sits a layer of technical settings that can silently undo everything else if they are wrong on launch day.
Canonical Tags
Every page needs a canonical tag pointing to itself on the new domain or URL structure, and I specifically check for canonicals left pointing back at the old site, a common leftover from staging environments that never got updated before launch.
The Noindex Tag That Never Got Removed
This is the single most common launch-day disaster I see, and it happens for a simple reason, staging environments are usually set to noindex so search engines do not crawl an unfinished site, and that noindex tag occasionally survives the move to production. A perfect migration with a stray noindex tag left in place can de-index an entire site within days. I treat this as a mandatory final check immediately before and immediately after every launch.
XML Sitemap and Robots.txt
I generate a fresh XML sitemap reflecting the new URL structure and submit it through Google Search Console and Bing Webmaster Tools the moment the site goes live, since this actively speeds up how quickly search engines discover and re-crawl the new pages rather than waiting to stumble onto them. I also review robots.txt line by line, since an overly broad disallow rule copied from a staging config can block entire sections of the new site from being crawled at all.
Page Speed and Mobile Experience
A platform migration is also a chance to improve Core Web Vitals, but it can just as easily make them worse if the new theme ships with unnecessary scripts or unoptimized images. Since the majority of ecommerce traffic is mobile, I test load times and mobile usability on the new site before launch, not after, because a slower new site can undercut the very rankings the rest of this process is protecting.
Launch Day: What to Validate in the First Hours
Launch day is when the plan either holds or reveals what was missed, and I treat the first few hours after going live as an active monitoring window, not a moment to relax.
Immediately after DNS propagates or the new platform goes public, I re-crawl the entire redirect map against the live site to confirm every redirect actually resolves in production the same way it did in staging. I check that analytics and Search Console tracking codes fired correctly on the new platform, since a broken tracking setup means you are flying blind on every metric that follows. I manually spot-check the highest-value pages identified during the audit, confirming metadata, schema, and internal links all rendered as expected, and I request indexing on the most critical URLs directly through Search Console rather than waiting for Google to find them on its own schedule.
Post-Launch Monitoring: The First 30, 60, and 90 Days
I never consider a migration finished at launch, since most of the real signal about whether it worked shows up over the following weeks.
In the first 30 days, I watch Search Console daily for crawl errors, indexing status, and any spike in 404s or soft 404s, since these are the earliest warning signs of a redirect or canonical problem. I track organic traffic and rankings for the highest-value pages specifically, rather than only watching the site-wide total, since a healthy overall number can still hide a real drop on a handful of pages that matter most.
Between 30 and 90 days, I compare the full post-launch picture against the pre-migration benchmark, and I reach out to any high-authority sites still linking to old URLs, asking them to update the link directly to the new URL rather than relying on the redirect indefinitely. A redirect preserves most of the value of a backlink, but a direct link to the live URL is always stronger and removes one more point of failure from the chain.
What "100 Percent" Actually Means in Practice
I want to be direct about this, because I think most guides oversell the phrase. A temporary fluctuation of a few percentage points in the days immediately after launch is normal, even in a well-executed migration, simply because search engines need time to re-crawl and re-index a changed site. The goal of everything in this guide is not to prevent that brief re-indexing window, it is to make sure the fluctuation is temporary rather than permanent, and that it recovers within weeks rather than months.
"Preserving 100 percent of organic traffic" means every ranking page has a clear, direct path to an equivalent or better page on the new site, with no broken redirects, no lost metadata, and no accidentally de-indexed sections, so that once search engines finish re-crawling, your visibility lands back at baseline or above it. In my experience, migrations that follow this process consistently land in that outcome, and the ones that do not almost always trace back to one of the mistakes in the next section.
Common Mistakes That Turn a Migration Into a Traffic Loss
Every case of serious traffic loss I have ever diagnosed after the fact comes down to a small number of repeat offenders:
- Missing or incomplete redirects, especially for lower-traffic pages that were never included in the audit in the first place.
- Redirecting everything to the homepage instead of the closest relevant page, which search engines increasingly treat as a soft 404.
- A staging noindex tag that made it into production and quietly de-indexed the new site.
- Metadata and schema overwritten by a generic CMS default instead of migrated with intent.
- Redirect chains and loops that dilute authority or break entirely.
- No pre-migration benchmark, which makes it impossible to tell whether a post-launch dip is normal or a real problem.
- Treating launch day as the finish line instead of the start of an active monitoring period.
None of these are exotic technical problems, they are all avoidable with the audit, redirect map, and monitoring plan laid out above, which is exactly why I run every migration through the same process regardless of which platform a client is moving to or from.
Free Migration Audit — Get First Position
If you are planning a platform switch, a domain consolidation, or a full redesign and want a second set of eyes before you commit to a launch date, I invite you to request a free migration audit from Get First Position. I will personally review your current site, flag the pages carrying the most risk, and walk you through the redirect and monitoring plan built specifically around your catalog, not a generic checklist.