If you run an online store, someone has probably told you to "go headless". It usually comes with a promise of a faster site and total design freedom, and without much detail about what you take on in exchange. Headless commerce is a legitimate architecture that suits some merchants very well. It is also a larger engineering commitment than the pitch suggests, and plenty of stores are better off without it.

This article explains what it is, what a headless store is made of, what the main platforms offer according to their own documentation, and how to decide whether it fits your business.

Quick answer

Headless commerce means the part of your store that customers see (the storefront) is built and hosted separately from the system that manages products, prices, carts and orders (the commerce backend). The two talk to each other through APIs.

• What you gain: full control over design and user experience, one backend serving several channels (website, mobile app, kiosk, marketplace feeds), and the chance of very good performance if the storefront is engineered well.
• What it costs: you now own a software product. There are more moving parts, more vendors, more integration work, and you need developers on an ongoing basis, not only at launch.
• Who needs it: merchants whose growth is blocked by what a theme can do, who sell through several channels from one catalog, or whose content and commerce need to be combined in ways a theme cannot handle.
• Who does not: a store with a standard catalog and a standard buying journey, a small team, and no in-house or contracted developers. A well-built theme on a traditional platform is usually the better business decision.

Traditional, headless and composable commerce in plain terms

These three terms describe how tightly the pieces of your store are tied together.

Traditional (monolithic) commerce

One platform does everything. The same system stores your products, runs the checkout and renders the pages customers see, usually through a theme. A standard Shopify theme store, a WooCommerce site running a WordPress theme, and a Magento store using its built-in frontend are all examples. You install a theme, add apps or plugins, and the platform keeps the parts working together.

Headless commerce

The "head" is the storefront. In a headless setup you remove the platform's built-in storefront and build your own, usually as a web application in a JavaScript framework. The platform still manages catalog, pricing, cart, checkout and orders, and your storefront requests that data through the platform's APIs. Only the presentation layer has been separated.

Composable commerce

Composable goes a step further. Instead of one commerce platform behind your custom storefront, you assemble the backend itself from separate specialist services: one for the catalog and cart, another for search, another for content, another for promotions, and so on. The MACH Alliance, an industry body that promotes this approach, describes a composable architecture as modular, with each capability an independently deployable unit. Every composable store is headless, but a headless store is not necessarily composable.

How a headless store is put together

A traditional store is one product. A headless store is a small system of products that you connect. The usual parts are:

• Commerce backend. The system of record for products, prices, inventory, customers, carts and orders. This is Shopify, BigCommerce, Adobe Commerce, WooCommerce, commercetools or similar.
• APIs. The storefront never touches the database directly. It sends requests such as "give me this product" or "add this item to the cart" to the backend's storefront API, often using GraphQL, a query language that lets the frontend ask for exactly the fields it needs.
• Storefront framework. The custom frontend, commonly built with React and a framework such as Next.js or React Router. It renders pages, handles navigation and manages the cart interface.
• Storefront hosting. Your frontend needs somewhere to run. On a traditional platform this is included and invisible. Headless makes it a separate decision, with its own deployment process, monitoring and bill.
• Content management system (CMS). Landing pages, editorial content, banners and navigation need a home that marketers can edit. In a themed store the theme editor does this. In a headless store you typically add a headless CMS and build the page components it controls.
• Search and merchandising. Product search, filtering and recommendations may come from the commerce platform or from a dedicated search service, which then needs to be kept in sync with the catalog.
• Payments and checkout. Often the checkout stays with the commerce platform even when everything else is custom, because that is where payment security and compliance obligations concentrate. A fully custom checkout is possible on some platforms and is the most demanding part to build and maintain.
• Everything a theme used to give you. Analytics tags, cookie consent, reviews, email capture, accessibility, SEO metadata, redirects and sitemaps all have to be implemented deliberately in the new frontend.

The last point is where many budgets go wrong. Apps and plugins that work by adding code to a theme generally cannot do that in a custom storefront. Each one has to be checked for an API you can integrate, replaced, or rebuilt.

The real benefits

Design and experience freedom

