HEADLESS · ARCHITECTURE · 17 SEPTEMBER 2026 · 6 MIN READ
Do you actually need headless Shopify?
Most stores asking the question have a theme problem or an app problem. Both are cheaper to fix, and both are reversible.
Probably not. Headless earns its cost when the front end is genuinely the constraint — a configurator the theme cannot express, one front end shared across web and a native app, or content composed from several systems. If the complaint is page speed, an unmaintainable theme, or marketing waiting a week for a landing page, each of those has a direct fix that costs a fraction as much and can be undone.
IN SHORT
- Headless means Shopify keeps catalogue, cart, checkout and orders while a front end you own renders the pages.
- The three most common reasons given for going headless — speed, theme debt, slow publishing — all have cheaper direct fixes.
- The real cost is not the build. It is owning a codebase, losing the theme editor, and replacing every app that injects a script.
- Checkout should stay on Shopify regardless: it carries PCI scope and converts better than a custom equivalent.
- A partially headless site — some routes headless, the rest on Liquid — is a legitimate destination, not a failed migration.
The three reasons people give, and what each one actually needs
Almost every headless conversation opens with one of three complaints. It is worth being honest about which one you have, because none of the three is solved by replacing the rendering layer.
“Our store is slow.” Page speed on Shopify is usually decided by apps and images, not by Liquid. A store carrying eleven script-injecting apps will be slow headless too, because those scripts either follow you or get replaced by equivalent JavaScript in the new front end. Measure what is actually costing you: a speed programme that removes four apps and fixes image delivery will beat a rebuild, and you will know within weeks rather than months.
“Nobody can touch our theme.” This is theme debt, and it is real — four agencies over six years leaves a codebase where every change risks something unrelated. But a headless rebuild is not the only way out. A clean theme rebuild costs a fraction as much, keeps the app ecosystem, and does not require your team to learn React.
“Marketing waits a week for a landing page.” That is a tooling problem, and going headless makes it worse before it makes it better, because you lose the theme editor on day one. A section library — composable blocks merchandisers arrange themselves — fixes this directly and is the cheapest of the three.
When headless genuinely is the answer
There are real cases, and they share a shape: the constraint is the front end itself, not something running inside it.
- One front end shared across a web storefront and a native app. Liquid renders web pages only. This is the strongest case there is.
- A configurator or tool that has outgrown a product page — multi-step state, live pricing, and a UI that no longer fits inside a theme section.
- Content composed from several systems at render time, where metafields have stopped being enough.
- A storefront that is one surface inside a larger application, such as a portal or marketplace, where Shopify is the commerce layer rather than the site.
The costs nobody itemises
Build cost is the number everyone asks about and the smallest one that matters. The three that decide whether the project is a success are rarely on the quote.
The theme editor goes away. Whatever your merchandisers use it for now has to exist somewhere else, which means a headless CMS, a content model, and a migration of everyone’s habits. Skip this and the site launches and marketing quietly stops shipping.
Script-injected apps stop working. Reviews, popups, personalisation and most analytics tools work by adding a script tag to your theme. After cutover there is no theme to add it to. Each one needs an API-based replacement, a custom integration, or a decision to live without it — and occasionally the replacements cost more than the migration.
You own a codebase now. Indefinitely. It needs dependency updates, security patches and people who understand it. The pool of developers who can pick up your Liquid theme is every Shopify agency. The pool who can pick up your bespoke front end is whoever wrote it.
What we would ask you first
Before scoping anything, five questions. If the answers are uncomfortable, that is the useful outcome.
- Which specific thing can you not build today? Name the page, not the category.
- Which apps inject a script into your theme, and what replaces each one?
- Who publishes a landing page on the Tuesday after launch, and in which tool?
- What is the performance budget, in numbers, and who can block a release for breaking it?
- Who maintains the front end in year two, and do they work here yet?
The honest position
We build headless storefronts and we would rather you did not need one. The interfaces clients usually reach for headless to build — a multi-step bundle builder, a date-driven personalisation tool, a delivery-capacity engine that decides what a customer can pick at checkout — we have shipped inside Shopify, on Liquid, without a rebuild. Knowing when something fits is worth more than knowing how to replace everything.
If after all that the front end really is your constraint, go headless deliberately: migrate one route, measure it against the baseline, and only then move the next. A project you can stop is a project you can afford to start.
Questions this raises
Is headless Shopify faster than a theme?
Not automatically. Plenty of headless builds are slower than the theme they replaced, because removing theme and app scripts only helps if the JavaScript bundle that replaces them is smaller. Speed comes from a performance budget somebody enforces, not from the architecture.
Does headless improve SEO?
No, and it puts it at risk. Canonicals, product structured data and pagination signals came free with Liquid and must be rebuilt by hand in the new front end. Done deliberately, rankings hold because URLs and content have not changed. Done carelessly, they do not.
How much does headless Shopify cost?
The build is the smallest line. Budget for a CMS, replacements for every script-injected app, and a team that can maintain a front-end codebase indefinitely. If those three are not funded, the build being on time will not save the project.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.