Shopify vs WooCommerce vs headless: choosing by constraint, not hype

The question behind the question

Almost nobody actually wants to know which ecommerce platform is best. What they want to know is whether the decision in front of them is reversible, what it will cost to live with, and which of the three vendors in the room is telling them the least self-serving version of the truth.

So it is worth being explicit about what you are choosing between, because the three options are not three points on a single scale of sophistication. They are three different answers to one question: where do you want your engineering effort to go?

Shopify says: give us the boring parts — hosting, uptime, patching, payment compliance, the checkout — and accept our opinions about how a store works. WooCommerce says: here is a store that lives inside your website, and you can change anything, including things you should not; the cost is that you now run a piece of software. Headless says: we will separate the storefront from the commerce engine so you can build any front end you like, and you will pay for that freedom in permanent engineering ownership.

None of those is wrong. Each is wrong for someone. The useful work is figuring out which someone you are, and the fastest route to that is to stop comparing features and start comparing constraints — what your team can maintain, what your merchandisers need to change without a developer, and what your payments and tax setup will actually tolerate.

What the three options actually are

The terminology has been muddied by marketing on all sides, so a short and slightly pedantic clarification earns its space.

Shopify: a hosted platform with a theme layer

Shopify runs the whole stack. You get a catalogue, cart, checkout, payments, admin and a themed storefront, and the checkout in particular is Shopify’s rather than yours. Customisation happens through themes, through apps, and — since the retirement of the old checkout template approach for most merchants — through checkout extensibility, where UI extensions, Functions and payment extensions plug into defined points rather than letting you rewrite the page.

That constraint is the product. You cannot break checkout, which also means you cannot fix it in ways Shopify has not anticipated.

WooCommerce: commerce as a WordPress plugin

WooCommerce is software you install on hosting you arrange, inside a WordPress site you already run. Products are a post type. Extensions are plugins. The store inherits WordPress’s content model, its editorial workflow, its plugin ecosystem and its maintenance burden in equal measure.

It exposes a public Store API for cart, checkout and product functionality, which is unauthenticated by design and deliberately scoped: it will not return other customers’ orders and it will not write store settings. That is sensible design, and also a useful reminder that “open source, so we can do anything” has boundaries in practice.

Headless: a decoupled storefront on a commerce engine

Headless means the front end is a separate application talking to a commerce back end over an API. On Shopify, that back end is reached through the Storefront API, a GraphQL interface with its own token model and a quarterly release cadence you have to keep pace with. You can build on Shopify’s own Hydrogen framework with Oxygen hosting, or bring an entirely separate stack.

Composable commerce and MACH architecture extend the same idea further: search, content, promotions and sometimes checkout become separate services you assemble. That buys real flexibility and introduces a genuinely new job — integration ownership — which somebody holds for as long as the system exists.

Total cost of ownership, compared honestly

The comparison most vendors publish is a licence fee comparison, because licence fees are the one number that is easy to look up and the one that flatters open source. Here is the fuller shape, without figures, because any figure quoted before your scope is known is a guess.

Cost line	Shopify	WooCommerce	Headless
Platform or licence	Recurring, predictable, tiered	None for core; per-extension for most useful features	Commerce engine fee plus each composed service
Hosting	Included	Yours to specify, scale and pay for	Yours, plus edge and CDN for the storefront
Security patching	Vendor’s job	Yours, continuously	Yours for the storefront, vendor’s for the engine
Payment compliance scope	Largely absorbed by the hosted checkout	Yours to manage, depending on integration method	Depends where checkout lives
Front-end changes	Theme edits, often no developer needed	Theme edits, often no developer needed	Developer required for essentially everything
Merchandising changes	Admin, self-serve	Admin, self-serve	Depends entirely on how you built it
Upgrade treadmill	Vendor-managed, occasional forced migrations	Core, plugin and PHP updates forever	API version deprecations plus framework churn
Cost of a bad decision	Low; you can leave	Moderate; data is portable, integrations are not	High; you own the whole storefront

