Headless with Shopware and Shopify: when it pays off and when it doesn’t

Hardly any term in e-commerce is sold as often and explained as rarely as headless. For some it is the future of every serious online store, for others an expensive experiment. Both are true, depending on who you ask. This article shows what headless means technically for Shopware 6 and Shopify, where the real benefits lie, what it costs, where projects fail in practice and how you can make a well-founded decision for your store.

A preliminary note, because this article used to be called “Shopware PWA”: the Shopware PWA based on Vue Storefront was discontinued in 2023. Its successor is Shopware Frontends, also called Composable Frontends. Anyone planning headless with Shopware today plans with it or with their own frontend based on the Store API.

The key points:

• Headless separates the store’s interface from the system behind it. The frontend becomes a separate application that talks to Shopware or Shopify via APIs.

• The gain is freedom: in design, technology and channels. The price is a second software project that has to be built, operated and maintained permanently.

• Most plugins and apps don’t simply work headless. Everything that hooks into the interface has to be replaced or rebuilt.

• Headless doesn’t automatically make a store faster, better on Google or more ready for AI agents.

• For most merchants, a well-built standard frontend is the more economical choice. Headless pays off when there is a clear reason that pays for the second project.

What headless means technically

A classic store is one piece of software that does both jobs: it manages products, prices, customers and orders, and it builds the pages the customer sees from them. In Shopware 6, the storefront with its Twig templates handles this second task; in Shopify, the Liquid theme does. Both run on the same platform, and extensions can intervene in both places.

With headless, this head is cut off. Shopware or Shopify remain responsible for catalogue, cart, customers, prices and orders. The interface is a separate application, usually based on a modern JavaScript framework, that fetches its data via APIs and builds the pages itself. It runs on its own infrastructure, with its own deployment and its own life cycle.

Two things follow from this that decision-makers often underestimate. First, there are two systems instead of one afterwards, with all the consequences for operations, updates and troubleshooting. Second, the frontend loses everything the platform previously provided by itself. Whatever was simply there in the standard theme, from basic search engine features to the cookie banner, has to be built deliberately in the new frontend.

Headless with Shopware 6

Shopware 6 was built with APIs from the start and is technically well suited to headless. The basis is the Store API. It delivers products, categories, search and filters, cart, checkout and customer account as structured data. There is also the Admin API for management, integrations and automation.

For the frontend, Shopware offers Shopware Frontends. This isn’t a finished theme, but a toolkit: packages for connecting to the Store API, typed interfaces, ready-made building blocks for routing, search and filters, price display and login, and integration of Shopping Experiences, the content pages from the Shopware admin. A template based on Vue and Nuxt builds on this. If you prefer React, you can also build the frontend with Next.js, because the Store API isn’t tied to any framework. Since Shopware 6.7, many Store API responses can also be cached, which is an important building block for fast headless stores.

A major advantage with Shopware: the backend remains fully intact. Shopping Experiences, rules, prices, promotions, B2B features and sales channels continue to be managed in the familiar admin. Shopware even offers its own sales channel type for headless. And the merchant keeps full control over checkout, because it also runs via the Store API.

Headless with Shopify

At Shopify, the counterpart is called Hydrogen. Hydrogen is a framework based on React Router that is prepared for the Shopify APIs. By default it is hosted on Oxygen, Shopify’s hosting platform, which is included in paid plans. Alternatively, a headless frontend can be run differently, for example with Next.js on your own infrastructure.

The data comes from the Storefront API and the Customer Account API. The most important difference from Shopware: checkout stays at Shopify. A headless cart returns a checkout URL, and the customer switches to Shopify checkout to buy. It can be customised according to the same rules as with a regular theme, i.e. with the options of the respective plan.

There is one point Shopify merchants should know before deciding: the APIs appear in new versions every quarter, and Hydrogen follows this rhythm too. A headless frontend on Shopify is therefore never finished; it has to be brought up to new versions regularly. At the same time, the merchant loses the theme editor that marketing previously used to adjust content themselves. This freedom has to be recreated via a CMS or via metaobjects.

The direct comparison

The problem with plugins and apps

This is where most headless calculations fail in practice. A typical store has dozens of extensions. A large share of them work exactly where headless starts: in the interface.

In Shopware, many plugins bring their own Twig templates, their own JavaScript and their own storefront logic. Review widgets, product configurators, cross-selling sliders, wishlists, voucher features, live search, chat or payment methods with their own flow in checkout: everything that becomes visible in the storefront doesn’t initially exist in a headless frontend. Plugins that only work in the backend, such as interfaces to the ERP system, keep working. Plugins that also provide their data via the Store API can be connected, but still have to be displayed anew in the frontend.

At Shopify it is similar. Most apps hook into the store via theme extensions, i.e. app blocks and app embeds in the Liquid theme. On a headless frontend, they aren’t displayed. You need apps that explicitly support custom frontends, or your own integration via their APIs. Checkout is the exception at Shopify: because checkout stays at Shopify, checkout extensions keep working.

