Ecommerce platform migration SEO: how not to lose everything overnight

Table of Contents

Platform migrations are the single highest-stakes moment in an ecommerce store’s SEO history — more than any algorithm update, more than any competitor move. Done carelessly, a store can lose years of accumulated rankings in the time it takes a DNS change to propagate. Done properly, a migration is barely visible in the ranking data at all.

The difference between those two outcomes isn’t luck. It’s almost entirely down to one document: the redirect map.

Why migrations go wrong #

Every platform — Shopify, WooCommerce, Magento, a custom headless build — generates its own URL structure by default. Moving platforms almost always means every single URL on the site changes, even if the content on each page stays identical. Google doesn’t automatically know that your old /product.php?id=847 and your new /products/waterproof-hiking-boots are the same page. Without an explicit signal, it treats the old URL as gone and the new one as brand new, with zero accumulated history.

That signal is a 301 redirect, mapped old-URL to new-URL, for every single page on the site — not just the homepage and a handful of top pages.

The redirect map: the one document that decides the outcome #

Step 1

Crawl the old site completely before migration starts, capturing every indexed URL — product, category, blog, and any orphaned pages Google still has indexed even if they're no longer linked internally. Cross-reference against Search Console's own indexed-URL list, since a site crawl alone can miss pages the internal nav no longer links to.

Step 2

Map every old URL to its closest new-platform equivalent, one row per URL. A product that still exists maps to its new product page. A discontinued product maps to the closest replacement or its parent category — the same decision tree covered in handling out-of-stock and discontinued products.

Step 3

Implement every redirect as a 301, never a 302 — a 302 tells Google "temporary," and search engines are far slower to transfer ranking signals through a redirect they believe isn't permanent.

Step 4

Test the entire redirect map in staging before the DNS switch — every single URL, not a sample. A redirect map with a 2% error rate on an 8,000-product catalog is 160 broken pages on launch day.

What to check before, during, and after launch #

Before: XML sitemap ready on day one
The new platform's sitemap needs to be live and submittable the moment the new site goes live — not added a week later once someone remembers.

During: keep the old site crawlable until cutover
Don't take the old site offline or block it in robots.txt before redirects are live — that just creates a dead-URL gap with nothing bridging old to new.

After: submit the new sitemap and monitor Search Console daily for the first two weeks
The Coverage report will surface any redirect gaps as "not found" or "crawled, not indexed" errors — catching these in week one is fixable; catching them in month two after rankings have already dropped is much harder to fully recover.

The technical checks that get skipped under launch-day pressure #

Canonical tags need to point to the new URLs correctly from day one — a stale canonical pointing back at the old domain or old URL structure actively undermines the redirect map you just built.

hreflang tags, if the store serves multiple regions or languages, need remapping in full — this is exactly the kind of detail that gets missed when a migration is scoped as “just the UK site” and the international versions are patched in later as an afterthought.

Structured data (Product schema, breadcrumbs) frequently resets to platform defaults on a new build, sometimes losing custom fields like aggregateRating that took months to accumulate real review data into — worth a specific check, not an assumption it carried over.

Internal links across the whole site need to point to the new URL structure directly, not rely on the redirect chain to get visitors and crawlers there — a live site full of internal links to old, redirected URLs is dead weight the crawler has to work through repeatedly.

Why this connects to duplicate content and platform-specific issues #

A migration is also the moment duplicate content problems most often get introduced — a new platform generating its own dual-URL patterns (see the Shopify canonical bug as one concrete example) on top of a redirect map that’s still bedding in. Auditing for duplicate URL patterns should be part of the same post-launch checklist as monitoring the redirects themselves, not a separate project weeks later.

The realistic timeline #

Even a flawless migration causes a temporary ranking dip in most cases — Google needs time to recrawl, re-evaluate, and transfer signal through the new redirect map. What flawless execution actually buys you is a fast, temporary dip rather than a permanent loss. Expect two to six weeks of noisier rankings before things stabilize back to pre-migration levels or better, and treat anything beyond that as a signal to go back through the redirect map and technical checklist above for gaps.

Migration audits are some of the highest-stakes work in ecommerce SEO — get in touch before a platform switch, not after the rankings have already dropped.