Replatforming without losing your rankings

Every store outgrows its platform eventually. The catalogue gets too big, the checkout cannot be changed without a developer, page speed sits at the bottom of every report, and someone finally says the word: replatform. (If the open question is still which platform, that is a decision about constraints, not features.)

Then, a few months after launch, organic traffic is down forty percent and nobody can say exactly when it started.

This outcome is common enough to be treated as inevitable. It is not. Almost all of it traces back to decisions made in the weeks before launch, by people who did not know they were making SEO decisions at the time.

The traffic was never in the platform

The first thing worth internalising: search engines do not rank your platform. They rank URLs, and they have accumulated a great deal of information about yours — which ones exist, what they contain, which ones other sites link to, which ones answer which query.

A migration threatens that in three ways, in descending order of damage:

URLs change and nothing tells anyone. This is the catastrophic one. Every external link, every stored ranking signal, every bookmark points at an address that now returns a 404. The authority those pages accumulated does not transfer; it evaporates.

Content thins out. Category descriptions get dropped because the new theme has nowhere to put them. Product copy is truncated to fit a template. The page still exists, but there is less on it than there was, and it ranks accordingly.

Technical signals regress. The new build is slower, or renders products in JavaScript that the old one served in HTML, or ships structured data that is subtly wrong — exactly the regressions a pre-launch technical SEO audit exists to catch.

Only the first is dramatic. The other two are quiet, and they are the ones that show up as a slow bleed nobody attributes to the migration.

Start with an inventory, not a design

The correct first artefact of a replatforming project is not a mockup. It is a complete list of every URL the current site serves that anyone reaches.

Build it from four sources, because no single one is complete:

The crawl. Everything reachable by following links from the homepage.
Search Console. Everything that has received an impression in the last sixteen months. This catches pages the crawl misses because nothing links to them any more — often old campaign landing pages that still rank.
Server logs or analytics. Everything that has received a visit. This catches pages nobody links to and that rank for nothing, but which someone bookmarked.
The backlink profile. Everything another site points at, including pages that have been dead for years. A 404 with links pointing at it is recoverable value.

Deduplicate, and you have the thing the whole migration must respect.

Map every URL to a decision

Each URL in the inventory gets exactly one of four verdicts, and none of them is “we’ll see”:

Keep the address. The safest possible outcome. If the new platform can serve the same path, let it. Every URL you do not change is a redirect you do not have to get right.

Redirect to the closest equivalent. A permanent 301 to the page that answers the same need. “Closest equivalent” means a page a visitor arriving from that search would consider a reasonable answer — not the homepage, not a generic category.

Redirect to a parent. For discontinued products with no successor, the category is the honest destination.

Let it go. Some URLs should die: duplicate filter combinations, expired promotions, session-parameter noise. Deciding this deliberately is very different from discovering it afterwards.

The failure mode here is mass-redirecting anything uncertain to the homepage. Search engines treat a bulk redirect to the root as a soft 404 and discard the signal entirely — you get the same loss as doing nothing, plus the work.

Protect content parity

Before launch, compare old and new page by page on the pages that matter — your top revenue and top organic URLs, which are rarely the same list.

For each, check that the title and heading structure still express the same topic, that body copy has not been silently trimmed by a template, that structured data still validates, that internal links to it still exist, and that images kept their alt text.

Template-driven truncation is the sneakiest of these. A category description that ran four paragraphs on the old site becomes two lines in a new design that has no room for it, and the page quietly stops being the best answer to its query.

Launch is a sequence, not a moment

Order matters more than speed:

Stage the new site behind authentication, so it can be crawled by you and nobody else. A staging site indexed by accident creates duplicate content against your own store.
Test the redirect map against the inventory. Every URL, automated. Assert a 301 and the expected destination, not merely a non-404 — a redirect chain that resolves through four hops still loses time and signal.
Switch. Keep the redirect layer at the edge, not in application code, so it survives a rollback.
Resubmit the sitemap immediately and leave the old sitemap reachable for a few weeks. It is how crawlers find the URLs that need re-evaluating.
Watch server logs for 404s daily for the first fortnight. Real traffic finds URLs your inventory missed. Every one is a redirect you can still add.

The twelve weeks after

Rankings wobble after a migration even when everything is done correctly. Crawlers must revisit every URL, follow every redirect, and re-evaluate. This takes weeks, and during it positions move in both directions.

Knowing this matters, because the most expensive mistake in a replatforming project is panicking in week three and reverting a change that was working.

Judge it on three things instead of daily rank checks: whether the number of indexed pages is recovering toward the previous level, whether 404s in the logs are trending to zero, and whether the pages you identified as top organic URLs are holding. If those three are healthy, the wobble is normal.

If indexed pages keep falling after six weeks, something in the redirect map is wrong, and it is worth re-running the inventory against live crawl data before touching anything else.

What actually makes it safe

A migration that keeps its rankings looks boring from the outside. Nothing dramatic happens on launch night, because the difficult work happened weeks earlier in a spreadsheet nobody wanted to build.

The store that loses forty percent is rarely the one with the worse design or the weaker platform. It is the one where nobody made the URL inventory, and every redirect decision was improvised in the final week by someone who did not know which pages were load-bearing.

It is also why the inventory is the first deliverable of every e-commerce migration we run — not a favour to the SEO team, but the project’s safety net.