The line that decides most real cases is the second from bottom. Hosted platforms shift maintenance to the vendor and charge you for it visibly. Self-hosted platforms hand it back and charge you invisibly, in developer hours that never appear in the comparison spreadsheet. Headless adds a third category: the API you build against changes on the vendor’s schedule, not yours, and somebody has to be paid to keep up.

There is a fourth cost that almost never gets modelled — the cost of your merchandising team waiting. If a seasonal campaign needs a developer, the delay is a real commercial loss, and it recurs. Hosted themes and visual editors are frequently mocked by engineers and quietly loved by the people who have to ship a promotion on a Thursday.

Shopify: what you gain and what you give up

What you gain is that a large category of problems stops being yours. Uptime under a traffic spike, PCI scope on the checkout page, gateway maintenance, fraud tooling, the tax engine, and the endless small compliance changes arriving from payment networks are all absorbed. For a business whose advantage is merchandising or brand rather than technology, that is exactly the right trade.

You also inherit a checkout that a very large team optimises full-time. Given that the aggregate documented cart abandonment rate across 50 studies compiled by Baymard Institute sits at 70.22%, that is not a small inheritance. Baymard’s data also shows what actually loses the sale: among people who abandon for reasons other than browsing, 40% cite extra costs being too high, 18% abandon because they were forced to create an account, and 17% because the checkout was too long or complicated. Two of those three are configuration decisions rather than platform decisions — a useful reminder that the platform is rarely the thing costing you conversions.

What you give up is the checkout itself, and a certain amount of dignity around app sprawl. Every capability that is not core arrives as an app with its own subscription, its own scripts on your pages, and its own opinion about your data model. A store with twenty apps has twenty vendors, twenty renewal dates and twenty possible sources of a client-side script you did not write — which matters more than it used to, given that PCI DSS requirements 6.4.3 and 11.6.1 require payment page scripts to be authorised, integrity-checked and monitored for tampering.

You also give up the ability to do genuinely unusual things at the point of purchase. If your business needs a quotation flow, a credit application, or a multi-party approval before an order is placed, the hosted checkout will fight you, and the right response is usually to ask whether a retail platform is the correct tool at all.

WooCommerce: control, and the maintenance bill attached to it

WooCommerce earns its place when the store is genuinely an extension of a content business. If you publish heavily, if organic traffic arrives on guides and comparisons rather than product pages, if your editorial workflow already lives in WordPress — then keeping content and commerce in one system removes a whole class of integration problems, and the ones it creates are smaller.

The control is real. You can change the data model, write your own extension, host wherever you like, and take the database with you. Nobody can deprecate your storefront.

The bill attached is also real, and it is not primarily financial. WordPress’s own guidance on hardening states the division of responsibility explicitly: hosts are responsible for the infrastructure, not for the application you chose to install on it. Core updates, plugin updates, removing plugins you stopped using, file permissions, database user restrictions, monitored backups — a standing job, not a launch task. When WooCommerce stores are compromised it is very rarely because somebody found a novel flaw in WooCommerce; it is because a plugin went unpatched on a site where maintenance was nobody’s explicit responsibility.

The second cost is performance discipline. WordPress will happily let you install a visual builder, three analytics tools and a slider plugin on a product template, and then you are trying to hit a Largest Contentful Paint under 2.5 seconds at the 75th percentile on a page loading nine stylesheets. It is entirely possible to run a very fast WooCommerce store. It is not possible to run one accidentally. If you want the detail on what those thresholds mean and how to move them, we have written about the three Core Web Vitals separately.

So the honest test for WooCommerce is not technical. It is: who, by name, is responsible for updates? If you can answer that, it is an excellent platform. If the answer is “we’ll sort it out”, choose hosted and spend the saving on photography.

Headless: when a faster storefront pays for itself

