PinwheelThe single biggest fear in any e-commerce replatform is the one nobody likes to say out loud: what if we lose our rankings?
It's a rational fear. Organic search is, for most independent retailers, the cheapest and most durable channel they have. A site that ranks for hundreds of product and category terms has accumulated that visibility over years. Move to a new platform carelessly — break the URLs, drop the structured data, ship pages search engines can't render — and you can erase a meaningful share of it in a weekend.
The good news: migrating a large catalogue to a headless store without losing SEO is a solved problem. It is not luck, and it is not something you hope works out. It's a checklist, executed before the cutover, not after.
This post is that checklist. We'll use a recent build of ours — Edith Wilmot, a Bristol luxury florist whose 609-product store we launched on a headless Next.js and Medusa v2 stack — as the worked example throughout.
Why Headless Migrations Are Higher-Risk Than They Look
A headless migration changes more under the hood than a like-for-like platform swap, and each change is a place SEO can leak away.
The rendering model changes. Many legacy platforms serve fully-formed HTML from the server by default. A naively built headless storefront, by contrast, can ship a near-empty HTML shell and render everything in the browser with JavaScript. Google can render JavaScript — but it does so on a delay and a budget, and for a brand-new store with no crawl authority, relying on that is a gamble. This is the single most important technical decision in a headless migration, and it's why our builds are server-rendered.
The URL structure often changes. New platform, new routing conventions, new slugs. Every URL that changes and isn't redirected is a page of accumulated link equity thrown away — and on a 600-product catalogue, that's a lot of pages.
The structured data and metadata can silently vanish. Legacy platforms and their SEO plugins inject a lot of invisible markup — title tags, meta descriptions, canonical tags, Open Graph data, and Product schema. A from-scratch storefront has none of that until you build it. Miss it, and rankings that depended on rich results quietly degrade.
Understand those three risks and you've understood 90% of the job. Now the playbook.
1. Crawl and Inventory the Old Site First
Before you touch the new platform, capture the full picture of the old one. You can't preserve what you haven't recorded.
Export, for every page that matters:
- The full list of indexed URLs (a crawler plus Google Search Console's page report)
- Title tags and meta descriptions
- Canonical tags
- Existing structured data
- Internal link structure
- Your top organic landing pages and the queries they rank for
That last point drives prioritisation. On a 600-product catalogue you will not hand-craft every single page, but you absolutely must protect the pages that already earn traffic. Identify them now, before anything moves.
2. Build a Complete 1:1 Redirect Map
This is the part of a migration that gets under-scoped more than any other — and it's the part that, done wrong, costs the most rankings.
Every old URL that has traffic or inbound links needs a 301 redirect to its matching new URL. Not a 302. A 301 is a permanent redirect, and it passes link equity to the new URL; a 302 signals a temporary move and tells search engines to keep the old URL indexed and not to transfer authority. For a permanent replatform, 301 is correct for every redirect, every time.
The map needs to cover all page types, not just products:
- Product pages
- Category and occasion pages (for a florist: weddings, sympathy, subscriptions, and so on)
- Informational and content pages
- Any old blog or guide content with backlinks
When slugs change, map old to new explicitly. Where you can keep a high-performing slug identical, do — a redirect is good, but no redirect needed is better.
For a catalogue the size of Edith Wilmot's, with 609 products plus their occasion categories, the redirect map is a deliverable in its own right: built, reviewed, and tested in staging before the cutover, not improvised on launch day.
3. Rebuild Metadata and Structured Data Deliberately
Your new storefront should ship with the full technical-SEO surface in place from day one:
- Title tags and meta descriptions for every page, migrated or rewritten — never left to a framework default.
- Canonical tags on every page, so faceted or parameterised URLs don't create duplicate-content confusion.
- Product structured data (Product schema with price, availability, and — where you have them — reviews) so product pages remain eligible for rich results.
- Open Graph and Twitter Card metadata for clean sharing.
A headless framework like Next.js makes this straightforward to do systematically — metadata generated from your product data, applied uniformly across hundreds of pages — rather than relying on an editor remembering to fill in a field. That consistency is itself an SEO advantage over a plugin-driven legacy site where metadata coverage is often patchy.
4. Ship the Crawl Infrastructure: Sitemap, Robots, SSR
Three technical foundations need to be live the moment the site is:
An XML sitemap listing every canonical URL, so search engines can discover your new structure quickly rather than crawling their way to it. On a large catalogue, generate it from your product data so it stays accurate as the catalogue changes.
A correctly configured robots file that allows crawling of everything that should be indexed and blocks what shouldn't (cart, checkout, account, internal search results).
Server-side rendering, so every page returns complete HTML — with its content, metadata, and structured data present in the initial response, not assembled later by JavaScript.
On the Edith Wilmot build, the XML sitemap, robots configuration, and structured data were all in place ahead of the DNS cutover — the SEO infrastructure was part of the launch, not a follow-up task. That sequencing is the whole point: the site presented itself correctly to search engines from the first crawl.
5. Stage, Verify, Then Cut Over
A headless launch typically ends with a DNS cutover — pointing the live domain at the new platform once everything is tested. Before you flip that switch, verify on staging:
- Every redirect in the map resolves to the correct new URL with a 301
- Key pages render full HTML with their metadata and structured data intact
- The sitemap is complete and the robots file is correct
- Product schema validates
- Page performance holds up on mobile
The discipline is simple: the cutover is the last step, not the first test. By the time the domain points at the new store, every SEO-critical element has already been confirmed in staging. That's exactly how Edith Wilmot went live at edithwilmot.co.uk — a clean cutover onto a platform that was already SEO-complete.
6. Monitor the Recovery — and Don't Panic
Even with a textbook migration, expect a short, shallow dip in organic traffic as search engines re-crawl and re-index the new structure. A modest dip that recovers over a handful of weeks is normal and is not a sign the migration failed.
In the days and weeks after launch:
- Submit the new sitemap in Search Console and request indexing of key pages
- Watch the coverage report for crawl errors and unexpected 404s
- Confirm 301s are being followed and old URLs are dropping out of the index in favour of the new ones
- Keep an eye on Core Web Vitals — a faster site is a tailwind, not just a defensive measure
What turns a temporary dip into a permanent loss is almost always one of the failures above: missing redirects, JavaScript-only rendering, or absent structured data. Get those right before the cutover and the recovery takes care of itself.
The Headless Advantage, Properly Used
Done carelessly, a headless migration is a way to lose rankings. Done properly, it's a way to improve the SEO foundations you migrate onto.
A server-rendered Next.js storefront gives you fast, fully-crawlable pages by default. Metadata and structured data generated systematically from your product data are more consistent across a large catalogue than anything a plugin-driven legacy site typically managed. And owning the whole stack — as Edith Wilmot does, right down to self-hosted product images — means no third-party dependency sitting in the critical path of how your store renders and gets crawled.
The fear of losing rankings in a replatform is legitimate. The way you answer it is not hope — it's a redirect map, server-side rendering, and the crawl infrastructure all in place before the domain ever points at the new site.
Planning a Replatform?
If you're weighing a move to headless commerce and the SEO risk is what's holding you back, that's the right thing to be careful about — and it's entirely manageable with the right plan. See how we built Edith Wilmot's headless platform end to end, or read our complete guide to headless e-commerce architecture for the bigger picture on whether headless is the right move for your store.