Why an online store migration can "succeed" technically and still lose all its organic traffic
We recently worked on the replatforming of a store with over 8,000 of its own products, active for more than ten years, selling simultaneously through its own site and across seven marketplace channels. Technically, the project to migrate an online store without losing SEO went exactly as it should — the catalogue moved over cleanly, checkout worked, the design looked far better than the old version. If we'd stopped there, the risk was that the new site would lose, in the first month, a good chunk of the organic traffic built up over ten years.
The reason is simple and often overlooked: Google doesn't automatically recognise the new page as the "continuation" of the old one. Every address indexed over ten years represents accumulated trust — links, clicks, quality signals — tied strictly to that address. If the address disappears without an explicit bridge to its new location, that trust doesn't carry over automatically, it simply gets lost, and the search engine ranking for that page starts from close to zero.
Stage zero: the complete inventory, before you change anything on the site
Before writing a single line of code, you need a complete list of everything indexed today: a URL export from Google Search Console, your own crawl of the old site and, if one exists, the current XML sitemap. It's not just product pages that matter — categories, attribute filter archives and informational pages usually build up just as many links and organic clicks, but they're exactly the type of page forgotten when the team focuses only on individual product listings.
In our case, the old system already had a useful naming convention — names were structured with category, attribute and variant built in. We used exactly that pattern as the basis for the new attribute structure, instead of inventing a new taxonomy from scratch. Any pattern that already exists in the old data, however "messy" it looks at first glance, is real information about how the catalogue was thought through — and, often, about how people actually search for those products.
The 301 redirect plan — three types of mapping, not just one
The first type, the most visible one, is product-to-product mapping: every old product page address gets a permanent redirect to its exact equivalent on the new site. It sounds simple, but on a catalogue of thousands of products, "exact" matters — an approximate mapping, to a category instead of the precise product, sends a much weaker signal to the search engine than a precisely targeted, one-to-one redirect.
The second type, frequently overlooked, is category and filter mapping — the pages that list products by brand, attribute or series. These pages often accumulate just as much organic traffic as individual product pages, because people frequently search on generic category terms, not just exact product names. Leaving them out of the redirect plan means losing a significant slice of the site's recurring traffic.
The third type is the fallback rule, for content that genuinely disappears — products discontinued for good, categories merged or removed. Here the temptation is to redirect everything to the homepage, but a generic redirect to the homepage is almost as damaging as no redirect at all: it tells the search engine that the old page no longer has any relevant equivalent. It's better to target the closest parent category that's genuinely relevant to the content that's gone.
| Mapping type | Applies to | The typical mistake |
|---|---|---|
| Product → product | individual product pages | approximate redirect, to a category instead of the product |
| Category → category | archives, filters by attribute or brand | left out of the migration plan entirely |
| Fallback rule | content withdrawn for good | generic redirect to the homepage |
Build on staging and test in stages, not in a single move
The new site is built entirely on a staging subdomain, completely separate from the live site, no matter how small the catalogue seems or how tight the deadline is. The live site keeps selling normally while the new system is prepared in parallel, and any configuration mistake made during the build stays completely invisible to customers and to Google, because the staging page must never be indexed.
Catalogue migration is worth validating on a small sample before the full volume — in our project, the first 150 imported products immediately exposed a field-mapping error that would have affected the entire catalogue had we run it directly on thousands of products. A small batch, checked manually product by product, costs a few hours; the same mistake discovered only after the full import costs whole days of fixing and, sometimes, wrong redirects already published.
An automated import that "ran with no errors" doesn't mean it "ran correctly" — always manually check a sample, even when the script reports success.
The technical traps that don't show up in any proposal written beforehand
Product descriptions pulled from old systems sometimes come through double-encoded — the HTML text shows up as raw symbols on the page instead of normal paragraphs, because it was only partly "decoded" during the export-import process. It's obvious the moment you look at the page, but stays completely invisible in an automated report that only says the import succeeded. The simple rule: check a sample of real pages with your own eyes, not just the import script's return code.
The second, more subtle trap: an SEO plugin can calculate the meta title and description perfectly in the admin panel, yet never send them to the public page if it wasn't fully configured at install time. From the outside, the site looks optimised — the editor shows good scores — but the source code delivered to Google doesn't contain that metadata. The only reliable check is to open the published page's source code, not the plugin's internal panel score.
Cutover — how to switch to the new system without sales going down
The actual switch happens in a low-traffic window, with the old site kept accessible for a while, at least at the domain level, precisely so the 301 redirects have somewhere to start from. Suddenly shutting down the old server right after launch turns every old address into a straight-up error instead of a working redirect — exactly the scenario the whole migration plan is trying to avoid.
When the store also sells on marketplaces through automatic stock synchronisation, connecting that sync to the new system happens only in the last stage of cutover, not while building on staging. Otherwise, you risk a system still being tested pushing the wrong stock levels or prices to live channels, with real orders behind them — a mistake far more costly than any purely SEO-related issue.
What to track daily in the first weeks after launch
The coverage report in Search Console becomes, for a few weeks, the single most important tool to watch — any sudden jump in 404 errors or "indexed, but with issues" pages shows exactly where the redirect plan has gaps. Reacting quickly matters enormously: an error spotted and fixed within two days is a minor incident; the same error left for three weeks becomes traffic lost for good over that period.
Search engine rankings normally fluctuate for a few weeks after any major migration, even when everything is done correctly — it's a recalibration period, not necessarily a sign of error. The difference between "normal" and "a real problem" shows up when you compare traffic across broad categories, not individual terms: a widespread, sustained drop across every major category really is worth investigating immediately, not just monitoring passively. For organic growth after a migration, we've described separately how we work on SEO for online stores.
- 01Check the coverage report in Search Console daily, for the first two weeks.
- 02Compare organic traffic by broad category, not just individual pages.
- 03Manually confirm, on a sample, that the 301 redirects actually work, not just that they exist in the configuration.
- 04Keep the old site accessible at the domain level for as long as the redirects are active.
- 05Reassess the redirect plan after the first month, based on the actual errors Google reports.
Sources and further reading.
Frequently asked questions
How long does it take to fully recover after a platform migration?
Normally, a few weeks for rankings to settle, if the redirect plan was done right from the start. A migration with no redirect plan can mean months of partial recovery, not just a temporary dip.
Do I need a 301 redirect for category or filter pages too?
Yes — category and filter archive pages often build up organic traffic comparable to individual product pages, and they're exactly the type of page most often left out of a rushed migration plan.
What changes if the migration also involves a domain change, not just a platform change?
One extra mandatory step is added: the Change of Address tool in Search Console, alongside the 301 redirect plan. Without it, the "move" signal to Google is incomplete, even if the redirects work technically.
How do I know if I lost traffic because of the migration and not for some other reason?
You compare the period before and after the migration, on the same product categories, cross-checked against the coverage report in Search Console. A widespread drop, right around cutover day, points almost always to the migration, not to an algorithm change.
Is it worth keeping the old site active for a while after the new one launches?
Yes, at least at the domain and redirect-server level — 301 redirects need an active source to redirect from. Suddenly shutting down the old system turns every indexed address into a straight-up error.
What do I do with products that no longer exist at all in the new catalogue?
You redirect them to the closest relevant parent category, not to the homepage. If the product genuinely has no equivalent left, a proper error page is sometimes more honest than a forced, irrelevant redirect.
Let's see what can be automated in your business.
A free 30-minute session: we'll tell you what can be automated, how long it takes and what it costs, with a fixed price after discovery.