Ecommerce team planning a WooCommerce storefront project around a meeting table

WooCommerce · Headless · Next.js

Headless WooCommerce: keep your backend, rebuild the storefront in Next.js

Your products, orders, customers and admin stay in WooCommerce. We build a Next.js storefront on top, connect it through the current WooCommerce APIs, and move your traffic over with your rankings and checkout protected.

Plan my headless migration Is headless right for my store?

Cmsmart Ecommerce, a Netbase JSC division building WooCommerce solutions since 2012.

ShopperCDN / edge
StorefrontNext.js
APIsStore API · REST v3 · GraphQL
BackendWooCommerce + WordPress admin

Your data stays in WooCommerce. Only the storefront changes.

What is headless WooCommerce?

Headless WooCommerce means WooCommerce keeps running your catalog, cart, orders and admin, while shoppers see a separate storefront, usually built in Next.js, that reads and writes data through the Store API, the REST API or GraphQL. Cmsmart plans and builds that storefront and the migration, scoped and quoted per project.

Updated October 2026 · WordPress and WooCommerce API facts checked on 5 October 2026 against the official documentation listed under Sources.

The APIs in 2026

What changed in the WordPress and WooCommerce APIs for headless stores?

WooCommerce now ships a public Store API for cart and checkout, cart tokens that work across domains, a checkout total check, and a current authenticated REST API v3. Together they let a Next.js storefront run the full shopping flow while WooCommerce stays the system of record.

Developer writing API integration code on a laptop

Release	What changed	Why it matters for a Next.js storefront
WordPress 7.1 and WooCommerce 11.1	WordPress 7.1 is the current major release. WooCommerce 11.1.2 was released on 22 September 2026 and requires WordPress 7.0 and PHP 7.4 or later. Source: WordPress 7.1 Field Guide, make.wordpress.org; WooCommerce plugin page, WordPress.org (version 11.1.2, requirements).	A headless project starts on a current, supported backend. We upgrade and test WordPress, WooCommerce and your plugins before any API work.
Store API (wc/store/v1)	Public, unauthenticated endpoints for customer-facing products, cart and checkout. A Cart-Token header identifies the cart instead of a cookie session. Source: Store API documentation, developer.woocommerce.com; Store API Cart Tokens, developer.woocommerce.com.	This is the API a Next.js storefront uses for the cart and checkout, so shoppers keep their cart across devices and sessions without WordPress cookies.
Cart-Token on CORS requests (WooCommerce 9.8)	WooCommerce 9.8 exposes the Cart-Token on CORS-protected requests, so a browser on another domain can read it without a proxy. The nonce is still not exposed. Source: Store API updates coming in WooCommerce 9.8, developer.woocommerce.com.	A storefront on its own domain or CDN can talk to the Store API directly; fewer moving parts between the shopper and the cart.
Checkout total check (WooCommerce 11.1)	Store API checkout accepts an optional expected_total. If the charge would differ from what the shopper saw, the request fails with 409 woocommerce_rest_checkout_total_mismatch. Source: WooCommerce 11.1: what is coming for developers, developer.woocommerce.com.	A headless checkout can send the total it displayed and stop a payment when prices, shipping or coupons changed in the meantime.
REST API v3 and refunds (WooCommerce 11.1)	v3 is the current authenticated REST API. WooCommerce 11.1 adds server-calculated refunds (compute_totals) and a refunds preview endpoint, and skips block registration on REST, cron and AJAX requests. Source: WooCommerce REST API documentation, developer.woocommerce.com; WooCommerce 11.1: what is coming for developers, developer.woocommerce.com.	Back-office tasks (orders, refunds, stock, ERP sync) stay on authenticated server-side calls; keys never reach the browser.
Cart and Checkout blocks	Since WooCommerce 8.3 the Cart and Checkout blocks are the default for new stores; existing stores keep their checkout until they switch. Payment extensions declare block compatibility separately. Source: FAQ: Cart and Checkout blocks by default, developer.woocommerce.com.	Before choosing a checkout option we check each payment and shipping extension you use for block and Store API support.
WPGraphQL and WooGraphQL	WPGraphQL 2.23.1 was updated on WordPress.org on 22 September 2026. WooGraphQL (WPGraphQL for WooCommerce) is on its v1.0 line: v1.0.3 shipped on 30 June 2026, and v1.0 aligned its data loaders with WPGraphQL 2.3 and later. Source: WPGraphQL plugin page, WordPress.org; WPGraphQL for WooCommerce releases, GitHub.	GraphQL is an option when the storefront needs flexible queries across content and catalog. We compare it with REST plus Store API per project.

