How to migrate ecommerce platforms without losing search traffic
Search traffic is lost in migration when old URLs stop resolving. Before moving, export every indexed URL, map each one to its new destination, and test every redirect on staging before the switch. Platform migrations also break two things reliably: URL structures, because platforms enforce their own path prefixes, and customer passwords, which never transfer.
Migrations lose traffic for one reason above all others: URLs that used to resolve stop resolving. Almost everything else is recoverable. That is not.
Export before you can’t
The first task, and the one with a deadline attached, because some of this data disappears with the old site.
Take these while the old site is still live:
| Source | What it gives you | Recoverable later? |
|---|---|---|
| Search Console — Pages report | Every URL Google has, with impressions | Yes — history survives the site |
| Search Console — Queries report | Your ranking baseline | Yes |
| Live XML sitemap | URLs the platform believes exist | No |
| Full site crawl | Orphaned and unlinked URLs | No |
| Backlink report | Which URLs hold external links | Partially |
| Database export | Previously published, now unpublished URLs | No |
The crawl finds what the other sources miss — old landing pages, paginated archives, attachment pages, campaign URLs. These are exactly the URLs nobody remembers and that quietly hold links.
Reconcile all sources into one list. That list is the specification for the redirect map, and every URL on it needs an answer.
Build the redirect map
Three possible outcomes per URL, and every URL gets one:
- Preserved — same path on the new site, no redirect needed
- Redirected — permanent redirect to the closest equivalent
- Gone — deliberately returns 410, for genuinely retired content
Acceptance criterion: zero URLs unaccounted for. Not “the important ones”. All of them.
Rules that matter:
- Redirect to the closest equivalent page, not to the home page. Bulk redirects to home are treated as soft 404s and pass nothing.
- One hop. If the old site already had redirect chains, flatten them. Chains lose value and slow crawling.
- Preserve where you can. Every URL that does not change is a URL that cannot break. On our own rebuild we kept
/privacy-policy/and/terms-conditions/at their exact paths for this reason. - Watch the trailing slash. Decide a policy, apply it everywhere, and normalise the other form with a redirect.
What breaks on every migration
Two things, regardless of direction.
URL structure
Platforms enforce their own path conventions. Shopify requires /products/, /collections/ and /pages/ prefixes. Move to it and essentially every product and category URL changes.
This is not negotiable and it is not a bug. It simply means the redirect map is mandatory rather than optional, and any migration plan that treats it as a final-week task has the sequencing wrong.
Customer passwords
Password hashes are not portable. Every customer must reset.
You cannot engineer around this. What you can do is plan it:
- Write the reset communication before launch
- Schedule it to go out with the launch, not days later
- Make sure support knows it is coming
- Expect a spike in “I can’t log in” contacts regardless
Discovering this after launch, from tickets, is a genuinely bad first day for a new store.
Also plan for
- Order history — migrate it if the platform allows, or keep the old system readable for returns and support
- Reviews — often tied to product IDs that change; check the export path before committing
- Transactional emails — every template needs rebuilding and testing on the new platform
- Structured data — rebuild it, and validate before launch rather than after
- Analytics — install and verify on staging, so you do not lose the first days of data
- Third-party integrations — every system connected to the old store needs repointing
Test the redirects
A redirect map that has never been executed is a hypothesis.
On staging, run the full URL list and confirm each returns the expected status and lands on the intended page. Automate it — a script over a few hundred URLs takes minutes and catches the typos that a spot-check misses.
Check specifically for: chains, loops, redirects to 404s, and any URL that quietly falls through to the home page.
Launch and afterwards
Submit the new sitemap immediately. Keep the old sitemap available briefly so crawlers discover the redirects for URLs they already know.
Then monitor daily for two weeks:
- 404s in server logs, which is where you find URLs the map missed
- Search Console coverage and crawl errors
- Which redirects are actually being hit
Expect a dip. Search engines need to recrawl and reassess, and a few weeks of fluctuation is normal even on a clean migration.
The mistake that turns a dip into a problem is panicking into further changes mid-recovery. That restarts the reassessment from the beginning. Hold the line, fix genuine errors only, and let it settle.
If you skip the export
Sometimes a client decides a migration is really a fresh start and the old data is not worth capturing. That is a legitimate call for a small site, and it should be a decision rather than an oversight.
Be clear about the consequence: any indexed URL not in your map will 404, and you will have no baseline to measure recovery against. At minimum, take the Search Console export. It survives the site being switched off, it costs ten minutes, and it is the single most useful item on the list.
A realistic timeline
Migrations get compressed because the build feels finished. These are the stages that actually need time.
Weeks 1–2: inventory and mapping. Exports taken, URLs reconciled, redirect map drafted. This can run in parallel with the build and should start early, because it is the item most often left too late.
During the build: data preparation. Catalogue cleaning, which is nearly always needed and nearly always underestimated. Inconsistent units, missing attributes, duplicate products.
Week before launch: redirect testing. The full list, executed and verified on staging.
Launch day: sequence matters. DNS change, immediate smoke test of the critical paths, sitemap submission, then monitoring. Not a Friday afternoon.
Weeks 1–2 after: daily monitoring. 404 logs, coverage reports, and the checkout working. Fix genuine errors; resist restructuring.
Week 4 onwards: assess. Enough data has accumulated to tell recovery from a real problem.
What to tell stakeholders beforehand
The conversation that prevents a crisis three weeks after launch.
Traffic will dip. Say this before launch, in writing, with an expected shape and duration. A forecast that comes true is reassuring; the same dip unforecast looks like failure.
Rankings will move around before settling. Individual keyword positions during recovery are noise.
Some things will break. Not because the work was poor, but because no test environment reproduces real traffic on real devices. A defined fix window is normal.
The comparison point is month three, not week one.
Having that conversation early costs ten minutes. Not having it costs considerably more in confidence when the expected dip arrives and nobody was warned.
