Classic vs headless WooCommerce
The short version: keep classic WooCommerce when one PHP server with good caching can serve a single storefront, and go headless when mobile speed caps revenue, the catalog is large, or one catalog must feed several frontends. Headless is not automatically better. It is better in specific conditions, and a rebuild outside those conditions just adds cost.
Headless WooCommerce means WordPress and WooCommerce stay as the backend, exposed through the Store API or WPGraphQL, while the PHP theme is replaced by a decoupled front end on Next.js or Astro that renders edge-cached HTML.
The decision matrix
| Criterion | Classic WooCommerce | Headless WooCommerce |
|---|---|---|
| Catalog size | Up to a few thousand SKUs | Large catalogs, faceted browsing |
| Mobile Core Web Vitals | Good with full-page caching | Best, zero PHP per request at the edge |
| Build and run cost | Lower, one stack | Higher, two stacks to maintain |
| Editorial experience | Native WordPress | Native WordPress, preview on a separate domain |
| Multiple frontends | One storefront | One catalog, many frontends |
| Checkout complexity | Native, simplest | Server-authoritative, more wiring |
| Time to ship | Faster | Around six weeks for a mid-size store |
When classic still wins
For a single storefront under a few thousand products, a classic WooCommerce on quality EU hosting with full-page caching, a clean database and optimized assets will hit sub-2-second mobile LCP without a rebuild. If your store is slow today, the cause is almost always infrastructure and technical debt, not the rendering model. Fix that first. The WooCommerce performance optimization guide covers exactly how, and it is far cheaper than going headless.
A brochure-scale store, a store with a small catalog, or a team without front-end capacity to maintain a second stack should stay classic. The maintenance cost of two stacks is real and recurring.
When headless wins
Headless earns its cost in three situations. First, when mobile Core Web Vitals directly shape revenue and a caching-tuned monolith still cannot hold sub-2-second LCP under load. Second, when the catalog is large and faceted browsing makes PHP rendering the bottleneck. Third, when one catalog has to feed several surfaces, such as a web storefront, a native app and an in-store kiosk, from a single source of truth.
In those cases the front end renders pre-built HTML at the edge with zero PHP per request, which removes the worst tail-latency cases, while WooCommerce keeps owning catalog, orders, tax and stock.
The part everyone underestimates: checkout
The checkout is where headless WooCommerce migrations succeed or fail. Payment, tax and order creation must stay server-authoritative inside WooCommerce. The front end orchestrates the steps, but the backend owns the money. Reimplementing checkout logic in the front end is how stores end up with mispriced orders and broken VAT. We keep the checkout server-side and let the front end drive the experience around it.
How the migration runs
The schedule is dominated by two things: keeping the checkout correct, and carrying SEO over without loss. We freeze the data contract first, build the front end against the Store API, keep checkout in WooCommerce, preserve every URL and structured-data block, then cut over behind a CDN with the old store still reachable until the new one is proven. A crawl diff before launch is what prevents the ranking drops that give headless a bad name.
WordPress newsletter
Tips, updates, and WordPress best practices once a month.
We respect your privacy. No spam.
Not sure which side you are on?
We map the trade-off against your real catalog, traffic and team before recommending anything. Often the honest answer is to optimize the classic store first and revisit headless later.
Weighing classic against headless?
Get a migration assessment. We score your store against the decision matrix, model the cost both ways, and tell you plainly which one fits, even when the answer is to stay classic.
Get an assessment →Related resources
- WooCommerce performance optimization - try this before a rebuild
- WooCommerce developer - how we work on stores
- Shopify Plus vs headless WooCommerce - if you are also weighing Shopify
- Headless WordPress: Next.js vs Astro - choosing the front-end framework
- Migration case study: PageSpeed 18 to 99 - a real rebuild onto a modern stack, load time 12s to 0.3s, with full metrics
