Shopify Headless Commerce: What Hydrogen Actually Buys You

21 August 2026

“Headless commerce” gets thrown around a lot in Shopify conversations lately, often without much precision about what it actually means or when it’s worth the extra engineering. Having built and shipped a real headless Shopify storefront this year rather than just read the docs, here’s what actually changes when you go headless, and where the complexity really ends up living.

What “headless” actually means on Shopify

A standard Shopify store is server-rendered: Liquid themes, sections and blocks, with Shopify handling routing, cart state and checkout for you. Headless replaces that frontend entirely. Hydrogen, Shopify’s React framework built on React Router 7, talks to Shopify only through the Storefront API and Customer Account API, and deploys to Shopify’s own edge runtime, Oxygen. You get full control over rendering, routing and UI, at the cost of everything a theme used to hand you for free.

When it’s actually worth the switch

For a single-brand store with a fairly standard catalogue and checkout, a well-built Online Store 2.0 theme is usually the right call. Hydrogen doesn’t buy you anything a solid theme can’t already do. Headless earns its complexity when the storefront needs to do something Liquid genuinely can’t: serve multiple distinct brand experiences from one backend, gate content behind real authentication instead of a password page, or build interaction patterns that a theme’s section/block model can’t express cleanly.

Multi-brand, one backend: what I built for Fullerton Group

This is where I put it into practice. Fullerton Group needed one Shopify backend serving three separate security-industry brands, Professional Security, Armatus and Bridgegate Security, each with its own look, without maintaining three synced stores or three codebases. Hydrogen resolves the active brand from the URL path segment on every request, and shared routes swap header, footer and theming per-brand from that single decision point. On top of that: a restricted trade ordering channel gated through the Customer Account API rather than a public password page, a custom pay-in-full vs. pay-in-instalments toggle built entirely in-house with no third-party app, and a monthly auto-rotating password gate for the employees-only areas. All of it runs on one GraphQL Storefront API layer, deployed to Shopify Oxygen through a proper CI/CD pipeline rather than manual theme pushes.

What you actually take on when you go headless

• SEO and metadata. A theme gets this mostly for free; in Hydrogen, every route’s meta tags, structured data and canonical URLs are your responsibility to wire up correctly.
• Cart and checkout handoff. The cart lives in your app until the moment it hands off to Shopify’s checkout, so cart state, persistence and edge cases become your code, not theme code.
• Caching and edge behaviour. Oxygen gives you the infrastructure, but deciding what’s cached, for how long, and when it’s invalidated per brand or route is now an explicit decision, not a platform default.
• Deployments. There’s no “save theme, it’s live” anymore. A real CI/CD pipeline, build, test, deploy to Oxygen, becomes part of the job rather than optional tooling.

None of this makes headless the wrong call, it just moves the complexity rather than removing it. If your storefront genuinely needs multi-brand logic, real authentication or interaction patterns a theme can’t express, Hydrogen is worth the investment. If it doesn’t, you’re signing up for infrastructure work a good Online Store 2.0 theme would have handled for you anyway.

Back