Changing ecommerce platforms is one of the few decisions that can erase years of organic traffic in a weekend. The new store looks better, loads faster, and costs less to run, and then the rankings slide because thousands of old URLs stopped resolving, category text vanished in the import, and the staging site’s noindex tag shipped to production. None of that is the new platform’s fault. It is what happens when a migration is planned as a design and development project with SEO as an afterthought.
Stores replatform for good reasons: growth past what a starter plan can handle, fees that scale badly, missing features, or a stack nobody can maintain anymore. The options are covered in our comparison of the 10 best ecommerce platforms for 2026. This article is about the part that decides whether the move pays off: keeping the search visibility you already have while you change everything underneath it.
The stakes are well documented. SALT.agency analyzed 1,052 domain migrations and found a median recovery time of 304 days, a mean of 489 days, and 13.9% of sites that showed no full recovery after three years. Only about one in four recovered within 90 days. Those numbers come from domain migrations, the riskiest kind, but the mechanisms that cause the losses are the same ones a replatforming project triggers.
Why migrations lose traffic
Rankings are attached to URLs, and the signals Google has collected about each URL (links, relevance, history, engagement) do not move to a new address on their own. When a URL changes, a redirect has to pass those signals along, and the new page has to be similar enough that Google treats it as the same thing. Most migration losses come from breaking one of those two conditions.
An earlier, widely cited study published by Search Engine Journal, covering 892 domain migrations, found an average of 523 days before the new domain matched the old one’s organic traffic, and 17% of sites still had not recovered after 1,000 days. The causes that turn a manageable dip into a long recovery are predictable:
- Missing redirects for URLs that had rankings or links, leaving them as 404s
- Redirects to the wrong place, most often every old product sent to the homepage or a top-level category
- Lost content: category descriptions, product copy, or FAQs that did not survive the import
- Changed templates that drop headings, internal links, breadcrumbs, or structured data
- Indexing blockers carried over from staging, such as noindex tags, robots.txt rules, or password protection
- Too many changes at once: new platform, new URLs, new design, new domain, and new content in one launch, making it impossible to tell which change caused which drop
The last point is the one most teams ignore. Every additional change multiplies the risk and slows the diagnosis when something goes wrong.
Decide what kind of migration you are running
Not every replatforming carries the same risk, and the checklist scales with it. A platform change that keeps the same domain and the same URLs is the safest; Google sees new templates on familiar addresses. A platform change that alters the URL structure is the most common case, since platforms have their own URL conventions. Adding a domain change, a redesign, or a content overhaul on top raises the risk each time.
If you have a choice, separate the moves. Replatform first and keep the design and content as close to the old site as the new platform allows. Change the domain, if you must, in a separate project months later. Redesign once rankings have settled. It feels slower, but it is the only way to know what each change did.
Before migration: benchmark everything
You cannot protect what you have not measured. Before any development starts, capture a full picture of the current site, saved as files rather than screenshots, because the old site will not exist to check later:
- A complete crawl of the live store, with every URL, status code, title, meta description, H1, canonical, and word count
- Search Console exports of the last 16 months of clicks and impressions by page and by query
- Analytics data: organic sessions, conversions, and revenue by landing page for at least the last year
- Backlink data showing which URLs have external links pointing at them, and from where
- Structured data inventory per template: product, review, breadcrumb, and organization markup
- A ranking set of your top 100 to 200 commercial keywords with current positions and ranking URLs
From that data, build a list of priority URLs: every page that receives organic traffic, earns revenue, or has external links. On most stores this is a small fraction of the total URL count, and it is the fraction the whole migration plan should protect first. The technical baseline itself (indexation, canonicals, pagination, rendering) is worth reviewing at this point too, using our guide to technical SEO for ecommerce sites, because migrating existing problems onto a new platform wastes the opportunity to fix them.
Map every old URL to its new home
The redirect map is the single most important document in a migration. It lists every old URL that matters and the exact new URL it should point to, one to one wherever possible. Platform conventions make this harder than it sounds: Shopify forces /products/ and /collections/ prefixes, WooCommerce uses its own product and category bases, and headless builds can use almost anything. The structural differences between the two most common platforms are part of what our Shopify vs WooCommerce comparison covers, and they should be understood before anyone promises that “the URLs will stay the same”.
Work through the map by page type:
- Products: map each old product URL to the same product on the new platform, by SKU rather than by name
- Categories: map each old category to its closest equivalent, and create new categories rather than collapsing several into one if they had separate rankings
- Content pages and blog posts: keep the same slugs where the platform allows
- Discontinued products: redirect to the closest replacement or parent category, or let them return 404 if they have no traffic or links
- Parameter URLs and filters: decide which old filtered URLs had real traffic and need a destination, and let the rest go
- Images and files: map any image or PDF URLs that have links or image search traffic
Test the map against your crawl and backlink exports before launch. Every priority URL should have a destination, and every destination should be a live, indexable page on the new site.
Write redirects the way Google reads them
Google’s documentation on redirects and Google Search recommends a permanent server-side redirect whenever possible when you want the new URL to replace the old one in results. On most platforms that means 301 redirects configured in the platform’s redirect manager, the server configuration, or the CDN, not JavaScript or meta refresh redirects that run in the browser.
Three rules prevent most redirect problems. Redirect in one hop: if an old URL already redirects somewhere, update the old rule to point at the final destination instead of chaining a new redirect on top. Redirect to the equivalent page, not the homepage; Google treats mass homepage redirects much like 404s. And keep the redirects in place for the long term, rather than cleaning them out a few months after launch when someone decides the rule list is getting long.
Carry the content and templates over intact
A redirect tells Google where a page went. The page at the other end still has to deserve the rankings. Template and content parity is where many migrations quietly lose ground, because the new theme looks finished in a demo and nobody checks it against the old pages line by line:
- Titles and meta descriptions migrated per URL, not regenerated from a new template
- Category descriptions and buying help present on the new category pages, in the same position relative to the product grid
- Product descriptions, specifications, and FAQs imported completely, including formatted text and tables
- Heading structure, with one H1 per page matching the old one
- Internal links: navigation, breadcrumbs, related products, and links inside content, pointing at the new URLs directly rather than through redirects
- Structured data for products, reviews, breadcrumbs, and the organization, validated on each new template
- Image alt text and file names, which bulk imports often drop
- Hreflang and canonical tags for multi-language or multi-region stores
Compare a crawl of the staging site against the crawl of the live site, URL by URL, using the redirect map to pair them. Differences in title, H1, word count, or internal link count are the warning signs.
Staging traps that ship to production
The most damaging migration mistakes are often the simplest, and they happen at launch because the staging environment was deliberately hidden from search. Before switching DNS or going live, check each one explicitly:
- Noindex tags added sitewide to keep staging out of Google
- Robots.txt set to disallow everything on staging
- Password protection or IP restrictions left on part of the site
- Canonical tags pointing at the staging domain
- Hardcoded staging URLs in internal links, sitemaps, or structured data
- Analytics and tag manager missing from the new templates, which means you will not see the damage you are trying to measure
A five-minute check against this list on launch day has saved more migrations than any amount of planning documentation.
Launch day and the first weeks
Launch on a quiet day for your store, not before a sale or a holiday. Deploy the redirects at the same moment the new site goes live, submit the new XML sitemap in Search Console, and crawl the old URL list immediately to confirm every priority URL redirects once to the right destination.
Then set expectations with everyone who will look at the traffic graph. Google’s guide to site moves with URL changes says that for medium-sized sites it can take a few weeks or more for Google to start showing the new URLs instead of the old ones, and longer for large sites. The same guide recommends keeping redirects for as long as possible, generally at least one year. A temporary dip while Google recrawls is normal; a sustained drop on priority pages is not, and the benchmark data from before the migration is what lets you tell the difference.
If the domain changes too
When a replatforming also moves the store to a new domain, Search Console’s Change of Address tool tells Google about the move directly once the redirects are live. It only applies to moves between domains, not to URL changes within the same domain, and Search Console shows notices about the move for 180 days. Both domains need to be verified in Search Console, and the old domain must stay registered and redirecting long after the move; letting it lapse throws away every link that still points to it.
Protect the links you earned
Redirects pass link signals, but they are the second-best option. For your most valuable backlinks (the ones from relevant, authoritative sites pointing at pages that rank), ask the linking sites to update the URL directly. It is a small outreach list for most stores, usually a few dozen links, and it removes a dependency on redirects that someone may delete years from now.
The migration is also a natural moment to look at which pages have links and which do not. Category pages that are about to start over on new templates benefit from fresh links more than at almost any other time, and our breakdown of ecommerce link building covers which tactics move category pages on a realistic budget.
Hosting and performance on the new platform
A migration changes the infrastructure under the store as well as the software, and speed regressions are a common cause of post-launch ranking and conversion losses. Test the new templates on real devices before launch, compare Core Web Vitals on staging against the live site, and check server response times under load rather than on an empty staging server. If the move includes a change of hosting or cloud provider, the planning steps in our guide to cloud computing migration apply alongside the SEO checklist, since downtime during the switchover means crawl errors at exactly the moment Google is re-evaluating the site.
The first 90 days after launch
Monitor daily for the first two weeks, then weekly until the third month. The checks that matter:
- Search Console Pages report for spikes in 404s, redirect errors, and “Discovered, currently not indexed” on new URLs
- Crawl stats to confirm Googlebot is crawling the new site at a healthy rate
- Organic clicks on priority pages, compared week by week against the pre-migration baseline
- Ranking set positions, especially for the commercial keywords that drive revenue
- Organic revenue by landing page, since traffic can hold while revenue drops if the losses are concentrated on commercial pages
- Server logs or the redirect manager, for old URLs still being requested that are missing from the redirect map
Fix what you find quickly. A missing redirect discovered in week one costs a little; the same redirect discovered in month six has cost the page its rankings.
Is the move worth it?
A migration done well can leave a store faster, easier to manage, and better positioned to grow than before. A migration done badly can take more than a year to recover from, and the studies above show that some sites never fully do. The decision to move should rest on a clear business case: the cost of staying, the cost of moving, and the cost of the traffic risk in between. Our analysis of the total cost of ownership of scaling on open-source architecture is a useful starting point for the first two. The checklist above is how you keep the third as small as possible.