Short answer: headless WooCommerce keeps WooCommerce for products, stock, orders and payments, and replaces the WordPress theme with a separate front end, usually built in Next.js, that reads the shop through an API. Customers get a faster, fully custom storefront; your team keeps the WooCommerce admin it already knows. It pays off for shops whose theme has become the bottleneck, and it is overkill for a catalogue that a good theme already sells well.
This guide is for owners and managers weighing the move. It covers what changes, what stays the same, what it costs, where these projects go wrong, and how to tell whether your shop is ready.
What “headless” actually means for a WooCommerce shop
In a normal WooCommerce site, WordPress does two jobs: it stores the shop and it renders every page through a theme. Headless splits those jobs. WordPress and WooCommerce stay where they are and keep storing everything. A second application, the storefront, fetches products, prices and content over an API and builds the pages your customers see.
On our builds the storefront is Next.js, the API is WPGraphQL with the WooCommerce extension, and a CDN sits in front. When someone saves a product in WordPress, the storefront rebuilds only the pages that show it, within seconds. The WordPress address never appears in the page, in the images or in the emails.
| Part of the shop | Traditional WooCommerce | Headless WooCommerce |
|---|---|---|
| Products, stock, orders, customers | WooCommerce | WooCommerce (unchanged) |
| Admin your team uses | WordPress admin | WordPress admin (unchanged) |
| Pages customers see | WordPress theme + page builder | Custom Next.js storefront |
| Cart and checkout | Theme templates and plugins | Built in the storefront, calling WooCommerce |
| Plugins that output HTML | Work out of the box | Rebuilt as storefront components |
| Speed ceiling | Set by theme, plugins and PHP | Set by the storefront and CDN |
What changes for customers, and what changes for your team
Customers notice speed first. Pages are pre-rendered and served from the edge, so browsing a category or opening a product feels instant rather than fast-for-WordPress. Design is the second change: there is no theme to fight, so the product page, filters and checkout can be exactly what the brand needs.
Your team notices less than they fear. Products are still added in WooCommerce, orders still arrive in WooCommerce, and the payment provider still reports to WooCommerce. What changes is that visual edits to the storefront are made in code, not in a page builder. Content that marketing edits often, such as landing pages, banners and blog posts, stays editable in WordPress, provided the build plans for it. That is one of the twelve decisions to settle before anyone estimates a build.
When headless pays off
We recommend it when at least two of these are true:
- The theme is the reason you cannot ship a design or feature, and every change turns into a fight with a page builder.
- Mobile Core Web Vitals are failing and you have already tried caching, image optimisation and removing plugins.
- You sell in several markets and want one catalogue behind different storefronts, currencies or languages.
- The catalogue has more than one reader: a marketplace feed, a wholesale portal, an app, or an AI assistant that queries products.
- You want a checkout that is one page, designed like the rest of the site, instead of the stock WooCommerce flow.
- You plan loyalty, referrals, subscriptions or B2B pricing, and want them designed rather than bolted on with plugins.
When it does not
Headless is the wrong move if the shop is new and has not proved its product, if nobody will own the front end after launch, or if the real problem is content, pricing or traffic rather than the site. A well-built WordPress and WooCommerce site on a fast theme is the right answer for most small shops, and it is what we build for them. Headless WooCommerce for a small shop goes through that decision in detail. If you are also looking at hosted platforms, our comparison with Shopify lays out that choice.
What it costs
A basic headless WooCommerce build starts at around USD 25,000 in labour. Shops with loyalty programmes, referrals, gamification or B2B accounts regularly go past USD 100,000. The number is driven by scope decisions, not by the word headless: checkout, accounts, search, integrations and migration size move it far more than the framework does. The full breakdown is in what a headless WooCommerce build costs.
The stack in 2026
| Layer | What we use | Why |
|---|---|---|
| Shop and content | WordPress + WooCommerce | Your team already knows it; every business rule stays in one place |
| API | WPGraphQL + WPGraphQL for WooCommerce (v1.0) | One typed API for products, cart, checkout and customer accounts |
| Storefront | Next.js 16 with Cache Components | Pages cached until the data behind them changes, then rebuilt on demand |
| Edge | Cloudflare | HTML and media served close to the customer |
| SEO | Yoast data exposed through the API | Titles, descriptions and schema edited in WordPress, rendered by the storefront |
WooCommerce also ships its own Store API, a REST API for cart and checkout. It is a sound choice for a small storefront; we prefer GraphQL when the same catalogue feeds several readers, because every query is defined once and cached on both sides. We compare the two in WooCommerce Store API vs WPGraphQL.
Where headless WooCommerce projects go wrong
Almost every rescue we are asked to do fails in one of the same places:
- Emails. WooCommerce builds links in order emails from the WordPress address, so customers get links to a site they were never meant to see. Every customer email has to be checked by rendering it, not by reading templates.
- Password reset. The reset link points at an account page on the storefront that nobody built. It works in the demo and breaks the first week after launch.
- Plugins that render HTML. Sliders, badges, filters and wishlist widgets output nothing in a headless build. They have to be listed early and rebuilt.
- Cache that never updates. A product is edited, and the old price stays online because the CDN kept a copy. Publishing has to trigger both the storefront and the CDN.
- Nobody owns the front end after launch. Two applications need two sets of updates. Put the maintenance owner in the contract.
SEO on a headless shop
Search engines only see the storefront. Titles, descriptions and schema are still edited in WordPress and passed through the API, and the storefront renders them together with canonical URLs, sitemaps, breadcrumbs and product structured data. Old URLs get permanent redirects from the storefront. Done this way, a headless shop is easier to crawl than most themes, because every page arrives as finished HTML instead of being assembled by scripts. The setup is explained in headless WordPress SEO.
How a project runs with us
- Decisions call. We go through the twelve decisions with you: checkout, accounts, search, freshness, media, emails, preview, other readers, migration and maintenance.
- Written offer. A fixed scope and price, with what is out of scope stated as clearly as what is in.
- Build next to the live shop. The storefront is built against a copy of your WooCommerce, so the current shop keeps selling.
- Migration and launch. Every old URL is kept or redirected (see moving WooCommerce to headless without losing rankings), emails are tested, and launch is a switch of the domain, not a rebuild weekend.
- Handover or maintenance. Your team, our team, or both, agreed before launch.
You can see the result on Pewes Energy, the headless WooCommerce shop we built as a live reference, with its catalogue, cart, checkout, accounts and rewards all running on this stack. The service itself is described on our headless WooCommerce page.
Frequently asked questions
Plugins that manage data, such as payment gateways, shipping, stock and subscriptions, keep working because WooCommerce still runs them. Plugins that only output HTML on the page have to be rebuilt in the storefront.
Yes. Products, orders, customers and content are managed in the same WordPress and WooCommerce admin as today. Only the design of the storefront moves into code.
It is good for SEO when the storefront renders pages on the server and reads titles, descriptions and schema from WordPress. It hurts when pages render only in the browser or when old URLs are not redirected.
A basic build starts at around USD 25,000 in labour. Builds with loyalty, referrals, gamification or B2B features can exceed USD 100,000. The exact figure depends on the scope decisions and comes as a written offer.
You need somewhere to run WordPress and somewhere to run the Next.js storefront. They can live on the same server or on separate platforms; we advise on the setup that fits your traffic and team.
