What headless means, in plain terms
A traditional ecommerce platform is one product: it stores your catalogue and orders, and it also produces the web pages customers see, through a theme. Headless splits these apart. The platform remains as the engine, handling products, prices, baskets, checkout and orders, and it exposes them through interfaces. The pages are built separately, as a website or app of your own that asks the engine for what it needs.
The benefit is freedom. The storefront can look and behave exactly as you wish, load very quickly, and be joined by other front ends, such as an app or in-store screens, all using the same engine. The cost is that everything the theme gave you for nothing now has to be built, hosted and maintained. Our comparison of headless and traditional ecommerce weighs the two approaches.
Decide whether headless pays for you
Good reasons
- The shopping experience is a competitive advantage that themes cannot deliver
- Content and commerce must be woven together, as in editorial-led brands
- Several storefronts, regions or channels share one catalogue
- Measured speed problems that theme optimization has not solved
- A development team is, or will be, permanently available
Poor reasons
- It is described as the modern way
- A dislike of the current theme's look
- An agency recommends it for every client
- The hope of lower running costs
- No developers after launch
Be honest about scale. For many stores, a well-built theme on a hosted platform is faster to launch, cheaper to run and easier to change without developers. Headless suits businesses for which the storefront is a product in its own right.
The parts you will choose
| Part | What it does | Planning question |
|---|---|---|
| Commerce engine | Catalogue, prices, baskets, checkout, orders, customers | Stay on your current platform as the engine, or change? Staying halves the project |
| Storefront | The pages and their code | Which framework, and who will maintain it for years? |
| Content system | Editorial pages, landing pages, banners, navigation | Can marketing build pages and preview them unaided? |
| Search and listing | Product search, filters, sorting, recommendations | The engine's own, or a dedicated search service? |
| Payments and checkout | Taking the money | The engine's hosted checkout, or your own? |
| Hosting and delivery | Serving pages worldwide, quickly | Who monitors it and answers at night in peak season? |
| Integration layer | Joins the parts and your ERP, tax, email and analytics tools | What replaces the plug-in apps you rely on today? |
Many apps and extensions for hosted platforms work by inserting themselves into the theme. With a headless storefront they often stop working, and each must be replaced through an interface or rebuilt. List every app you use and check each one before committing.
Make the checkout decision early
The checkout is the most sensitive part of any store: it handles payment details, taxes, fraud controls and regulation, and every fault costs orders. A headless project can treat it in two ways.
| Option | How it works | Consider |
|---|---|---|
| Keep the engine's hosted checkout | Customers move from your storefront to the platform's checkout to pay | Proven, secure and maintained for you. Styling and structure are limited, and the handover between the two must be smooth |
| Build your own checkout | Your storefront collects details and calls the engine and payment provider through interfaces | Full control. You carry the security obligations, payment methods, tax logic and testing, permanently |
Most projects should begin with the hosted checkout. It removes the largest risk and lets the team concentrate on the pages where design freedom actually sells. A custom checkout can follow if evidence shows the hosted one costs orders. If you do build your own, involve your payment provider early about card data security requirements.
Make sure editors can still work
The complaint heard most often after a headless launch comes from marketing: we used to change the home page ourselves, and now we need a developer. It is avoidable, and only if editing is designed as carefully as the storefront.
- 01
List what editors change today
Home page, banners, landing pages, navigation, promotions, product content, announcements. Each needs a home in the new setup.
- 02
Give them building blocks
A library of page sections that editors can arrange, fill and reorder in the content system, without code.
- 03
Require preview
Editors must see a page as customers will, before publishing. This needs deliberate work in a headless build.
- 04
Keep scheduling and roles
Timed publishing for campaigns, drafts, approvals and a history of changes.
- 05
Connect content to products
Editors should be able to pick products and collections from the catalogue inside the content tool, with live prices and stock.
- 06
Test with the editors
Before launch, have the marketing team build a real campaign page alone. What they cannot do is a defect.
A worked example
A fashion brand goes headless in stages
This example is invented to show a cautious route. A fashion brand sells in four countries from one hosted store and wants editorial content and shopping on the same pages.
- ReasonsLookbook pages with shoppable products, per-country storefronts sharing one catalogue, and product pages that are slow on phones despite theme work. The brand has two developers on staff.
- PartsThe current platform stays as the engine. A new storefront is built with a content system that has a block library and preview. Search remains the platform's own for now.
- CheckoutThe platform's hosted checkout is kept. The basket lives in the new storefront, and the handover to checkout is styled to match.
- AppsOf 19 installed apps, 8 work through interfaces unchanged, 6 are replaced and 5 are dropped. Reviews and the size guide need rebuilding.
- StagesThe home page and lookbooks launch first on the new storefront, with product pages still served by the old theme. Product and listing pages follow two months later.
Launching in stages meant the riskiest pages moved last, after the team had learned the new setup. Marketing built the first lookbook without a developer, which had been written into the acceptance criteria.
Performance and search visibility
Speed is a common reason for going headless, and it is not automatic. A storefront that builds its pages in the visitor's browser can be slower to show content than a good theme, and harder for search engines to read. Ask for pages to be prepared on the server or in advance, so that content arrives complete, and set measurable targets for loading on a mid-range phone.
Everything a theme did for search must be rebuilt on purpose: page titles and descriptions, structured product data, canonical addresses, the sitemap, redirects from old addresses, and sensible handling of filtered listing pages. Put each of these in the requirements. Where the storefront is replacing an existing one, our guide on migrating a website without losing important URLs applies in full.
Team and cost of ownership
- 01
Who maintains the storefront?
What to budget forAn in-house team or a retained partner, for as long as the store runs. Frameworks need updates, and the business will want changes weekly.
- 02
What do the parts cost each month?
What to budget forEngine plan, content system, search service, hosting, monitoring. Add them up at expected traffic, and at peak.
- 03
Who is on call?
What to budget forWith several services involved, someone must diagnose which one failed during a sale.
- 04
How are changes released?
What to budget forAutomated tests and a release process, so that frequent changes do not break buying.
- 05
What does a new feature cost?
What to budget forThings that were an app install now need development. Compare the yearly total with your current setup honestly.
- 06
What is the exit?
What to budget forBecause the parts are separate, each can be replaced. Keep content and product data portable to preserve that benefit.
Headless planning checklist
Headless ecommerce planning checklist
0 of 11 checkedWhat to do next
Write down the three things you cannot do with your current store that customers would notice. If a theme developer could deliver them, you do not need headless yet. If they could not, list your installed apps and what marketing edits each week, which are the two inventories every headless plan depends on.
Our headless ecommerce development page explains how we build and stage these projects. Tell us what your store cannot do today and we will say plainly whether headless is the answer.
Common questions
Is headless ecommerce faster?
It can be, because the storefront is built for speed without a theme's constraints. It is not faster by default. A storefront that assembles pages in the browser, or loads many third-party scripts, can be slower than a well-tuned theme. Require pages prepared on the server, set measurable targets and test on ordinary phones before judging.
Can we go headless and keep our current platform?
Often, yes. Many hosted platforms can act as the engine behind a separate storefront, depending on plan. Keeping the platform means products, orders, customers and integrations stay where they are, which removes a large share of the risk. Check which interfaces your plan includes and any limits on their use.
Does headless cost more to run?
Usually. You pay for several services in place of one, and you need developers for changes that used to be settings or app installs. In return you gain control and the ability to replace parts independently. Add up a full year of platform fees, services, hosting and development time for both approaches before deciding.
Will our marketing team be able to edit pages?
Only if that is designed in. A headless build needs a content system with a library of page sections, preview and scheduling, so that editors can create and change pages without code. Make it an acceptance test: before launch, the marketing team builds a real campaign page unaided.
Should we build our own checkout?
Not at first, in most cases. The platform's hosted checkout is secure, maintained and proven, and it removes the hardest part of the project. Build a custom checkout only when there is evidence that the hosted one is costing orders or cannot support a requirement, and with a clear understanding of the security and maintenance duties that come with it.