Headless is the option most often bought for the wrong reason, and the usual wrong reason is speed — the belief that a decoupled front end is inherently faster. It can be, and frequently is not, because storefront performance is decided by what you put on the page rather than by how the page is rendered. A React storefront shipping four hundred kilobytes of JavaScript before the first product image is not faster than a well-built theme. It is slower, with better slides.

The right reasons are structural:

1. The experience you need cannot be expressed in the theme layer. Configurators, complex bundling, an interface that behaves like an application rather than a catalogue.
2. One catalogue, many front ends. Several brands, several regions, a mobile app and a web store sharing one commerce engine. This is the case where headless is unambiguously correct.
3. Content and commerce are equal partners. You need editorial control a commerce platform’s CMS cannot give you, and you refuse to maintain two systems that both claim to own the product page.
4. Your front-end team already exists. If you employ front-end engineers, the marginal cost of headless is far lower than if you would be hiring them for this project alone.

What you take on is precise and permanent. The Storefront API is versioned quarterly — a healthy, well-documented cadence and also a commitment: something in your codebase will need attention every year, indefinitely. Preview, search, faceted navigation, sitemaps, redirects and structured data all become yours to implement. Google’s ecommerce guidance is clear that discoverability depends on crawlable links from menus through category and sub-category pages down to every product, supported by Product, ProductGroup, BreadcrumbList and Organization structured data. On a themed store those arrive by default. On a headless build they arrive because you built them, and their absence is one of the most common reasons a technically impressive replatform loses traffic.

If you do go headless on Shopify, the choice between Hydrogen with Oxygen hosting and a stack of your own is mostly a question of how much undifferentiated work you want to inherit. Shopify’s headless documentation frames it the same way: prebuilt components and included hosting, or complete freedom and complete responsibility.

The thresholds where the answer flips, and why revenue is not one of them

You will read confident claims that headless “makes sense above” some annual revenue figure. Treat every one of them as a sales aid. Nobody has run the experiment, the figures differ by an order of magnitude between sources, and none of them are measured — they are the number that felt right to whoever wrote the article.

Revenue is a proxy for the only thing that actually matters: whether you can afford to permanently retain the engineering capacity your architecture requires. Say that directly instead of encoding it in a threshold, and the conversation improves.

The real flip points are these:

• From Shopify to headless when merchandising is repeatedly blocked by something the theme layer cannot express, and you have quantified what that block costs.
• From WooCommerce to Shopify when maintenance has become the dominant use of your development budget and nothing about your business requires WordPress’s flexibility.
• From Shopify to WooCommerce when content is the acquisition engine, the product count is modest, and the store is genuinely secondary to publishing.
• From anything to composable when you run multiple brands or regions and the cost of duplicated configuration exceeds the cost of integration ownership.
• Stay exactly where you are when the honest diagnosis is that your product pages do not persuade, your photography is weak, or your delivery proposition is uncompetitive. No platform fixes those, and replatforming is an unusually expensive way to avoid confronting them.

Content-led stores versus catalogue-led stores

This distinction predicts platform fit better than revenue, category or product count, and it is the first question worth asking.

A catalogue-led store wins on breadth, search, filtering and merchandising. Customers arrive knowing roughly what they want; the product page’s job is to remove doubt. Here, hosted commerce is usually right, because the platform’s own search, faceted navigation, variant handling and inventory logic are precisely the features you would otherwise build badly.

A content-led store wins on trust built before the customer knows which product they need. Traffic arrives on guides, comparisons and explanation, and commerce is the conversion step at the end of an editorial journey. Here, WordPress with WooCommerce or a headless build with a proper CMS both make sense, and the deciding factor is whether the catalogue is simple enough for WooCommerce to handle comfortably.

The mistake is running a content-led business on a platform whose CMS is an afterthought, then compensating with a blog on a separate subdomain — splitting internal linking, fragmenting authority, and producing exactly the disjointed experience you were trying to avoid. Our ecommerce SEO work spends a surprising share of its time undoing that one decision.

