Most eCommerce SEO migration content online is written as a DIY checklist: here’s what you, the store owner, need to do before you switch platforms. That’s not much use to most people reading it, because most store owners aren’t the ones touching redirects, rebuilding schema, or checking staging isn’t indexed. Their agency or developer is.
The question that actually matters isn’t “what needs doing during a migration.” It’s “how do I know if the people doing it are doing it properly.”
I’ve watched agencies get eCommerce SEO migrations right, and watched in-house teams get them badly wrong, usually by treating a platform switch as a design job with SEO bolted on afterwards. This isn’t a platform comparison piece. If you’re still deciding between Shopify, WooCommerce, BigCommerce or Magento, that decision belongs on our eCommerce platform SEO hub, which covers the technical trade-offs of each. This piece assumes the platform decision is already made and you’re looking at the migration project itself.
What follows is what a competent agency should own, in order, with what you should be able to ask for as evidence at each stage.
Why eCommerce migrations go wrong more often than people expect
Google treats a “site move” broadly. Its own documentation lists three triggers: any change from HTTP to HTTPS, any domain change, or any change to URL paths or structure. A platform migration, even one that keeps the same domain, falls under that umbrella the moment your URLs change shape. The SEO risk starts the moment someone decides /product.php?id=482 is becoming /products/widget, not on launch day.
The data on how badly this can go is sobering, if you read it properly. SALT.agency’s analysis of 1,052 domain migrations found a median recovery time of 304 days, with around 23% of sites recovering within 90 days (28% by the 120-day mark), and 13.9% still showing no full recovery after three years.
Read that carefully: SALT’s data is specifically about domain migrations, the highest-risk category, because the URL and the domain it sits on change at the same time. A platform migration that keeps your existing domain and preserves URL structure carries meaningfully less risk than a domain change. Conflating the two overstates the danger for someone who’s just switching the software behind the same web address.
Google’s own guidance on timeline is more reassuring: a small to medium site can take a few weeks for most pages to move through the index, with larger sites taking longer. That’s the baseline for a well-executed migration. The rest of this checklist won’t remove risk entirely, nothing does, but it’s the process, not luck, that decides which outcome you get: a few weeks of settling, or the long tail SALT’s data describes.
Before anything moves: the audit your agency should run first
Before a single URL changes, your agency should be documenting exactly what exists today. This isn’t optional groundwork. It’s the reference point everything else gets checked against later.
That means:
- A full crawl of the actual live site using the XML sitemap, the Google Search Console coverage report, and a crawler like Screaming Frog together, not just whatever’s linked in the main navigation. Orphaned pages that still rank and still get indexed are exactly the ones a lazy migration misses.
- Baseline traffic captured at URL level via GSC’s Pages and Performance reports. GSC’s own click and impression data is the right source for “which URLs currently earn traffic” here, no search volume figure needed, just what’s actually converting clicks right now.
- Current rankings for priority terms, current Core Web Vitals scores, and a backlink inventory by URL, so you know which old pages are carrying referring domains that need to keep working.
- Existing metadata and schema documented as a reference, not just the page content itself. If nobody wrote down what the title tags said before, there’s no way to check whether the new platform’s template mangled them.
This should exist as a document you can actually look at, not something your agency tells you they did. Ask “can I see the pre-migration audit” and get a shrug back, and that’s your answer.
The redirect map: the part most migrations get wrong
Every indexed, traffic-bearing or backlinked old URL needs an explicit, individually mapped destination. Not a rule. Not a fallback. A specific old URL pointing at a specific new URL that’s genuinely equivalent in content.
Don’t just redirect everything to the homepage
This is the single most common shortcut, and it quietly costs migrations their most valuable URLs. John Mueller has said repeatedly that when a large batch of unrelated old URLs get redirected to one destination, usually the homepage, because there’s no real equivalent, Google treats those redirects as soft 404s. In plain terms: no equivalent page means no ranking signal passes through. The redirect exists technically. It does nothing for you.
Google’s actual advice is simpler than the workaround most agencies reach for: if there’s genuinely no equivalent page for an old URL, let it 404. A clean 404 (or 410 for something permanently gone) is more honest than a fake redirect that isn’t passing any signal anyway.
A few other non-negotiables on the redirect side: server-side 301s only, JavaScript and meta-refresh redirects are unreliable for passing signal during a migration. 302s tell Google the move is temporary, so by default Google keeps the original URL as the canonical page rather than shifting authority to the destination, unlike a 301, which signals a permanent move (Google Search Central). If a 302 sits in place for months, Google may eventually start treating it like a 301, but that’s not something to plan around.
Keep chains to one hop where you can, old URL straight to final URL. Mueller has advised staying under five hops, and Google’s own documentation confirms Googlebot can technically follow up to ten but recommends staying under five as best practice (Google Search Central). The practical target for a migration is one: old to new, not old to intermediate to new.
Discontinued products get judged individually too. Redirect to the closest matching category page if there’s a genuine equivalent; if there isn’t, let it 404 or 410 rather than dumping the URL somewhere unrelated just to avoid a broken link.
And keep the redirects live for at least a year. This is a separate figure from Search Console’s Change of Address tool, covered below, which forwards signal for a fixed 180-day window. The redirects need to outlast that window considerably, longer still if you’re still seeing traffic land on the old URLs. Treat the map as something to check back on for months, not something ticked off on go-live day.
The tooling for building this map differs by platform: Shopify enforces a fixed URL skeleton you can’t remove (/products/, /collections/, /blogs/, /pages/) but has a native bulk redirect importer, WooCommerce has fully customisable permalinks but no native redirect tool, so you’re relying on a plugin. If you’re weighing up Shopify against WooCommerce specifically, we’ve covered the mechanics of that URL-structure trade-off in our Shopify vs WooCommerce SEO comparison.
Content, metadata and schema: what shouldn’t get regenerated from scratch
Title tags, meta descriptions, headings and body copy need to migrate with the page, not get regenerated from a template. Cart-to-cart migration tools frequently auto-generate or truncate these during transfer, a quiet cause of ranking loss unrelated to redirects. Nobody notices at the time, because nothing’s technically “broken.” The page just reads worse and ranks worse than it did.
Structured data needs the same scrutiny. Product, Offer, AggregateRating and BreadcrumbList schema should be rebuilt or explicitly confirmed on the new platform, never assumed to carry over intact. Validate with Google’s Rich Results Test at launch, not weeks later: broken product schema affects rich result eligibility, star ratings, price, stock status in the SERP, and therefore click-through rate, before rankings even have time to move.
Reviews are an easy silent loss here too. If your review app doesn’t migrate cleanly, you lose the data feeding AggregateRating schema, and that gap only tends to surface once someone notices the star ratings have quietly vanished from search results.
Technical checks that have to happen at launch, not after
A handful of items need verifying at the moment of cutover, not discovered a fortnight later.
- Staging blocked from indexing. Password protection, noindex, or a robots.txt disallow, ideally more than one of these at once. It’s a well-known failure mode and still a depressingly common one.
- SSL/HTTPS continuity through the switch, with no mixed content warnings post-launch.
- Canonical tags self-referencing correctly at scale, checked across the site, not spot-checked on a handful of pages that happened to look fine.
Beyond those three: internal links, navigation, footer, breadcrumbs, related-product modules, all need to point directly at the new URLs rather than resolve through the old ones, tying back to the one-hop principle above. The XML sitemap needs regenerating and resubmitting in both Google Search Console and Bing Webmaster Tools, with the old sitemap taken down rather than left live alongside it. And faceted or filtered navigation is worth a look too: platforms generate filter URLs differently, query parameters versus path-based, and on a larger catalogue it’s worth a crawl-budget check so Googlebot isn’t burning its allowance on parameter combinations during the window it should be focused on the migrated pages.
The first 30 days: what should actually be monitored, and what’s normal
Migration doesn’t end at launch, and this is where a lot of agencies quietly stop paying attention. What should be happening in the weeks after:
- GSC’s Coverage and Pages reports checked daily for the first two weeks, watching for a spike in 404s or “crawled, not indexed,” then weekly after that.
- The redirect map tested at scale, not spot-checked: the URL Inspection Tool for individual checks, a crawler for bulk verification, rather than trusting the migration tool got it all right.
- Log file analysis to see what Googlebot is actually requesting, as opposed to what you assume it’s crawling. This is the most direct way to catch a redirect or crawl-budget problem early, before it shows up as a ranking drop.
On what’s normal: a dip in traffic during the first two to four weeks while Google reprocesses the site follows directly from Google’s own “a few weeks” guidance, and shouldn’t set off alarm bells on its own. What’s worth watching for is a dip that’s still getting worse at the six-week mark. That’s not normal reprocessing lag. That’s a sign something’s actually broken, whether it’s unmapped redirects, a de-indexed section, or internal links still pointing at dead URLs.
Core Web Vitals data in GSC comes from the Chrome UX Report: a rolling 28-day window of real-world Chrome data, refreshed roughly daily, though changes typically take a few days to show up in the Search Console report itself. New URLs won’t show CWV data immediately after migration, so don’t panic at a blank report in week one.
What to ask your agency before a migration starts
Turn this whole checklist into questions you can put to whoever’s running the migration:
- Can I see the pre-migration audit and the redirect map before launch, not after?
- Who’s explicitly checking staging isn’t indexed, and how are they checking it?
- What’s the monitoring plan for the first 30 days, and who owns watching it daily versus weekly?
- What’s the plan for discontinued or out-of-stock product URLs specifically?
- Is anything else changing at the same time as the platform switch? It shouldn’t be. Google’s own advice is to change one thing at a time, move to the new platform, then separately change the design or content, because combining them makes any ranking movement impossible to diagnose properly.
This kind of technical discipline should sit under ongoing SEO management, not a one-off project handed to whoever built the site. It’s core to what we do as part of our SEO services, and it’s the difference between a platform switch that costs three months of visibility and one that barely registers in your traffic graph. Our Small Smart case study, covered on the platform hub, shows what disciplined platform-level work can produce: a 220% increase in ranking keywords and an eightfold increase in seasonal Christmas-intent traffic for a children’s products retailer.
A migration is temporary. A bad one has a long tail that isn’t. Most of this checklist exists for one reason: to stop a few weeks of technical project work turning into a permanent hole in your organic traffic.
FAQ
How long does an eCommerce SEO migration take to recover from?
Google’s own guidance suggests a few weeks for most pages on a small to medium site to move through the index. SALT.agency’s analysis of domain migrations specifically found a median recovery of around 304 days, but that figure covers the highest-risk category, a domain change. A platform switch that keeps your existing domain and URL structure is typically a much smaller undertaking.
Should I redirect every old product URL, even discontinued ones?
Only where there’s a genuine equivalent, usually the closest matching category page. If nothing on the new site is actually equivalent to a discontinued product, let it 404 or 410 rather than redirecting it to something unrelated. Google treats mass redirects to unrelated pages as soft 404s, meaning they don’t pass any ranking signal anyway.
What’s the single biggest mistake in eCommerce migrations?
Bulk-redirecting everything to the homepage or one catch-all page without checking for genuine equivalents. It looks tidy and technically “works,” nothing 404s, but it strips ranking signal from every URL caught up in it.
Do I need to tell Google about the migration?
If you’re changing domains, yes, via Google Search Console’s Change of Address tool. It’s not needed for an HTTP to HTTPS switch alone, or for a platform migration that keeps the same domain and URL structure. Once submitted, it tells Google to prioritise crawling the new site and forwards ranking signals for a 180-day window, a real head start over waiting for organic discovery. That window is about crawl prioritisation, not how long to keep the redirects live: keep those in place for at least a year regardless.
