Why this storefront has no theme

This shop runs headless WooCommerce: WordPress still holds every word, price and image on the site, and it no longer renders a single page. That one change moves more than it sounds like it should.
Every page on this site is written and stored in WordPress. None of it is rendered by WordPress. The content leaves as data over GraphQL, and a Next.js application turns that data into HTML on a server that does nothing else. That split is the whole idea, and it is worth explaining, because it is the reason the shop feels the way it does.
What a theme actually costs
A traditional WordPress page is assembled at the moment you ask for it. The server loads the framework, then the plugins, then the theme, then runs a few dozen database queries, then prints the HTML. On a good host that is a few hundred milliseconds of work repeated for every visitor. The browser is then handed a stylesheet it did not ask for, a script bundle it will never call, and a slider library that exists because one page needed it years ago.
None of that is a complaint about WordPress. It is very good at storing content and very good at letting a person edit it without learning anything new. It is simply doing a second job, rendering, that it does not have to do.
What replaced it
- Pages are rendered once and cached as static HTML, with only the parts that genuinely change per visitor streamed in afterwards.
- Every query the front end can make is stored inside WordPress as a persisted document, so the shape of the data is fixed, cacheable on the WordPress side, and impossible for a stray request to abuse.
- When a product changes, WordPress sends one request that clears exactly the cached entries mentioning it. A price change on a single can does not throw away the whole catalogue.
- Images are converted to AVIF on demand and served at the size the layout asks for, not at the size they happened to be uploaded.
What did not change
The editor. Every headline, every product description, every meta title and description on this site lives in WordPress and is edited in WordPress. Rank Math still decides what a search engine is told about a page. The only thing that moved out is the rendering.
If you would rather feel it than read about it, open the shop and click into a can. The page arrives from cache; the price and stock line does not.
Three things headless WooCommerce gains

Speed you keep. Pages are built ahead of time and served as static files, then revalidated when WordPress says something changed. A plugin cannot slow the front end down, because the front end is not running plugins.
A front end you actually control. No theme to fight, no filter to unhook. The hero on this site is a real three dimensional can; that is not a thing a theme would have let us do.
One catalogue, many surfaces. The same WooCommerce data feeds the storefront, a product feed for Google Shopping, a machine readable catalogue for AI agents and a reseller API, because nothing is welded to a template.
The honest cost
Preview and the block editor stop matching what a visitor sees, so an editor writes without a live preview of the final page. Anything a plugin used to output on the front end has to be rebuilt in the storefront. You are running two deployments instead of one. For a small brochure site that trade is not worth making.
What stays the same for the editor

Almost everything. Products are still WooCommerce products with the same fields. Pages are still pages, menus are still menus, and the colours and copy on the about page are ordinary custom fields. Press update and the storefront rebuilds that page within a second or two.
How the pieces connect
WordPress exposes the catalogue over GraphQL and the WooCommerce REST API; the storefront queries it, caches by tag, and a small plugin pings the app whenever something is saved so exactly the affected pages refresh. The reseller side of the same data is documented on the API page.