Payments, tax and compliance: the boring constraints that usually decide it

More platform decisions are settled here than anywhere else, and it is the section most comparison articles omit because it is not interesting.

Payment methods. Work backwards from the methods your customers use in the markets you sell to, not from a feature list. If a market’s dominant method is not supported natively, you are either integrating it yourself or accepting a conversion penalty. Check this before anything else; it disqualifies options faster than any other criterion.

PCI scope. How your checkout collects card data determines how much of PCI DSS applies to you. A hosted checkout absorbs most of it; a self-hosted checkout using a gateway integration that keeps card data off your servers absorbs a lot of it. Either way, the payment page script requirements apply to any page that can affect the security of a payment, including pages using embedded iframes — so “we use a hosted gateway” is not the end of the conversation about which third-party scripts you allow near checkout.

Tax. Multi-jurisdiction VAT, marketplace rules and digital goods thresholds are handled to very different standards across platforms and plugins. Have your accountant look at the actual tax configuration during evaluation, not after launch. This is unglamorous advice that has rescued more projects than any architectural insight.

Consent and measurement. In the EU and UK your analytics and marketing tags are a compliance surface as well as a measurement one. That is a separate discussion from platform choice, but it constrains which apps you can safely install and how you count what happens after the click.

Migration risk: what actually breaks when you replatform

If you are replatforming rather than starting fresh, risk concentrates in a few predictable places, and every one of them is manageable when planned rather than discovered.

1. URLs. Every platform generates a different structure for products, collections and filtered views. Map old to new before you build, redirect in a single hop, and keep the map as a deliverable. Losing this is the most common cause of a traffic collapse after relaunch.
2. Structured data. New templates emit different markup. Product rich results vanish quietly and nobody notices for six weeks. Validate before launch, not after.
3. Speed. A rebuild is assumed to be faster. Benchmark the old site’s field data first, so you have a comparison rather than a feeling.
4. Undocumented business logic. The discount stacking rule, the shipping exception for one region, the integration the warehouse depends on. This lives in configuration and in people’s heads. Inventory it early; it is what causes launch delays.
5. Historic order and customer data. Decide what genuinely needs to move. Full order history is often less valuable than teams assume, and migrating it badly is worse than archiving it cleanly.

We have written a fuller treatment of the search side of this in how to redesign without losing your rankings, and the principles transfer directly to commerce.

A decision matrix you can take to a board meeting

If you need one page, this is it. Score honestly; the value is in the arguments it starts, not in the total.

If this is true of you	Shopify	WooCommerce	Headless
No in-house developer, and none planned	Strong fit	Poor fit	Wrong
Content is your main acquisition channel	Workable	Strong fit	Strong fit
Large, complex catalogue with heavy filtering	Strong fit	Workable with effort	Strong fit
You need a bespoke or multi-step purchase flow	Constrained	Possible	Possible
Several brands or regions on one catalogue	Workable	Poor fit	Strong fit
Merchandisers must ship changes without a developer	Strong fit	Strong fit	Depends on build
You already employ front-end engineers	Fine	Fine	Now affordable
Peak traffic is spiky and unpredictable	Absorbed by vendor	Your problem	Your problem
Nobody owns ongoing maintenance	Strong fit	Do not choose this	Do not choose this
You cannot name the thing you cannot do today	Strong fit	Fine	You are not ready

The pattern worth noticing is that the last row does most of the work. If you cannot articulate a specific capability you are missing, the platform is not your constraint, and a replatform will convert a marketing problem into a technology project without solving either.

We build on all three, and the recommendation depends entirely on the answers above — which is why our ecommerce development engagements begin with a written scoping exercise rather than a platform pitch. If the honest answer is that you should stay where you are and spend the money on product copy and photography, that is a legitimate outcome and we would rather say it early. Where a project genuinely needs custom work beyond a store, that is web development territory, and the two disciplines meet far more often than the platform marketing suggests.