The practical advice is therefore simple and still almost always skipped: before any headless decision, a complete list of all plugins and apps belongs on the table, with three columns. Keeps working. Needs to be connected. Needs to be replaced or rebuilt. Only this list turns an estimate into a calculation.

What is often overlooked

• Basic search engine features: page titles, meta descriptions, canonicals, hreflang, redirects, structured data and sitemap come with the standard theme. In a headless frontend, all of this has to be built. If any of it is missing at launch, the store loses rankings that have grown over years. Server-side rendering is also essential, so that Googlebot receives complete pages and doesn’t have to execute JavaScript first.

• Tracking and consent: consent banner, analytics, advertising pixels and conversion tracking have to be set up completely anew in the new frontend. A good moment to switch to server-side tracking straight away.

• Payment methods: many payment providers work with redirects, embedded forms or their own logic in checkout. With Shopware, every payment method has to be checked in the headless checkout and often adapted.

• Preview and editing: editors want to see what a page looks like before it goes live. A reliable preview in a headless frontend is work in its own right.

• Troubleshooting: is a problem in the frontend, the API, the cache or Shopware or Shopify? With two systems, the search takes longer, and you need people who understand both sides.

Myths about headless

“Headless is automatically faster.” Not necessarily. A headless frontend can load very quickly, especially with good caching. But it can even perform worse on responsiveness to clicks, because modern frameworks execute a lot of JavaScript in the browser before the page responds. How to measure and improve responsiveness is shown in the article on INP. A lean standard theme beats a poorly built headless frontend every time.

“Headless is better for SEO.” What counts for Google is what arrives: complete content, clean technology, a good user experience. A headless frontend can deliver this just as well as a standard theme, but it doesn’t deliver it by itself. More on the fundamentals under Shopware SEO and Shopify SEO.

“With headless, we’re ready for AI agents.” AI agents don’t shop via the interface, but via data and APIs. Whether a store is ready for agents is decided by product data and protocols such as UCP, and these depend on the backend. Shopware offers the connection via the Agentic Commerce extension for headless sales channels too, and Shopify serves products to AI assistants regardless of the frontend. More on this in the article on UCP and agentic commerce.

“Headless is future-proof.” It is more flexible, but not automatically future-proof. Frameworks age faster than store systems. The history of this article itself shows it: the Shopware PWA it was once written about no longer exists.

What headless costs

The costs of a headless project have three parts. The first is the build: the frontend is developed from scratch, including all the features the standard theme would have brought and all the extensions that need to be reconnected or built. In our experience, this effort is a multiple of a good theme project.

The second part is operations: hosting, monitoring, caching and deployment for an additional system. At Shopify, hosting on Oxygen is included in paid plans, but the operational work isn’t.

The third and most frequently underestimated part is ongoing maintenance. Framework updates, API versions, security updates and every new feature that in future no longer comes as a plugin or app but has to be developed. Anyone planning headless is planning a permanent development budget, not a one-off project.

When headless pays off

Headless is the right choice if at least one of these reasons applies and the benefit carries the ongoing costs:

• Several channels from one backend: web store, app, in-store terminal, marketplace frontends or customer portals are to use the same data.

• A shopping experience a theme can’t deliver: complex configurators, strongly content-driven brand worlds or features that can only be implemented with templates at great effort.

• An existing system landscape: an existing headless CMS, your own search or a design system used across several brands and countries.

• Your own frontend team: if you have Vue or React developers in-house or commission them permanently, you can carry the maintenance.

When it doesn’t

• If the main motive is speed: a lean, well-built theme is the cheaper route to good values.

• If the store relies heavily on plugins or apps: every extension in the interface becomes a project of its own.

• If marketing is to manage content itself and there is no CMS concept.

• If the budget covers the launch, but not the years after.

In between, there is a route that is often overlooked: the hybrid approach. The main store runs on the standard frontend, while individual channels or areas, such as an app, a B2B customer portal or a brand world, are built headless. This creates flexibility where it is needed without rebuilding the whole store.

A decision in five questions

1. What concrete benefit should headless bring that the standard frontend can’t deliver?

2. Which plugins or apps do you use, and how many of them work in the interface?

3. Who maintains the frontend in three years, and with what budget?

4. How is content managed when the theme editor or storefront goes away?

5. How do you secure rankings, tracking and payment methods during the switch?

If all five questions can be answered convincingly, headless is a strong option. If one of them remains open, it is almost always the reason projects end up costing more than planned.

Headless or standard: deciding with arboro

arboro has been developing Shopware and Shopify stores for many years, with classic frontends as well as headless architectures. Before anything is built, we check with you whether headless makes economic sense for your store: with an inventory of all plugins and apps, an honest cost estimate over several years and a plan for SEO, tracking and payment methods. Sometimes the result is a headless project, often a better standard frontend. Both are good answers if they fit your business. More on this under Shopware and Shopify development.