Most horror stories about an ecommerce migration follow the same script: the new store looks beautiful on launch day, and three weeks later organic traffic is down 40% and nobody knows why. The design was never the problem. The problem is that a migration is, underneath the redesign, a mass URL-change event — and Google was ranking the old URLs. Break the mapping between old and new and you don’t just lose a page, you lose every ranking, every backlink’s destination, and the revenue attached to them. Handle the mapping deliberately and you can replatform a large catalog with a dip so shallow it’s back to baseline in a month. This guide is about the mechanics that decide which outcome you get.
Why Ecommerce Migrations Lose Sales — and Which Ones Don’t
The single largest cause of traffic loss in any store migration seo project isn’t Google punishing the move — it’s equity that quietly fails to transfer. Every ranking URL carries accumulated signals: links, internal-link weight, click history, index status. When a URL changes and the old one 404s or redirects to the homepage instead of its true equivalent, those signals don’t move. Google treats the new URL as a fresh page starting from zero, and the old page’s rankings evaporate. Multiply that across ten thousand products and you have the classic post-launch cliff.
The migrations that hold their traffic share one trait: a one-to-one redirect from every old URL to its closest new equivalent, in place before launch. Everything else in this guide — schema, speed, faceted navigation — matters, but they’re second-order. Redirect mapping is where the sales are won or lost.
The Five Things That Actually Change in a Replatform
Before you can protect anything, you need to know what’s moving. A replatform ecommerce project usually changes some combination of five things at once, and each one is a distinct risk surface:
- URL structure — Shopify, Magento, WooCommerce, and BigCommerce each impose different default paths (
/products/vs/product/vs numeric IDs). Category and product slugs almost always shift. - Domain or protocol — a rebrand moves the domain; an HTTP-to-HTTPS or www/non-www change counts as a migration too.
- Templates and on-page content — H1s, meta titles, descriptions, and body copy get regenerated by the new theme, sometimes stripping tags you were ranking on.
- Internal linking and navigation — new menus, new breadcrumb logic, new related-product blocks redistribute PageRank across the site.
- Technical rendering — a headless or JavaScript-heavy front end changes how and whether Google can crawl your content at all.
When only one of these changes, recovery is fast. When all five change simultaneously — the typical “we redesigned everything” launch — you’ve stacked five variables, and diagnosing a drop afterward means untangling which one caused it. The discipline is to control the ones you can, one at a time where possible.
Build the Complete URL Inventory First
You cannot redirect what you haven’t listed. Before touching the new platform, crawl the live site and pull a complete inventory of indexable URLs — products, categories, collections, blog posts, and the money-making landing pages. Cross-reference three sources so nothing hides: a full-site crawler for what’s linked, Google Search Console’s Pages report for what Google actually indexes, and your server logs or analytics for what earns traffic and revenue. A URL that gets no internal links but ranks for a high-intent term is exactly the page a link-only crawl misses and a migration silently kills.
Rank the inventory by value, not by count. The pages that drive 80% of organic revenue deserve individually verified redirects; the long tail can follow pattern rules. SEO Rocket’s real-crawler site audit exists partly for this — it walks the live store the way Googlebot does, surfacing every indexable URL plus the redirect chains, broken links, and duplicate variants you’ll want cleaned up before, not after, the move.
Redirect Mapping: The Step That Decides Everything
Map every old URL to its single closest new URL and serve it as a 301 permanent redirect. Three rules keep this from going wrong. First, redirect to the true equivalent — an old product page goes to the same product on the new store, never to the homepage or a generic category. Bulk “redirect everything to the homepage” is the most common self-inflicted wound in an ecommerce migration; Google reads it as a soft 404 and drops the rankings anyway. Second, avoid chains: if A used to redirect to B and now B moves to C, point A straight at C. Redirect chains leak equity and slow crawling on large catalogs. Third, use 301 (permanent), not 302 (temporary) — a 302 tells Google to keep indexing the old URL, so signals never consolidate on the new one.
For discontinued products with no equivalent, don’t just 404 them. If a close alternative or the parent category exists, 301 there; if the product is genuinely gone forever, a clean 410 (Gone) tells Google to deindex it deliberately rather than leaving a soft error. Reserve 404s for URLs that were never meant to rank.
Faceted Navigation and Variant URLs: the Silent Killers
This is where ecommerce diverges hard from a blog migration. Stores generate URLs at a scale content sites never touch: every filter combination (?color=blue&size=m&sort=price) and every product variant can spawn a crawlable URL. A replatform frequently changes how these parameters are built — and if the old faceted URLs were indexed (a common mistake) you now have thousands of ranking parameter pages that need mapping, or thousands of crawl-budget-wasting duplicates on the new site.
Decide the policy explicitly before launch. Canonical each variant and filtered view to its clean parent category or product URL, keep genuinely useful facets (like a popular “waterproof laminate flooring” filter that has its own search demand) as indexable landing pages, and block the infinite combinatorial junk from crawling. Getting this right also fixes crawl budget: on a 50,000-SKU catalog, letting Googlebot burn its crawl allowance on parameter noise means your real product pages get recrawled slowly, so migration signals take longer to settle.
Protect Schema, Internal Links, and Page Speed
New themes love to break structured data. Verify that Product, Offer, and AggregateRating schema carry over on every product template — price, availability, and review markup are what earn the rich results that lift click-through. A word of accuracy: star ratings only stay eligible for genuine first-party reviews on your own products, so don’t let a migration “add” review markup to products that have none. Rebuild your internal linking intentionally too: breadcrumbs, category-to-product links, and related-product modules are how PageRank flows to deep pages, and a new nav that orphans half the catalog will suppress those pages regardless of redirects. Finally, don’t let a heavier theme tank Core Web Vitals — a slower LCP on mobile is its own ranking drag layered on top of the migration.
Staging, Launch, and the First 72 Hours
Build and test the new store on a staging environment that is fully blocked from indexing — password-protected or noindex on every page. The nightmare scenario is a staging site getting crawled and indexed as a duplicate of production; make sure the block is removed the instant you go live, because a launched store still carrying noindex from staging will deindex itself within days. That single overlooked meta tag has erased more launches than any redirect error.
At launch, work a tight sequence: push live, remove the staging block, submit the new XML sitemap in Search Console, and — if the domain changed — file a Change of Address. Then spot-check a sample of high-value redirects manually to confirm they resolve in one hop to the right page. In the first 72 hours, watch crawl stats and coverage errors daily; a spike in 404s or soft-404s is your early-warning system, and catching a broken redirect pattern on day one instead of week three is the difference between a blip and a cliff.
Your Ecommerce Migration Checklist
Condensed to the sequence that protects sales, here’s the working ecommerce migration checklist:
- Before: crawl the live site, build the full URL inventory from crawl + Search Console + analytics, rank by revenue, and export the current rankings as a baseline.
- Map: create a one-to-one old→new 301 map for every valuable URL; decide the faceted/variant canonical policy; handle discontinued SKUs with 301 or 410.
- Build: replicate on-page tags (titles, H1s, meta, schema), rebuild internal links and breadcrumbs, and test on a fully index-blocked staging site.
- Launch: deploy, remove the staging block, submit the new sitemap, file Change of Address if the domain moved, and QA a sample of redirects.
- After: monitor coverage and crawl errors daily for two weeks, track rankings against the baseline, and fix any redirect that returns a chain, a 404, or the wrong page.
Print it, assign owners, and don’t launch until every “before” and “map” item is signed off. A migration that slips its redirect map to “we’ll fix it after go-live” is a migration that will lose sales.
What a Normal Traffic Dip Looks Like
Even a flawless ecommerce migration usually shows a temporary dip while Google recrawls, reprocesses redirects, and re-consolidates signals onto the new URLs. A shallow, short dip is normal and expected — a modest softening in the first week or two that recovers toward baseline within four to six weeks as the index catches up. That is not a reason to panic or start reverting redirects, which only adds another change event on top of the first.
What is worth worrying about: a drop that keeps deepening past a few weeks, a surge of 404s or soft-404s in coverage reports, or specific high-value pages that flatline while the rest recover. Those signal a real mapping or indexing fault, not normal settling. This is where continuous rank tracking earns its keep — if you exported a pre-launch baseline and watch it daily, you can tell “expected turbulence” from “a category page that lost its redirect” within days instead of guessing at a monthly report.
How SEO Rocket De-Risks a Replatform
Migration risk is mostly a visibility problem: you can’t fix the redirect you didn’t know broke. SEO Rocket’s real-crawler site audit maps the live catalog before the move and re-crawls the new store after, flagging redirect chains, broken links, orphaned products, and duplicate variants — the exact ecommerce failure modes above — so nothing slips through unseen. Rank tracking on your product and category terms gives you the pre-launch baseline and the day-by-day recovery curve, and competitor gap analysis on real Ahrefs data helps you rebuild category and buying-guide pages that may have thinned out in the redesign. It’s an SEO layer that sits on top of whatever store platform you choose, not a replatform tool itself, for roughly $50/month with a free tier.
The underlying method isn’t theoretical. It’s the same playbook proven across 1,000,000+ ranking pages — including flooring ecommerce, where a full catalog of product and category URLs has to survive redesigns and platform changes without surrendering the rankings that drive orders. The discipline scales down to a hundred SKUs and up to fifty thousand: inventory everything, map one-to-one, verify, and watch the baseline.
Frequently Asked Questions
How long does it take to recover rankings after an ecommerce migration?
With clean 301 redirects and preserved on-page signals, most stores see a shallow dip that recovers toward baseline within four to six weeks as Google recrawls and consolidates equity. Larger catalogs take longer simply because there’s more to recrawl. A recovery that stalls or keeps deepening past a month usually points to a redirect or indexing fault, not normal settling.
Should I redirect old product URLs to the homepage?
No. Bulk-redirecting to the homepage is the most common way stores lose rankings during a migration — Google reads a redirect to an irrelevant page as a soft 404 and drops the ranking. Send every old URL to its true equivalent: the same product, or the closest matching product or category if the item is discontinued.
Do I need to migrate my URL structure at all?
If you can keep the existing URL structure on the new platform, do it — the safest replatform ecommerce move is one that changes as little as possible. When the new platform forces different paths, minimize other simultaneous changes (content, domain, templates) so that if traffic moves, you know the URL change caused it and can isolate the fix.