A theme system limits what a page can be. A custom storefront does not. Product configurators, guided selling quizzes, content-heavy product pages, unusual navigation and custom account areas become ordinary frontend work instead of fights with a template.

One backend, several channels

Because the backend is reached through APIs, the same catalog, pricing and order logic can serve a website, a mobile app, an in-store kiosk or a partner portal. If a mobile app is part of your plan, the choice of app technology is a separate decision, covered in our comparison of native, Flutter and React Native.

Performance, when done well

A custom frontend lets developers control exactly what loads, when, and from where. That can produce strong results on Google's Core Web Vitals, which measure loading performance, interactivity and visual stability. The qualifier matters. Headless does not make a site fast by itself. A carelessly built JavaScript storefront can be slower than a lean theme, and a well-optimized theme can perform very well. Headless gives you control over performance, and control only pays off with skilled engineering.

The real costs

More moving parts

Each component has its own account, configuration, release cycle and failure modes. When a product page shows the wrong price, the cause could be the commerce backend, a cache, the CMS, the search index or the frontend code. Diagnosing problems takes people who understand the whole system.

More engineering, permanently

A headless storefront is custom software. It needs developers to build it and then to maintain it: framework upgrades, security patches, API version changes and new features. Changes a marketer could once make in a theme editor may now need a developer unless the CMS integration was designed to allow them. The cost drivers are the number of page types, the number of integrations, how custom the checkout is, and how much editing freedom the marketing team needs.

More vendors and contracts

Commerce platform, frontend hosting, CMS, search and possibly others each come with pricing, support terms and their own roadmap. No single vendor is responsible when the combination misbehaves.

Lost conveniences

Theme editors, live previews, one-click apps and built-in SEO features either disappear or must be rebuilt. For a store selling in both the US and the UK, items a platform theme often handles for you, such as currency display, showing prices with or without tax to match local shopper expectations, and consent banners, become your team's responsibility in the storefront. Requirements differ by country, so confirm them with a qualified adviser. This article is not legal advice.

What the major platforms actually offer

The statements below are taken from each vendor's own documentation, checked in October 2026. Features and plan terms change, so confirm them before you commit.

Shopify

Shopify describes Hydrogen and Oxygen as its recommended stack for headless commerce. Hydrogen is a set of components and utilities built on the open-source React Router framework, and Oxygen is Shopify's hosting platform for Hydrogen storefronts. The same page states that Oxygen is available at no extra charge on paid Shopify plans, and lists them. You are not required to use either: Shopify's headless documentation says you can build with any language and framework and host anywhere.

Custom storefronts read data through the Storefront API, which Shopify states is available only in GraphQL. When a cart is created through this API, it includes a checkout URL that sends the buyer to Shopify's checkout. In practice, this means a typical Shopify headless build customizes browsing and cart, and hands the payment step back to Shopify.

BigCommerce

BigCommerce provides Catalyst, which its documentation calls a composable, fully customizable headless storefront framework, built with Next.js, React storefront components and the BigCommerce GraphQL Storefront API. Its headless documentation explains that BigCommerce still creates the order and processes payments, while you build and run the storefront and any custom logic.

Adobe Commerce and Magento Open Source

Adobe's GraphQL documentation presents its GraphQL APIs as the foundation for headless storefronts and mobile applications. For the frontend, Adobe documents two routes: the Adobe Commerce Storefront, built on Edge Delivery Services with Commerce drop-in components, and PWA Studio, a set of tools for building a Progressive Web Application storefront on Adobe Commerce or Magento Open Source. Which route suits you depends on your edition and hosting, so this is a question to settle early with whoever handles your Magento development.

WooCommerce

WooCommerce documents a Store API that provides public REST endpoints for customer-facing cart, checkout and product functionality, and that does not require API keys. That makes a custom frontend on WooCommerce technically possible. Be aware that many WooCommerce extensions assume a WordPress theme is rendering the page, so each one you rely on has to be checked individually.

commercetools

commercetools sits at the composable end. Its API documentation describes HTTP and GraphQL access to its commerce resources. An API-only model like this suits organizations with an engineering team, not a merchant looking for a quick launch.

