One of the first questions every Hydrogen project runs into, usually about two weeks after launch: “how does the marketing team change this page?” In Liquid world the theme editor answered that. In Hydrogen you have to choose your answer deliberately, and the options have genuinely different tradeoffs. Here’s the landscape as honestly as I can lay it out.
Option 1: Shopify metaobjects (+ metafields)
The native route. You model content types in Shopify admin, editors fill in fields, your components query them through the Storefront API.
Pros
- Free, no extra vendor, no extra API to integrate or authenticate
- Content lives next to products/collections - one admin, one permission system
- Storefront API access is first-class, works cleanly with Hydrogen’s caching
- Good enough for a surprising number of stores: FAQs, banners, feature blocks, editorial snippets
Cons
- The editing experience is forms, not pages. Editors fill in fields blind and check the live site to see the result no visual preview out of the box.
- Layout is fixed by developers. Marketers can change content, not structure. New section arrangement = developer ticket
- Complex nested content (landing pages with flexible section ordering) gets awkward to model and awkward to edit
- No built-in scheduling/drafts workflow for storefront content the way a CMS has
Honest take: if your content needs are “editable text and images inside developer-defined layouts,” start here. Plenty of Hydrogen stores never need more, and you can add a CMS later without throwing this away.
Option 2: Headless CMS (Sanity, Contentful, Storyblok, Prismic, etc.)
A dedicated content platform. Developers define schemas, editors work in a purpose-built interface, the storefront queries the CMS API alongside the Storefront API.
Pros
- Serious content modeling: references, localization, drafts, scheduling, roles, revision history
- Much better editing UX than metaobject forms; some (Storyblok, Sanity with Presentation mode) offer visual preview with setup work
- Content can serve more than the storefront: blog, app, email, other channels
- Mature ecosystems, good docs, established Hydrogen integration patterns
Cons
- Cost: real subscription tiers once you pass hobby usage, plus meaningful integration time
- Two systems of record. Product data in Shopify, content in the CMS, and someone has to design how they reference each other
- Editors still work within developer-defined components. Better UX, same fundamental constraint: layout changes usually still need a developer
- Preview environments for Hydrogen take genuine setup effort
Honest take: the right call when content is a core part of the business - editorial-heavy brands, multi-market/localized stores, teams that publish constantly. Overkill if you need five editable sections on a homepage.
Option 3: Visual page builders for Hydrogen
Tools that sit on top of your Hydrogen components and give non-developers a drag-and-drop, WYSIWYG editing surface, closer to the Liquid theme editor experience, but for headless. Examples in this space: Builder.io, Pack Digital, Makeswift, and others.
Pros
- Marketers get real autonomy: rearrange sections, build landing pages, see changes visually before publishing without a developer ticket
- Developers still control the component library, so brand/quality guardrails hold
- Usually the fastest path to “the marketing team stopped asking us for content updates,” which is the pain that starts this whole conversation
- Post-launch handoff to clients gets much cleaner for agencies
Cons
- Another vendor dependency in your critical rendering path - evaluate what happens to your storefront if the service degrades, and what caching/fallback looks like
- Lock-in is real to varying degrees: how your components integrate with the tool determines how painful leaving would be. Ask this question before adopting, not after
- Cost, again and pricing models vary a lot (per-seat, per-view, flat)
- Less flexible than a full CMS for non-page content (structured editorial, multi-channel content)
- The space is younger than the CMS space; evaluate each tool’s maturity and Hydrogen/Oxygen compatibility specifically, not the category generally
Honest take: the right call when the actual bottleneck is marketer autonomy over pages: landing pages, campaign pages, frequent merchandising changes. If your content is more editorial than page-composition, a CMS fits better.
How I’d decide
- Small store, content changes are occasional, dev is reachable → metaobjects. Don’t buy a problem you don’t have.
- Content-heavy brand, multiple locales, dedicated content team → headless CMS.
- Marketing team ships landing/campaign pages weekly and every change is currently a dev ticket → visual page builder, or CMS-with-visual-preview if your content also lives beyond the storefront.
- Not sure → start with metaobjects. It’s free to be wrong; the migration path to either other option is well-trodden.
And these combine - metaobjects for product-adjacent content plus a CMS for editorial is a common pattern.
What are other teams here running? Especially interested in anyone who switched approaches mid-project and why.