A buyer’s guide to headless Shopify
The questions worth answering before you sign off a headless project, in plain language.
How a headless Shopify store fits together
In a theme store, Shopify receives each request, runs your Liquid templates and returns finished HTML. In a headless store, that job moves to an application you control. When a shopper opens a product page, your front end asks the Storefront API for the product, its variants, prices, media and whichever metafields the page needs, then renders the page itself. The Storefront API is a GraphQL API, so every query names the exact fields a page uses. Done well, that keeps responses small and pages quick.
The cart still lives in Shopify. Your front end creates and updates it through Storefront API cart mutations, and when the shopper is ready to pay it sends them to the cart’s checkout URL. From there they are on Shopify’s own checkout, with the same payment methods, tax handling, shipping rates and discount logic as any other Shopify store. Orders arrive in your admin as usual, so fulfillment, ERP syncs and email flows keep running from Shopify data.
- Storefront API for catalog, search, filters, cart and localized prices
- Shopify checkout for payment, with your discounts and Functions intact
- Customer Account API for login, order history and saved addresses
- Admin API and webhooks for back-office jobs that never belong in the storefront
Hydrogen and Oxygen, or Next.js
Hydrogen is Shopify’s own framework for headless storefronts. It is built on React and comes with ready-made pieces for problems every store has: cart handling, SEO metadata, caching of Storefront API responses and sending storefront events to Shopify analytics. Oxygen is Shopify’s hosting for Hydrogen storefronts. Connected to a GitHub repository, it can create a preview deployment for each change, so reviewers click through real pages before anything goes live. Choosing Hydrogen keeps you close to Shopify’s tooling and documentation.
Next.js is the other common route, often hosted on Vercel. It makes sense when your developers already use it, when the site has large sections that are not commerce at all, or when one framework should serve several properties. It reads the same Storefront API. What you give up is the Shopify-specific tooling, so cart, analytics and caching helpers have to be written or sourced separately. We recommend one or the other based on your team and content, and we put the reasons in writing.
Where your content should live
Headless lets you choose where content is edited, and the choice shapes your team’s week. Shopify metaobjects and metafields keep structured content inside the admin you already use, with no extra subscription, and both are readable through the Storefront API. They suit product-adjacent content such as ingredient lists, size guides, store locations or designer profiles.
A headless CMS such as Sanity or Contentful suits editorial teams who need rich editing, scheduled publishing, approval steps and live previews of unpublished pages. Many brands use both: product facts in Shopify, stories and campaigns in the CMS, joined by product references. Whichever you pick, we design the content models before building pages. A common mistake is storing whole pages as one block of rich text, which locks the layout and makes every redesign a content migration.
SEO, analytics and consent need rebuilding
A theme quietly handles a lot: canonical tags, a sitemap, title tags from your Shopify SEO fields, product structured data in most themes, analytics and a consent banner tied to Shopify’s Customer Privacy API. In a headless build each of these has to be built on purpose, or it simply will not exist.
We server render every indexable page so search engines receive complete HTML, generate titles and descriptions from the SEO fields your team already edits, output product and organization structured data, publish XML sitemaps and map every old URL to its new home with permanent redirects. For measurement, we wire GA4, ad pixels and Shopify analytics to the same events, respect consent before anything fires, and test the full path from page view to purchase before launch rather than after the first monthly report looks wrong.
The real cost of owning a headless store
The build is only part of the bill. A headless storefront needs framework and dependency updates, hosting, error monitoring and someone who can ship a fix on a Friday. Shopify releases new versions of its APIs on a regular quarterly cycle and retires old ones on a published schedule, so queries need checking and upgrading over time. Apps that were plug-and-play in a theme often become API integrations with their own maintenance. A CMS may carry its own subscription.
None of this is a reason to avoid headless. It is a reason to budget for a technical owner, either your own developers or a support plan with us, and to agree who owns what before launch. When the answer to who maintains this is unclear, we usually recommend a custom theme instead.
