Headless Commerce SEO: The 10-Point Pre-Migration Audit Before You Replatform

Headless commerce (decoupling the storefront frontend from the commerce backend) is increasingly the default for stores doing $5M+ ARR. The performance, flexibility, and developer-experience wins are real. But the SEO migration risks are also real: in our analysis of 40+ headless migrations we've seen, roughly one-third experience a 20%+ organic traffic decline within 90 days post-launch, almost always traceable to migration-time technical issues that could have been caught with a pre-migration audit.

Below is the 10-point pre-migration audit. Run this before you cut over from a monolithic Shopify or BigCommerce build to a headless setup on Hydrogen, Next.js, Remix, or Nuxt.

1. Inventory Every URL That Currently Receives Organic Traffic

Before the migration, export the complete list of URLs that Google has indexed. Don't trust your sitemap — pull from Google Search Console's "Pages" report and filter to indexed pages. For larger stores, also use a crawler like Screaming Frog or Sitebulb to identify URLs that don't appear in your sitemap but are crawlable.

The output should be a CSV with: URL, current 30-day clicks, current 30-day impressions, current ranking keyword(s). Sort by clicks descending. The top 20% of URLs typically generate 80%+ of organic traffic — these are your migration priorities.

2. Map Every Indexed URL to a Post-Migration URL

The single biggest source of headless migration traffic loss: URL pattern changes. A monolithic Shopify store typically uses /products/handle for products and /collections/handle for categories. A headless rebuild on Next.js might use /p/[slug] and /c/[slug] instead — and unless you 301 redirect every old URL to its new equivalent, you lose every backlink and every ranking signal.

Build a 1:1 redirect map: every old URL → new URL. Then validate that map programmatically:

• Every old URL should redirect with a 301 (not 302)
• Every redirect should land on a 200 response (not chained through multiple redirects)
• Redirects should preserve query parameters where they matter (e.g., variant selection)

The Redirect Checker validates redirect chains. Run it against your top 100 URLs post-migration to confirm the map is implemented correctly.

3. Audit Internal Linking Structure

Headless storefronts often introduce JavaScript-rendered navigation menus, mega-menus, and footer links. Googlebot can render JavaScript — but it does so on a delayed crawl tier with a quota. If your category navigation is hidden behind a hydration boundary, Google may not discover the links on first crawl.

Audit the link graph two ways:

• JavaScript disabled — load each page type with JS disabled. Are the same links visible? Critical navigation should work without JS.
• Render-blocking inspection — view source on key pages. Are the category links and product links present in the initial HTML, or only after JavaScript hydration?

Server-side rendering (SSR) or static site generation (SSG) for navigation is non-negotiable for ecommerce headless. Client-side rendering (CSR) of category menus is one of the most common — and most damaging — headless SEO mistakes.

4. Validate Structured Data Preservation

Product schema, breadcrumb schema, organization schema, and review schema all need to migrate. Headless rebuilds frequently lose schema markup because the source-of-truth structured data was generated by the legacy theme — and the new frontend hasn't been wired up to emit it.

Pre-migration: run the Structured Data Checker on representative pages (homepage, category, product, blog post). Document every schema type and required field. Post-migration: validate that the same schema types and field coverage exist on the new pages.

The schema types that drive ecommerce SERP features:

• Product — required for product rich results, shopping graph eligibility
• AggregateRating — drives the review stars in search results
• BreadcrumbList — improves SERP click-through
• FAQPage — drives FAQ accordion rich result (where still eligible)

5. Test Canonical Tag Behavior

Headless frameworks have different canonical tag patterns than monolithic CMSs. Common mistakes:

• Self-referencing canonicals that point to a parameterized URL instead of the clean URL
• Missing canonicals on paginated category pages
• Canonicals that include trailing slashes inconsistently with the actual URL pattern
• Multiple canonical tags on the same page (e.g., one from the framework, one from a SEO plugin)

Run the Canonical Checker on every page type to confirm canonicals match the indexable URL.

6. Verify hreflang Implementation (Multi-Region Stores)

If you serve multiple markets with localized URLs (/us/, /uk/, /de/), every page needs reciprocal hreflang annotations. Headless frameworks handle this well when configured — and catastrophically when not. Common failures:

• hreflang tags pointing to URLs that don't exist post-migration
• x-default missing or pointing to the wrong fallback
• Inconsistent hreflang between sitemap.xml and HTML head

The Hreflang Checker validates the implementation across language and region variants.

7. Performance Baseline (Before and After)

One of the main reasons to go headless is performance. Establish a baseline before migration so you can prove the win — and so you can detect regressions if the migration actually makes things worse. Capture for 5–10 representative pages:

• Largest Contentful Paint (LCP)
• Interaction to Next Paint (INP)
• Cumulative Layout Shift (CLS)
• Time to First Byte (TTFB)
• Total Blocking Time (TBT)
• Total page weight (HTML + CSS + JS + images + fonts)

Use the Web Vitals Checker for Core Web Vitals and the Page Weight Checker for resource budgets. Take these measurements 1 week pre-migration and 1 week post-migration. If post-migration Core Web Vitals are worse, the headless rebuild didn't deliver its main promise.

8. Indexability Audit on Staging

Before launch, audit indexability on your staging environment — but first confirm staging is correctly noindexed. The pre-launch checklist:

• Staging environment returns X-Robots-Tag: noindex headers
• Staging robots.txt blocks all crawlers
• Production environment removes those blocks at cutover

The most common headless launch disaster: deploying with the staging noindex still active on production. We've seen migrations lose 70% of organic traffic in a week from a forgotten noindex meta tag that should have been environment-conditional. The Indexability Checker validates that critical pages are indexable post-launch.

9. Plan for Search Console Reverification

If your migration changes the domain or major URL patterns, you'll need to:

• Verify the new property in Google Search Console (if domain changes)
• Submit a new sitemap.xml from the new build
• Use the "Change of Address" tool if changing domain
• Monitor the "Pages" report for crawl errors during the first 30 days

Plan to spend an hour daily for the first 2 weeks in Search Console post-launch, watching for crawl spikes, 404s, and index removal.

10. Set Up Performance and Health Monitoring Post-Launch

Pre-launch is the audit; post-launch is the surveillance. Set up continuous monitoring that catches regressions:

• Site health monitoring — daily or weekly automated scans that alert on score drops
• Search Console alerts — daily check on indexed page count, average position
• Real-user Core Web Vitals — RUM data segmented by page type
• Crawl coverage — weekly review of GSC's Pages report for unexpected 404s or noindex

Run a baseline scan with StoreVitals pre-migration, then schedule weekly scans post-launch. Alert rules can fire when the score drops by 10+ points or when new critical issues appear. This catches the 90% of post-migration regressions that are detectable from page-level technical signals.

The Migration Window

The first 30 days post-migration are the highest-risk window. Google's re-crawl and re-indexation happens at a delayed pace — a problem you create on launch day may not affect rankings for 1–3 weeks. The pre-migration audit prevents the issues from existing; the post-migration monitoring catches the ones that slipped through. Both together typically reduce migration-traffic-loss risk from 30% to under 5%.