Who actually needs headless: a decision table

A useful test: write down the specific things you cannot do today. If the list is "the site feels dated" or "a competitor went headless", that is a redesign brief, not an architecture brief. If the list contains specific blocked requirements with revenue attached, headless deserves a proper evaluation.

A staged route from a traditional platform

Moving to headless does not have to be a single large project. A staged approach reduces risk and lets you stop at any stage that already solves the problem.

1. Fix what the current setup allows. Audit apps and plugins, remove unused ones, optimize images and scripts, and measure Core Web Vitals before and after. Many performance complaints end here.
2. Document the blockers. List the requirements the theme cannot meet, and estimate what each is worth. This becomes the business case and the scope.
3. Inventory your dependencies. For every app, plugin and tracking script, record whether it offers an API, needs replacing, or can be dropped. This list drives a large share of the cost.
4. Keep the backend, replace the head. Stay on your existing commerce platform and use its storefront API. Keep the platform's checkout if you can. This avoids migrating products, customers and orders at the same time as rebuilding the frontend.
5. Protect search rankings. Preserve URLs where possible, map redirects, and carry over metadata and structured data. Test with real crawling tools before launch.
6. Consider composable only when a specific backend limit appears. Replace search, content or promotions one service at a time, each for a stated reason.

Illustrative scenario, not a client case study: a furniture retailer on a themed store wants a room-based product configurator and a mobile app. Cleaning up the theme improves speed but does not deliver the configurator. The team keeps its commerce platform and checkout, builds a custom storefront for the catalog and configurator, and later points the mobile app at the same APIs. It never needs to go composable, because no backend limit appears.

For technical readers

• Rendering strategy. Decide per route between server rendering, static generation with revalidation, and client rendering. Product and category pages need server-rendered HTML for crawlers and fast first paint. Cart and account are per-user and should not be cached publicly.
• Caching and invalidation. Price and stock changes must reach the storefront promptly. Plan webhook-driven cache invalidation instead of relying only on time-based expiry.
• Checkout boundary. Handing off to the platform checkout keeps card data out of your application. A custom checkout increases your payment security scope, so involve your payment provider early.
• Preview and editing. Marketers need draft previews. Build the CMS preview path as a first-class feature, not an afterthought.
• Secrets and observability. Keep privileged API tokens server-side, and set up centralized logging, error tracking and real-user performance monitoring from day one.

Frequently asked questions

Is headless commerce bad for SEO?

It does not have to be, but it moves SEO responsibility to your team. Server-rendered pages, metadata, structured data, sitemaps, canonical tags and redirects all need to be implemented and tested in the custom storefront, where a traditional platform supplies many of them by default.

Can I go headless without changing my commerce platform?

Often, yes. Shopify, BigCommerce, Adobe Commerce and WooCommerce all document APIs that a custom storefront can use, as described above. Keeping the backend and replacing only the storefront is usually the lowest-risk way to start.

Does headless commerce cost more?

In most cases it costs more to build and to run than a themed store, because you are funding custom software, extra services and ongoing development. The main cost drivers are the number of page types and integrations, how custom the checkout is, and how much editing control non-technical staff need. Whether it pays back depends on the value of what it unblocks.

Do I need a headless CMS as well?

Usually. Once the theme editor is gone, marketers need another way to manage pages, banners and navigation. A small store with little editorial content can sometimes manage with content fields in the commerce platform, but most headless builds add a CMS.

Conclusion

Headless commerce trades convenience for control. You get freedom over design, channels and performance, and in return you take ownership of a custom storefront and the integrations around it. It is the right choice when you can name specific requirements your current platform blocks and you have, or can contract, steady engineering capacity. It is the wrong choice when the real problem is a dated design or a cluttered theme.

A sensible next step is to write the list of blocked requirements and the inventory of current apps and plugins described in the staged route. Those two documents will tell you most of what you need to know. If you would like a second opinion on them, Entrant Technologies builds ecommerce websites and apps on both traditional and custom architectures, and you can request a quote with your requirements attached.