Decision guide

Is headless right for your WooCommerce store?

Go headless when your store needs a storefront the theme cannot deliver, several storefronts on one backend, or speed targets that still fail after hosting and plugin cleanup, and you can run a second codebase. Otherwise, optimizing classic WooCommerce costs less and keeps every plugin working.

Store owner reviewing storefront performance on a laptop and phone

Situation	Stay on classic WooCommerce when…	Go headless when…
Catalog and design	A theme and the block editor already deliver the design you need.	You need a storefront experience the theme cannot deliver without fighting it.
Speed	Slow pages are explained by hosting, caching, images or heavy plugins, and fixing those is enough.	Your Core Web Vitals field data still misses the target after that cleanup, on pages that must stay dynamic.
Storefronts	You run one store, in one language, on one domain.	You want several storefronts (regions, brands, B2B and B2C) on one WooCommerce backend.
Plugins	The store depends on many frontend plugins: page builders, popups, checkout add-ons.	The frontend needs few plugins, or their logic can move into the storefront or the API.
Team and budget	There is no developer to own a second application.	There is budget and a team, in-house or with us, to run two codebases.
Content editing	Marketers edit pages in WordPress every day and need what they see to be what ships.	Content can keep living in WordPress as a headless CMS, with a preview step for editors.

Options in between

Optimize classic WooCommerce Hosting, caching, image and plugin cleanup on your current theme. Learn more
Add a PWA layer App-like speed and install on mobile without rebuilding the whole storefront. Learn more
Go hybrid Only catalog and product pages go headless; cart and checkout stay on WooCommerce. Custom development, scoped per project.

Architecture

How does headless WooCommerce work?

WooCommerce stays the system of record for products, prices, stock, orders and customers. A Next.js storefront reads the catalog through REST or GraphQL, runs cart and checkout through the Store API or hands off to WooCommerce checkout, and is served from a CDN close to shoppers.

Backend WooCommerce on WordPress Products · prices · stock · orders · customers · admin plugins

API layer Store API · REST API v3 · WPGraphQL Cart-Token sessions · webhooks for revalidation

Storefront Next.js Static and revalidated catalog pages · server-rendered cart and account

Delivery CDN / edge Pages served close to shoppers

Payment providerERP / CRM / email via webhooksSearch service (optional)Image CDN

Headless WooCommerce architecture: WooCommerce backend, API layer, Next.js storefront and CDN. The exact stack is scoped per project.

Which API does which job?

Storefront task	API	Note
Catalog, category and product pages	REST API v3 or GraphQL, called on the server at build or revalidation time	API keys stay on the server; pages can be cached at the edge.
Cart, coupons, shipping rates	Store API with a Cart-Token	Designed for customer-facing use without API keys.
Checkout	Store API checkout (with expected_total), or a hand-off to WooCommerce checkout	See the checkout options below.
Customer account and orders	Store API order endpoint and authenticated server-side calls	Session and login design is agreed in the architecture phase.
Price, stock and content changes	WooCommerce webhooks that trigger page revalidation	Keeps cached pages in step with the store.
Back office (orders, refunds, ERP, email)	Stays in WooCommerce admin and its plugins; REST API v3 for integrations	Staff keep the screens they know.

Checkout

Which checkout should a headless WooCommerce store use?

There is no single right answer. Choose by your payment and shipping extensions, how much design control you need at checkout, and how much testing you can fund. We check every extension you use before you decide.

Option	How it works	Fits when	Trade-off
Keep WooCommerce checkout	The storefront hands the cart to the WooCommerce checkout page on your domain or a subdomain.	Your payment and shipping plugins only work on the classic checkout, or speed to launch matters most.	The checkout looks and loads like WordPress, not like the new storefront.
Headless checkout on the Store API	The Next.js storefront renders checkout and calls the Store API checkout endpoint.	You want one design from product page to order confirmation, and your gateways support it.	Every gateway and checkout add-on must be tested against the Store API flow.
Provider-hosted payment step	The storefront collects the order; the payment provider hosts the card step.	You want a smaller card-data footprint on your own pages.	Shoppers see the provider page for a moment; branding there is limited.

Scope

