What is headless commerce? How it works, pros, cons and pitfalls
Headless commerce is an architecture in which the customer-facing storefront (the "head") is built separately from the commerce back end that manages products, prices, carts, orders and payments, and the two communicate only through APIs.
How it works
In a traditional, or coupled, platform the same system stores the catalog and renders the pages from its own themes. In a headless setup:
- The back end exposes commerce functions through an API. Shopify's GraphQL Storefront API, for example, lets developers build experiences "on any platform, including the web, apps, and games," where customers can view products and collections, add products to a cart and check out.
- The front end is a separate application, often built with a JavaScript framework, that calls those APIs and renders the pages.
- The same back end can feed several heads at once: a website, a mobile app, a kiosk or a marketplace integration.
Illustration (hypothetical): a brand runs its catalog and checkout on one commerce platform, its editorial pages in a separate content system, and a custom web front end that pulls from both. A product price changed in the back end appears on the website and in the app without either front end being redeployed.
Why teams choose it
- Front-end freedom. Designers and developers are not limited to a platform's theme system.
- Multiple channels. One set of products, prices and inventory serves every touchpoint.
- Independent releases. The front end can change without touching order processing.
Trade-offs and common mistakes
- You own more of the stack. Hosting, caching, previews, search, redirects and many features a theme provides out of the box become your team's work.
- Client-side rendering and SEO. Google processes JavaScript sites in three phases (crawling, rendering and indexing) and notes that server-side or pre-rendering "is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript."
- Page speed is not automatic. A heavy JavaScript bundle can hurt Core Web Vitals. Google's web.dev guidance encourages developers to consider server-side rendering or static rendering over a full rehydration approach.
- Losing structured data. Product, price and review markup has to be rebuilt in the new front end; see structured data.
- Choosing it for the label. If one website is your only channel and a theme already meets your design needs, a coupled setup is usually simpler to run.
Headless vs composable
The terms overlap. Headless describes the split between front end and back end; composable architectures go further and assemble the back end itself from separate services such as search, content and payments.