What Is a Headless Ecommerce Website?
Almost nobody reading this needs one. It is a real architecture solving real problems for a small number of businesses. It is also sold considerably more often than it is required, so this page also gives you a way to tell which situation you are in.
What Headless Means
An ordinary shop platform is one thing doing two jobs. It holds the products, stock, orders and payments. It also produces the pages customers look at. Those two halves arrive joined together and are designed to fit each other. Headless means separating them.
The engine stays where it is, holding everything the business runs on. The shop front is built independently and asks the engine for whatever it needs to show. The head, meaning the customer facing part, has been removed from the body. Hence the name.
A comparison that survives contact with a non technical reader. A conventional platform is a restaurant where the kitchen and the dining room were built together as one building. Headless is keeping the kitchen and constructing the dining room yourself, exactly as you want it, with the option of adding a second dining room, a takeaway hatch and a delivery operation later, all served by the same kitchen.
That analogy carries both halves of the argument. It explains why somebody would want this, since one kitchen serving several rooms is genuinely useful to a business that needs several rooms. It also explains the cost, because you now own two buildings and somebody has to look after both.
Why It Exists
This was not invented to give agencies something expensive to sell. It was built to solve three problems that some businesses genuinely have.
Selling through several places at once. A retailer with a website, a mobile application, screens in physical shops, self service kiosks and marketplace listings needs all of them showing the same products, the same prices and the same stock. Running five separate systems that must agree is a permanent source of expensive disagreement. One engine feeding all five is a considerably better arrangement.
Front end requirements a theme system cannot meet. Configurators where a product is assembled from choices that interact. Purchase journeys that do not resemble browsing and buying. Highly distinctive interfaces where the constraint of working within a theme genuinely prevents the thing being built.
Performance at substantial scale. Where a shop is large enough and busy enough that controlling exactly how pages are delivered becomes worth engineering effort.
Notice what those three share. Each is a specific problem that the architecture removes. Each belongs to a business of a particular size and shape. None of them is a preference, a modernisation or a general improvement, which is the distinction the rest of this page rests on.
What It Gives You
Four genuine advantages, stated properly before the page argues against them for most readers.
Complete freedom over what customers see. Nothing about the interface is constrained by what a theme system was designed to accommodate. If it can be built, it can be built.
One catalogue serving many surfaces. Products, prices and stock maintained once and shown everywhere. For a business selling in several places this is the whole argument and it is a strong one.
Independence from a platform's front end. The shop front is no longer tied to a theme system, its conventions or its release schedule. Changes to the platform's presentation layer stop being your problem.
The two halves can change separately. The customer facing part can be rebuilt without touching the commerce engine. The engine can be replaced without rebuilding the front. For a business expecting either to change, that separation has real value.
Each of those is genuine. The question the rest of the page asks is not whether they are real, since they are. It is whether they are worth what they cost to a business that was never being constrained in the first place.
What It Costs
Four costs, one of which changes daily life permanently and is consistently underestimated.
Building the front end from nothing. There is no theme to configure. Every page type, every state and every behaviour is constructed, which is a substantially larger piece of work than an ordinary build.
Two systems rather than one. Two things to host, monitor, update and pay for, plus the connection between them, which is itself something that can fail.
A smaller pool of people who can work on it. Fewer suppliers, higher rates and more exposure if the relationship ends, since the next supplier has to understand a bespoke arrangement rather than a familiar platform.
Permanent dependence on developers for ordinary changes. This is the one that matters most and the one nobody feels until afterwards. On a conventional shop an owner can add a banner, reorder sections on a page, change a category image or adjust wording themselves, in minutes. On a headless build those are development tasks. Every one of them becomes a request, a queue and an invoice.
Which is the accurate summary of the trade. You have exchanged convenience for freedom. Most shops use their convenience every week and would use their freedom approximately never.
What It Does To Search
On a conventional platform a great deal arrives without anybody asking for it. Pages come out in a form search engines can read. Addresses follow a structure. Sitemaps are produced. Product information is described in markup as a matter of course.
On a headless build none of that is inherited, because the front end is yours. How pages are produced, plus whether their content is actually present at the moment something looks at them, is now a decision somebody has to make deliberately. Address structure is designed rather than given. Markup is implemented rather than included. How filtered pages behave is built rather than configured.
Done properly, there is no disadvantage whatever. Done without anybody holding responsibility for it, a headless shop can end up substantially less visible than the conventional build it replaced, which is a painful outcome given what it cost.
This is the commonest way these projects disappoint. The reason is worth naming precisely. Search performance was assumed to be a property of the platform. On a headless build it is a property of the work, so it only exists if somebody was asked to produce it.
The detail of how that is handled belongs in our technical SEO guides rather than here, since this page is about whether to choose the architecture rather than how to implement it.
Who It Genuinely Suits
Four situations where this is the right answer rather than an expensive preference.
Retailers selling across several surfaces. Website, application, physical shop displays, kiosks and marketplaces, all needing one version of the truth about products and stock. The clearest case by some distance.
Businesses with a front end requirement a platform cannot meet. Not a distinctive design, which themes accommodate perfectly well. A genuine functional requirement, such as a configurator where choices constrain each other, perhaps a purchase process that does not resemble ordinary shopping.
Very large catalogues with substantial traffic. Where controlling exactly how pages are delivered is worth engineering effort because the volumes justify it.
Organisations that already employ developers. If a business has an in house team, the dependency described in block four is not a new cost. It is a use of capacity that already exists, which changes the calculation entirely.
The common thread is that each has a problem the architecture removes. If you cannot name the problem in a sentence, without using the words flexibility, scalability or future proofing, you are probably not in this list.
Who It Does Not
Almost every small and medium shop, which includes almost everybody who will read this page.
If your business sells products through a website, has a catalogue that behaves like a catalogue and is run by a small team with no developers on the payroll, a headless build will cost more, take longer, make routine changes harder and deliver nothing you could point at afterwards.
That is not caution or conservatism. It is the observation that freedom is only valuable to somebody who was being constrained. Most shops were not being constrained. A business that has never once been prevented from doing something by its theme system is not going to benefit from removing the theme system.
There is a version of this decision that does real damage. We see it often enough to name. A growing business commissions a headless build because it feels like the serious choice for a serious company. Two years later the daily experience is worse: small changes need a developer, the supplier who built it has moved on, nobody in the business understands it and the freedom purchased at considerable expense has never been used once.
If you are weighing this, the useful comparison is not headless against conventional. It is what you would do with the difference in cost if you spent it on product photography, category structure and the things in what makes a good ecommerce website.
How To Tell If You Are Being Sold It Unnecessarily
Put these to anybody proposing it. The answers separate a genuine recommendation from an expensive habit.
What specifically can we not do on a conventional build? The answer should be a concrete thing your business needs, described in a sentence. If it is flexibility, scalability, modern architecture or future proofing, no requirement has been identified.
Who makes front end changes after launch, at what cost each time? Establish now what adding a banner or reordering a page involves, because that is your next three years.
Who is responsible for how pages are produced and indexed? Named, then in scope. Block five explains why.
What does this cost over three years against a conventional build? Including maintenance and the development time for routine changes.
What happens if you become unavailable? Who else can work on this, plus what they would need.
What a reasonable justification sounds like. A named requirement, an explanation of how a conventional build would attempt it and why that attempt fails. Somebody proposing this for good reasons will have that answer ready, because it is why they are proposing it. Somebody without it is describing an architecture rather than solving your problem.
We will talk you
out of this.
Unless you can name the specific thing a conventional build cannot do for you, we will recommend the conventional build and spend the difference on structure, product data and the pages that actually sell.
What a build covers:
Ongoing management afterwards sits inside our fixed monthly fee. Build work is quoted per project.
Twenty guides.
One subject.
This page covers an architecture most shops should decline. The rest of the series covers what a build costs, which platform suits which business, where conversion is lost and why the search ceiling is set during the build.
