Replatforming Your Store Without Losing SEO, URLs or Sales

You lose SEO in a replatform at the URL layer, not the design. If product and category paths change with no redirects, if titles, descriptions and structured data are dropped, and if the sitemap is not resubmitted, rankings fall. Keep them by building a URL map, serving a 301 redirect for every old path, carrying over on-page metadata, and cutting over in stages you can verify.

This is a decision post as much as a how-to. If you want the migration planned and run for you, see how RAITHub would build this below. First, decide whether to replatform at all, then do it safely.

Should you replatform at all?

Only when the platform is the real limit, because a replatform always risks the traffic you already have. Good reasons are features your business depends on that the platform cannot do, costs that climb with every workaround app, or a front end you cannot make fast. Bad reasons are a redesign you could do in place, or slowness that is actually images and scripts. If the store is just slow, fix that first with the slow-store diagnosis before taking on a migration. The honest decision for hosted-platform limits is in when to move from Shopify to headless, and when not to.

Why does replatforming lose organic traffic?

Because search engines rank URLs, and a replatform usually changes them. When /products/blue-serum becomes /shop/skincare/blue-serum-123 with nothing connecting the two, the ranking the old URL earned has nowhere to go. Google's own guidance for a site move with URL changes is to redirect the old URLs to the new ones and keep the redirects in place long enough for the change to be processed (Google Search Central, site moves with URL changes). The other losses stack on top: dropped title tags and descriptions, missing Product structured data, and a sitemap that still lists the old paths.

What changes	How the traffic is lost	What prevents it
Product and category URLs	Ranked pages 404; link equity is stranded	A 301 redirect from every old URL to its new one
Title tags and meta descriptions	Snippets and relevance signals reset	Export and re-import on-page metadata per URL
Structured data (Product, Offer, Review)	Rich results disappear from search	Rebuild the schema on the new templates and validate it
Internal links and canonicals	Crawl budget wasted on redirects and duplicates	Update internal links to new paths; set correct canonicals
XML sitemap	Search engines keep crawling dead URLs	Publish a new sitemap and resubmit it at cutover

How do you build a URL map and redirects?

Export every indexed URL first, from your sitemap, your analytics and a crawl, then map each one to its new path. Every old URL needs exactly one destination, and a 301 (permanent) redirect, not a 302. Google treats a 301 as the strong signal that a page has moved for good.

// A row per old URL. Build this from the sitemap, Search Console and a crawl,
// then review the "unmapped" and "many-to-one" rows by hand before cutover.
type RedirectRow = {
  from: string      // old path, e.g. /products/blue-serum
  to: string        // new path, e.g. /shop/skincare/blue-serum
  status: 301       // permanent, never 302, for a real move
}

// Fail the migration build if any indexed URL has no mapping.
function findUnmapped(indexed: string[], map: Map<string, RedirectRow>): string[] {
  return indexed.filter((url) => !map.has(url))
}

Pay attention to three cases. A product that no longer exists should redirect to its category, not to the home page, so the signal is as relevant as possible. Several old URLs collapsing into one new page is fine as long as each is mapped. And a redirect that points at another redirect (a chain) wastes crawl budget, so flatten every chain to a single hop.

How do you keep the on-page SEO?

Carry the metadata over as data, not by hand. Export each page's title, meta description and canonical, keyed by URL, and apply them on the new templates during the import. Rebuild the structured data on the new product and category templates and validate it against Google's rules, because rich results are a common silent loss. Google's structured data guidance requires valid Product markup for merchant listings and rich results (Google Search Central, product structured data). Validate it with the Rich Results Test before and after cutover, and keep your heading structure and body copy, since that is what the page ranks for.

What does a safe cutover look like?

Stage it so nothing goes live unverified, and so you can tell within hours whether rankings are holding.

