Headless Shopify: When Hydrogen Is Worth It (and When It Isn't)

Headless Shopify is worth it when your storefront has outgrown what a theme can do: you need a custom shopping experience, content from a separate CMS, several storefronts on one backend, or tight control over performance, and you have the budget and an in-house or agency team to maintain a codebase. For most DTC brands below that point, a well-built Liquid theme with custom sections is faster to launch, cheaper to run and easier for the marketing team to manage. Hydrogen makes headless more practical, but it does not make it free: you trade the theme editor and plug-and-play apps for flexibility.

What "headless" actually means on Shopify

A standard Shopify store renders its pages with a Liquid theme. Shopify hosts it, merchandisers edit it in the theme editor, and apps plug into it through app blocks. Headless separates the two layers: Shopify stays the commerce backend (products, collections, customers, cart, checkout, international pricing), and the storefront is a separate web application that pulls that data through APIs.

The moving parts, at the time of writing:

• Storefront API serves products, collections, search and the cart, then hands the customer off to Shopify checkout. The Customer Account API covers login and order history.
• Hydrogen is Shopify's headless toolkit. It is no longer tied to one framework: its core is framework-agnostic, with bindings for React and Vue. Shopify documents two starter templates, React Router 7 deployed to Oxygen and a Next.js template deployed to Vercel, plus examples for Nuxt, SvelteKit and Astro.
• Oxygen is Shopify's hosting for Hydrogen storefronts, enabled by installing the Hydrogen channel. It is included at no extra charge on paid plans (Starter, Basic, Grow, Advanced, Plus), but not on Agentic plans.
• Headless channel manages API access for storefronts you host yourself, on any stack, including Hydrogen apps hosted outside Oxygen.

So "Hydrogen vs Liquid" is really a choice between a theme and an application. Within the application route, you choose between Shopify's toolkit and your own stack (Next.js, Nuxt or anything else calling the Storefront API directly).

What you gain with a headless storefront

• Performance control. You decide what is rendered on the server, what is cached and how much JavaScript ships to the browser. A theme loaded with a dozen app scripts is hard to tune; in your own codebase every request is yours to optimize. This is control, not a guarantee: a poorly built headless site can be slower than a good theme.
• Custom UX. Product configurators, bundle builders, quiz-led shopping, editorial pages mixed with commerce, app-like navigation — things that are awkward inside the section-and-block model become ordinary frontend work.
• Content from a headless CMS. If the brand runs a large content operation (lookbooks, guides, localized landing pages), a CMS like Sanity, Contentful or Storyblok can feed the same storefront as Shopify, with proper content modeling and preview.
• Multi-storefront. One Shopify backend can power several frontends: a main store, a wholesale portal, a brand microsite, a mobile app, all sharing catalog and inventory.
• One stack with the rest of your web. If your marketing site is already in Next.js or Nuxt, the store can live in the same codebase and design system.

What you lose or must rebuild

This is the part most "headless is the future" posts skip, and it decides most projects.

• App blocks and theme app extensions. Many Shopify apps integrate through theme app extensions, which are built for Online Store 2.0 themes. A headless storefront has no theme to host them. Reviews, loyalty, upsells, wishlists and size guides either offer an API or SDK for custom frontends, or have to be rebuilt. Audit every installed app before you commit.
• The theme editor. Merchandisers lose drag-and-drop sections and live preview. Their workflow moves to a CMS, Shopify metaobjects or developer tickets. If the marketing team ships new landing pages weekly, this cost is real.
• Checkout stays on Shopify. Headless does not give you a custom checkout. The cart is built through the Storefront API and the customer is redirected to Shopify checkout. Customizing the information, shipping and payment steps with checkout UI extensions is limited to Shopify Plus, exactly as on a theme store.
• Things a theme gives you for free. Search, filtering, customer accounts, localization, analytics wiring, cookie consent, redirects, sitemap and robots.txt all need to be implemented and tested in the app. Hydrogen covers a lot of this with utilities and templates, but someone still owns it.
• A codebase to maintain. Dependencies, API version upgrades, framework major versions, hosting limits and monitoring become a permanent line item, not a one-time project.

Costs: plans, build and maintenance

The platform side is the cheapest part. At the time of writing, Oxygen hosting comes with paid Shopify plans at no extra charge, so a Hydrogen storefront on Oxygen does not require Shopify Plus. Oxygen has technical limits (worker size, startup time, CPU time per request), which matter only for heavy server logic. If you host elsewhere, such as Vercel for a Next.js storefront, you pay that provider separately, and Plus is still needed only for Plus features like checkout step customization.

The real cost is people:

• Build. A headless storefront is a custom web application. Expect a substantially larger scope than a custom theme, because you are rebuilding the theme's built-in features and replacing apps, not just designing pages.
• Maintenance. You need developers on call for the life of the store: framework and API upgrades, app integrations, bug fixes, new features the marketing team would otherwise add in the editor.
• Operations. Every new campaign page, promotion banner or app trial goes through a development process unless you invest in a CMS setup that lets marketers self-serve.

A useful sanity check: if the brand cannot justify at least one developer, internal or agency, working on the storefront continuously, headless will slowly decay.

SEO on headless Shopify

Headless is neither good nor bad for SEO by itself; it moves responsibility from Shopify to your team. A Liquid theme handles canonical tags, sitemaps, robots.txt and URL redirects out of the box. On headless, you implement them.

• Server-side rendering is mandatory. Product and collection pages must return full HTML, not a client-rendered shell. Hydrogen and the Next.js or Nuxt templates do this by default; a hand-rolled single-page app often does not.
• Meta and structured data. Hydrogen's getSeoMeta utility handles titles, descriptions, canonical URLs and JSON-LD per route. Other stacks use their framework's equivalents.
• Sitemaps and robots.txt. Hydrogen templates include both routes. On Oxygen, non-production deployments are automatically blocked from crawlers, which prevents a common staging leak.
• Migration risk. URL structure changes are the classic way to lose rankings. Keep Shopify's URL patterns where you can, map every old URL to a new one and carry over redirects before launch.

How to choose: Liquid theme vs headless

Here is how the three options compare on the points that usually decide the project.

In our projects we use a simple rule: go headless only when you can name a specific requirement a theme cannot meet, and you can fund a team to own the code after launch. "Faster" or "more modern" alone is not a requirement.

• Early stage, still finding product-market fit. Stay on Liquid. Speed of iteration and app access matter more than architecture.
• Growing brand with a marketing team. Usually a custom Liquid theme. If the blockers are a few unique pages or features, solve them inside the theme first.
• Established brand with complex UX, heavy content or several storefronts. This is where headless pays off. Pick Hydrogen on Oxygen if Shopify is the center of your stack; pick your existing framework if the company already runs Next.js or Nuxt and has developers for it.

The hybrid option covers more cases than people expect. A custom Online Store 2.0 theme with bespoke sections, a few JavaScript-driven components (a configurator, a quiz, a bundle builder) and metaobject-powered content keeps the theme editor and app ecosystem while delivering most of the custom UX. This is the default we suggest before anyone commits to a headless build, and it is the core of our Shopify theme and app development work.

Migration path if you do go headless

• Audit first. List every app, script, integration and custom template. Mark each as "has a headless API," "rebuild" or "drop."
• Model content. Decide what lives in Shopify (products, metafields, metaobjects) and what lives in a CMS, and how marketers will preview it.
• Build in parallel. The Liquid store keeps selling while the new storefront is built against the same backend. Checkout does not change, so orders and payments are unaffected.
• Launch in slices if possible. Some brands start with a headless campaign or content section, then move the catalog.
• Protect SEO. Crawl the old site, map URLs, ship redirects and compare indexation and Core Web Vitals after launch.

If you are weighing this decision, our headless Shopify development team can run the audit and give you a clear "headless, hybrid or theme" recommendation before any build starts. For brands still on another platform, migration to Shopify is usually the first step, and the theme-or-headless choice comes after.