What stays in WooCommerce and what gets rebuilt?

Data and back office stay. The customer-facing layer is rebuilt. The audit turns this into a plugin-by-plugin list for your store.

Stays in WooCommerce

Products, variations, prices and stock
Orders and full order history
Customers, accounts and coupons
Tax, shipping and payment settings
WooCommerce admin and back-office plugins (ERP, accounting, email, order export)

Rebuilt in the storefront

Theme templates and page-builder pages
Frontend plugins: sliders, popups, wishlists, filters, review widgets
Search interface and account pages
Analytics tags and cookie consent
Sitemaps, structured data and meta tags (rebuilt to match the old ones)

Cmsmart Product Designer t-shirt editor inside a WooCommerce product page

Product designer stores

The Cmsmart Product Designer (NBDesigner) runs inside WooCommerce product pages. In a headless storefront it does not move across on its own: we handle it as hybrid or custom development, scoped per project. For example the design step stays on a WooCommerce page, or the Next.js product page opens the designer and returns the design to the WooCommerce cart.

Keep-WooCommerce headless migration

How do we migrate without losing SEO, orders or checkout?

Six phases. Each ends with a deliverable you sign off before the next one starts, and your store keeps selling on the current theme until cutover.

Audit
Plugin inventory and classification, URL and traffic inventory from Search Console, Core Web Vitals baseline, integrations list, and a go or no-go recommendation, which can be "stay on classic WooCommerce".
Architecture
API choice per feature, checkout option, rendering strategy per page type, hosting and CDN, sessions and login, environments, and the inputs for your cost formula.
Data and SEO preservation
A URL map from old to new (identical URLs wherever possible, one 301 for every change, no chains), canonical tags, Product and Breadcrumb structured data, sitemaps, titles and descriptions kept in parity, internal links, analytics and consent.
Build
The Next.js storefront in sprints, API extensions and webhooks in WooCommerce, and a staging storefront connected to a copy of your store data.
Cutover
A content freeze window, a crawl of staging against the live site (status codes, titles, structured data), real test orders on every payment method, the DNS and CDN switch, and a rollback plan with the old theme kept ready.
Hypercare
A support window agreed in your proposal: daily checks of 404s, Search Console coverage, Core Web Vitals field data and order or payment errors, then handover or ongoing support.

SEO practice follows Google's guidance on site moves with URL changes.

Business meeting table with notes and coffee during a store audit

Audit first

The audit decides whether headless is worth it for your store at all, and lists every plugin that will keep working, need an API or need rebuilding.

Blueprint sheets clipped together on a planning table

Rankings carried over

The URL map and a crawl comparison are signed off before cutover, so Google sees the same pages, titles and structured data at the same addresses.

Server rack with status lights in a data room

Cutover with a way back

Test orders on every payment method, a monitored switch, and the old theme ready to restore if a check fails.

Risk checklist

What can go wrong, and how is it controlled?

Rankings drop after launchURL map, 301 rules, structured data parity and a staging-versus-live crawl before cutover; daily Search Console checks after.
A payment gateway does not support the new checkoutGateway check in the architecture phase; keep WooCommerce checkout for that method if needed.
A plugin feature disappearsEvery plugin is classified in the audit: keeps working, has an API, or is rebuilt or replaced.
Stale prices or stock on cached pagesWebhook-driven revalidation and short cache rules on price and stock data.
Editors lose their previewPreview mode in the storefront, or WordPress kept as the content editor.
Two codebases to maintainNamed owners for storefront and backend, update routine for WordPress, WooCommerce and Next.js, agreed before launch.

Total cost of ownership

What does a headless WooCommerce store cost to run?

Use this formula with your own numbers to compare headless with optimizing your current theme. Cmsmart quotes the build after a discovery call; there are no fixed packages.

TCO (12 months) = Build
                + Frontend hosting and CDN × 12
                + WooCommerce hosting × 12
                + Paid services × 12
                + Maintenance hours per month × rate × 12
                − Retired licence costs

Variable	What it covers	Where you find it
Build	Discovery, architecture, storefront sprints, migration and QA	Your project proposal
Frontend hosting and CDN	Monthly plan of the host that serves the Next.js storefront	Host pricing page
WooCommerce hosting	Your current or upgraded WordPress hosting	Current invoice
Paid services	Search, image CDN, monitoring, plugin licences	Vendor pricing pages
Maintenance	Hours per month across two codebases, times the hourly rate	Support plan
Retired costs	Theme, page builder and frontend plugin licences you no longer need	Current licences