1. Build the new store on a staging URL that search engines cannot index. Keep it behind a password or a noindex header until launch.
2. Load the redirect map and test a sample of old URLs against it: each must return 301 to a live new page, with no chains and no 404s.
3. Validate structured data and metadata on a sample of product and category pages on staging.
4. Cut over at a low-traffic time, remove the noindex, publish the new sitemap and resubmit it in Search Console.
5. Watch for the first 72 hours: crawl stats, coverage errors, 404s in the logs, and the rankings of your top pages. Fix any unmapped URL that shows up as a 404 immediately.
6. Keep the redirects for months, not days. Google processes a move over time, so removing redirects early undoes the work.

Buy, build or hire?

Option	What you get	Choose this when
Platform migration app or tool	Data and sometimes redirect import between two supported platforms	You move between two mainstream platforms with a well-supported path
An SEO specialist for the plan	The URL map, redirect rules and a cutover checklist	Your developer can execute but you want the SEO plan to be right
Do it with your own team	Full control of the map, redirects and templates	You can crawl the site, build the map and test redirects before launch
A custom build with the migration included	New store, URL map, redirects and structured data done together	You are replatforming because the platform is the limit, not just the design

How long and risky is it to do yourself?

Building the URL map and redirects for a few hundred products is a few days of careful work; a large catalogue with faceted URLs is longer. The main risk of doing it yourself is declaring success at launch when the real test is the two weeks after, when unmapped URLs surface as 404s and rankings drift. Keep the logs open, watch Search Console coverage, and treat every 404 on a previously indexed URL as a redirect you missed.

How RAITHub would build this

• Scope: export every indexed URL, build and review the redirect map, carry over titles, descriptions and canonicals as data, rebuild and validate structured data on the new templates, stage the cutover behind noindex, and monitor the first 72 hours.
• Timeline: a custom store with the migration built in typically runs 6 to 12 weeks for the backend and templates; the redirect and SEO work runs alongside it, not as a last-minute step.
• What you receive: the reviewed URL map, redirects and SEO work tested in CI, a cutover runbook, the IP assigned to you and an NDA as standard.
• Next step: a free 15-minute technical audit, then a written fixed quote.

RAITHub grows TheSkinProof, the founder's own venture, through organic search with no paid ads, so SEO is treated as part of the build rather than bolted on after. The platform has 217 API endpoints and 750+ tests. For the wider context see the eCommerce industry page, and for moving data without loss during the migration, migrating products, customers and orders. To plan a safe replatform, read about a custom build or book the free 15-minute audit with your current platform and catalogue size.

Documentation checked on 11 October 2026.

Frequently asked questions

Will I lose my Google rankings if I replatform my store?

Not if you preserve the URL layer. Rankings are lost when old URLs 404 with no redirect, metadata and structured data are dropped, and the sitemap is not updated. A full URL map, a 301 redirect for every indexed page, carried-over metadata and a resubmitted sitemap keep the rankings you already have.

What redirect status code should I use for a replatform?

A 301 permanent redirect for every old URL, not a 302. A 301 tells search engines the page has moved for good, which is what passes the ranking signal to the new URL. Avoid redirect chains by pointing each old URL straight at its final destination in one hop.

Where should a discontinued product redirect to?

To its parent category, not the home page. A category page is the most relevant live destination, so it keeps more of the original signal and gives the buyer somewhere useful to go. Redirecting everything to the home page wastes the link equity the product page earned.

How long should I keep the redirects after a replatform?

Months, not days. Google processes a site move over time, so removing redirects early strands the URLs that have not been recrawled yet. Keep them in place well past the point where traffic and crawl stats have stabilised on the new URLs.

Do I need to rebuild my structured data when I replatform?

Yes. Structured data lives in the page templates, so new templates mean rebuilding your Product, Offer and review markup. Validate it with Google's Rich Results Test before and after cutover, because lost rich results are a common and easily missed drop in search visibility.

Should I replatform to fix a slow store?

Usually not on its own. Most slow stores get faster in place by fixing images, deferring scripts and adding database indexes. Replatform when the platform itself is the limit on features or cost, and diagnose the slowness first so you are not taking on migration risk for a problem you could fix cheaply.