This is the process for changing ecommerce platform without losing your search rankings, for the shop owner or developer doing the move. It is deliberately platform-neutral: the steps are the same whether you are leaving Shopify, WooCommerce, EKM, Magento or something a contractor built in 2016. Every rule below was checked against Google Search Central and Search Console Help on 15 September 2026 and linked to its source. Disclosure: we build Orbit Commerce, an ecommerce platform, so we have a stake in you moving shop. There is one Orbit paragraph and it is at the end.
The short version: rankings attach to URLs, not platforms. A migration goes wrong when the URLs change and nothing tells Google where each old address went. Get the redirect map right and most other mistakes are recoverable. Get it wrong and you are rebuilding from zero.
Which URLs actually matter, and how do you find them?
Every URL Google has indexed matters, plus every URL anyone links to and every URL that still gets a visit. That is a bigger set than your product list: old posts, discontinued products, tag pages, paginated collection pages, the PDF someone linked to in 2019. Pull four exports and merge them, because no single source is complete.
| Source | What it gives you | Why you need it |
|---|---|---|
| Search Console, Performance report filtered to Pages | Every URL that got an impression or click in the window Search Console keeps | The list that actually earns money. Sort by clicks for your priority order. |
| The old XML sitemap | Everything the old platform thinks is live and indexable | Catches pages with no traffic yet that still hold links. |
| A full crawl of the old site | Every URL reachable by following links, parameters and pagination included | Finds the URL shapes you forgot existed, including faceted and paginated ones. |
| Analytics landing pages, 12 to 24 months | URLs that got a real visit from any source | Catches pages that rank for nothing but are linked from an email or a supplier. |
Merge the four into one spreadsheet, remove duplicates, then mark the URLs other sites link to, using whichever backlink tool you have. If the Search Console export truncates, pull the same data through its API or Looker Studio. Do this before you build anything: the URL list should shape how the new site is structured.
How do you build a redirect map without missing anything?
A redirect map is one spreadsheet with a row per old URL: old URL, new URL, redirect type, and a status column you fill in after launch. Build it by pattern first, by hand second. Sort the merged list by URL shape, write a rule per shape that covers hundreds of rows at once, then hand-map the remainder. Nothing gets deleted from the sheet. Rows you cannot map get marked, not removed.
Google is explicit here. Its site move guidance says to use server-side permanent redirects where technically possible and to keep old URLs crawlable and redirecting rather than switching them off (Google Search Central, checked 15 September 2026). It is equally clear about the shortcut people reach for: do not redirect many old URLs to one irrelevant destination such as the home page of the new site. A shopper dumped on your homepage from a product link has lost the page they wanted, and so has Google: the old page reads as gone and its signals go with it.
Redirect type matters, and Google documents how each is read:
| Redirect | How Google treats it | Use it for |
|---|---|---|
| 301 or 308, server side | Permanent, a strong canonicalisation signal | Everything in a replatform. The default. |
| 302, 303 or 307 | Temporary, does not signal the new URL is canonical | Genuinely temporary things, like a sale page that reverts. |
| Meta refresh set to 0 seconds | Permanent, but read less reliably than a server redirect | Last resort if you cannot touch the server. |
| JavaScript redirect | Permanent, but only if rendering succeeds | Avoid. Google warns it might never see the redirect. |
(Source: Google on redirects and Search, checked 15 September 2026.) Where a page has gone with no equivalent, send it to the nearest real page: a discontinued product to its category. Where nothing sensible exists, let it 404. A clean 404 is honest and Google handles it fine.
A worked example with the arithmetic
Say the merged export gives 1,480 unique URLs: 940 products, 260 paginated and faceted collection URLs, 180 blog posts, 60 information pages, 40 old campaign landing pages. The new platform uses a different product prefix and drops the .html suffix, so four pattern rules cover 1,362 rows automatically, leaving 118 to map by hand. At 20 rows an hour, that is six hours over two evenings. Six hours is the whole price of not losing your rankings.
What must you copy across exactly?
Copy the things Google reads to work out what a page is: page title, meta description, H1, body copy, image alt text and structured data. Copy them character for character on your top pages instead of letting the new platform generate them from a template. It will happily replace a title you spent an hour on with the product name plus your shop name, and you will not notice for weeks.
In the order a migration usually loses them:
- Page titles and meta descriptions. Check per-page overrides survived the import, then spot-check twenty pages against the old site.
- H1s. New themes sometimes put the shop name in the H1 and demote the product name to an H2. Fix the template, not the pages.
- Body copy. Full descriptions, not truncated ones. Importers cut HTML at field length limits and nobody spots it until a page stops mid-sentence.
- Image alt text. It sits in a separate field from the image and is the most commonly dropped item in a catalogue import.
- Structured data. Product schema with name, price, availability and images, Article schema on posts, BreadcrumbList throughout. No markup, no review stars.
- Publish dates on posts. An importer that stamps 180 posts with today’s date tells Google you just published 180 new articles.
Keep the same content at the same depth. If a description was 400 words on the old site and the import brought 60, that is now a thinner, different page. People skip this because the site looks fine.
What breaks silently in a replatform?
The damaging faults produce a normal-looking page. Your shop loads, orders come in, and meanwhile Google quietly deindexes whole sections. Six things to check by hand, because no dashboard flags them:
- Canonical tags. The classic fault is canonicals still pointing at the old domain or the staging URL, which tells Google your live pages are duplicates of something else. View source on ten pages and read them yourself.
- Pagination. Old collection pages 2, 3 and 4 hold links and get crawled. New platforms often use a different parameter, or infinite scroll with no crawlable page 2. Map them to the equivalent page, or to page one if pagination has gone.
- Faceted and filter URLs. If the old site indexed filter combinations, decide deliberately: redirect them to the parent collection, or reproduce them. Do not let the new platform emit endless parameter URLs with no canonical back to the clean collection.
- Image paths. Image URLs change on every migration, so redirect the ones that earned image search traffic. And check nothing still hotlinks images from the old host, because the day you switch it off, half your product photos vanish.
- Internal links to old URLs. Hard-coded links in body copy, banners and navigation still point at old addresses. They work, through the redirect, so every click takes an extra hop and any later edit turns them into a chain. Rewrite them.
- robots.txt and stray noindex tags. The most expensive line in any migration is a Disallow: / copied from staging, or a site-wide noindex left on from the build. Read the live robots.txt yourself and check a product page head for a robots meta tag.
One more: page experience. Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift are the field metrics Google uses, with targets of 2.5 seconds, 200 milliseconds and 0.1 at the 75th percentile (web.dev, checked 15 September 2026). A new theme stuffed with sliders undoes a platform’s speed advantage by itself, so check the new storefront’s speed before the domain moves, not after.
What do you check on launch day, and in what order?
Run these in order. Steps 1 to 4 happen before you touch DNS.
- Freeze the old site: no new products, no edits, no new posts.
- Take the final export: products, customers, orders. Keep the files somewhere safe and dated.
- Read the new robots.txt in a browser and confirm it allows crawling, then view source on a product page and confirm no robots noindex is left from the build.
- Check the canonical on the homepage, a product, a collection and a post. Each must point at itself on the live domain.
- Point the domain at the new platform. Confirm HTTPS works on the apex and www, and that one redirects to the other rather than both serving.
- Spot-check redirects by hand: a product, a collection, a paginated URL, a faceted URL, a post, an image, and a URL you know is dead.
- Run the whole map through a bulk status checker. Every row should return a single 301 to a final 200. Fix any 302s, any chains, and any row landing on a 404.
- Confirm the old XML sitemap still resolves and lists the old URLs. Google recrawls those addresses to find the redirects, so leaving it reachable speeds the move up.
- Submit the new XML sitemap in Search Console and confirm it validates.
- If, and only if, the domain itself changed, use the Change of Address tool. It is for moving from one domain or subdomain to another, not for URL changes inside the same domain, not for HTTP to HTTPS, and not for changing host. It works only on domain-level properties, and you must verify both in the same Google account (Search Console Help, checked 15 September 2026).
- Confirm analytics and advertising tags fire, and that the consent banner still gates them.
- Place a real order with a real card and refund it. Check the confirmation email arrives and reads correctly.
- Test structured data on a product and a post with Google’s Rich Results Test.
- Annotate the date in analytics. In six weeks you will want to know exactly when you switched.
- Leave the old platform running, not serving the domain, for a fortnight as a reference.
Weeks one to six: what is normal and when should you worry?
Expect movement. Rankings commonly wobble for several weeks after a move and settle as Google recrawls and reprocesses the redirects, and that takes longer the bigger the site is. Nobody can honestly give you a recovery percentage, so here is what to watch instead.
| Period | Normal | Worry, and act |
|---|---|---|
| Days 1 to 7 | Impressions dip, positions move around, the old sitemap still shows most indexed pages and the new one very few | Pages returning 404 or 500, or a spike in soft 404s, which usually means redirects pointing somewhere irrelevant |
| Weeks 2 to 3 | New URLs appear in the Pages report, and indexed counts start moving from the old sitemap to the new one | The new sitemap stays near zero indexed, or crawl stats show Google barely fetching the site. Check robots.txt and noindex again |
| Weeks 4 to 6 | Most traffic is on new URLs. Some pages up, some down, overall trend flattening out | A whole section (all blog posts, one whole category) has gone and stayed gone. That is a template or redirect-rule fault, not a fluctuation |
The diagnostic question is always the same: one page, or a pattern? Individual pages move constantly and always have. A whole pattern disappearing is a bug you can fix in an afternoon. Check the Pages report weekly, grouped by URL folder, and the difference is obvious.
And keep the redirects. Google’s site move guidance says to keep them for as long as possible, generally at least a year. The Change of Address documentation says signals are forwarded for 180 days from the start of the migration and redirects should stay up at least that long, longer if search traffic still reaches them. For a shop, keep them forever: they cost nothing and they keep old links working for real people.
Questions people ask about changing ecommerce platform without losing SEO
Do 301 redirects lose ranking power?
Google’s site move documentation tells you to use server-side permanent redirects, 301 or 308, whenever technically possible, and describes them as the way to preserve signals during a move (checked 15 September 2026). The losses in a migration come from unmapped URLs, redirect chains, mass redirects to the homepage and changed page content, not from the redirect itself.
Should I use the Change of Address tool when I change platform?
Only if the domain changes. Search Console Help says the tool is for moving from one domain or subdomain to another, and specifically not for restructuring URLs inside the same domain, not for HTTP to HTTPS, and not for changing host while keeping your URLs. Most replatforms keep the same domain, so most replatforms should not use it.
How long should I keep the old redirects?
Google’s site move guidance says to keep redirects for as long as possible, generally at least a year. The Change of Address documentation says signals are forwarded for 180 days from the start of the migration and that redirects should stay up at least that long, longer if search traffic still reaches them. For a shop, just keep them permanently.
Can I redirect all my old URLs to the new homepage?
No. Google’s site move documentation says not to redirect many old URLs to one irrelevant destination such as the home page of the new site. It wastes the link and strands the shopper, and the old page reads as gone. Map each URL to its closest equivalent, and let genuinely dead pages return a 404 instead.
How long does it take for rankings to settle after a migration?
Several weeks in most cases, and longer for large catalogues, because Google has to recrawl every old URL to find its redirect. There is no reliable public figure for recovery, so treat anyone quoting one with suspicion. Watch the shape instead: individual pages moving is normal, a whole URL pattern vanishing is a bug.
One last thing, because the platform does affect how hard this is
Most of the work above is the same anywhere, but the tooling changes how long it takes. On Orbit, the SEO toolkit has a redirect manager with bulk CSV import (so the map goes in as a file, not 1,480 form submissions), an automatic 301 whenever a slug changes later, an editable robots.txt, canonicals and an automatic sitemap: the plumbing we think should ship by default. The import brings products, customers and orders across, and the 14-day free trial, no card required, is long enough to build the new store in parallel while the old one keeps selling. For the platform-specific versions, we have written up moving from Shopify, leaving WooCommerce and moving off EKM, ShopWired or Bluepark. Or start free and build the redirect map while the trial runs.