Experience

Who builds it?

Headless and decoupled WooCommerce builds are part of Cmsmart's custom-development work. The same Netbase JSC team builds Printcart, a web-to-print platform whose public site runs on a Next.js 14 and React 18 frontend that reads its content and catalog from separate APIs.

For WooCommerce merchants, Printcart also publishes the Printcart Store plugin on WordPress.org, so the team works on both sides of the API: the WordPress backend and the JavaScript frontend.

Printcart.com home page, a Next.js frontend built by the Netbase JSC team

How the project runs

Request and discovery call with an ecommerce consultant
Written proposal with scope, milestones and estimate in your dashboard
Milestones and sprints with a project manager, progress visible to you
QA and user acceptance testing on staging
Launch, then the support window agreed in your proposal

See how Cmsmart delivers ecommerce projects

Project milestones with status and due dates in the Cmsmart client dashboard

Real numbers, real clients

Trusted by store owners in 80+ countries

What we have delivered since 2012, and what customers say about working with us.

6,300+ client projects since 2012
4,600+ projects delivered since 2012
1,800+ live stores online now
80+ countries clients worldwide
500+ custom development projects since 2012
120+ engagements running 5+ years ongoing support

Since 2012 · a Netbase JSC company · as of Sep 2026 · source: WorkSuite project records

Rated by customers on third-party sites (as of Sep 2026)

Teams in 80+ countries run their ecommerce projects with Cmsmart

Delivered & maintained with WorkSuite: tickets, tasks, milestones and invoices in one place. See how it works

FAQ

Questions store owners ask about headless WooCommerce

Can I keep WooCommerce admin and my order history if I go headless?

Yes. In a headless WooCommerce build the products, orders, customers, coupons and settings stay in WooCommerce, and your team keeps using WooCommerce admin. Only the storefront that shoppers see is rebuilt, so there is no data migration of your order history.

Will I lose Google rankings when I move to a headless storefront?

Rankings are at risk when URLs, titles, content or structured data change. Cmsmart keeps URLs identical wherever possible, adds one 301 redirect for every change, keeps titles and Product and Breadcrumb structured data in parity, crawls staging against the live site before cutover, and watches Search Console after launch.

Which API should a Next.js storefront use with WooCommerce: REST, Store API or GraphQL?

Usually more than one. The Store API (wc/store/v1) is built for customer-facing cart and checkout and uses a Cart-Token instead of cookies. REST API v3 suits authenticated server-side work such as orders, refunds and integrations. WPGraphQL with WooGraphQL is an option when the storefront needs flexible queries across content and catalog.

Do my WooCommerce plugins still work in a headless setup?

Back-office plugins (ERP sync, accounting, email, order export) keep working because WooCommerce still runs. Plugins that only change the storefront, such as page builders, sliders and popups, have to be rebuilt or replaced. The audit classifies every plugin before any build work starts.

What happens to checkout and payments?

There are three options: keep the WooCommerce checkout, build a headless checkout on the Store API, or use a provider-hosted payment step. Each has trade-offs in design control, plugin support and testing effort; we check every payment and shipping extension you use before you choose.

Can I keep the Cmsmart Product Designer (NBDesigner) in a headless store?

The product designer runs inside WooCommerce product pages. In a headless storefront it is handled as hybrid or custom development, scoped per project: for example the design step stays on a WooCommerce page, or the storefront opens the designer and returns the design to the WooCommerce cart.

How long does a headless migration take and how is it priced?

It depends on the number of templates, integrations and plugins to replace, so Cmsmart scopes and quotes each project after a discovery call. You receive a written proposal with milestones and an estimate in your Cmsmart dashboard before any work starts.

Is this the same as NextCommerce?

No. NextCommerce is a separate Cmsmart framework. This service keeps the WooCommerce backend you already run and builds a Next.js storefront on top of it.

Project team discussing a storefront plan in a bright office

Plan your move from classic WooCommerce to headless

Tell us about your store, plugins and goals. You get a written proposal with scope and estimate before any work starts, including an honest answer if headless is not worth it for you.

Plan my headless migration See the headless service

Sources

Official documentation and release notes, accessed 5 October 2026. WordPress, WooCommerce, Next.js and other product names are trademarks of their owners.

Top