You integrate a headless CMS with Magento by treating the CMS as a content source, not a second frontend. Contentful, Storyblok, or Contentstack holds the structured content; Magento keeps commerce; a connector module pulls content in and renders it inside your Hyva theme, with cache tags wired so a CMS edit clears only the pages it touched.
That one sentence hides the decision most teams get wrong. On a Hyva storefront the theme is not headless, so a headless CMS does not replace your frontend. It replaces the part of Magento content editors hate: page building, campaign landing pages, editorial blocks, and the reusable modules that marketing wants to change without a deploy. Get the boundary right and you gain a real authoring experience without giving up Magento’s full page cache or the Core Web Vitals a Hyva build was supposed to protect. Get it wrong and you bolt a slow API call onto every page.
This guide covers what headless actually means on Magento, how to choose between the major platforms, the integration pattern that keeps full page cache intact, and how to model content so it holds up across brands, locales, and thousands of pages.
What “headless CMS” means on a Magento store
Two ideas get merged under the word headless, and separating them is the whole job.
A headless architecture decouples the storefront from the backend. The frontend is a separate application (React, Vue, a PWA) that talks to Magento over GraphQL or REST. A Hyva theme is deliberately not this. Hyva is a coupled Magento theme that ships around 0.15 MB per product page against Luma’s roughly 0.9 MB, using Tailwind CSS and Alpine.js inside the standard Magento render loop. It is fast because it stays inside Magento, not because it left.
A headless CMS is a different thing. It is a content repository with an authoring UI and a delivery API, and no opinion about your frontend. You can consume it from a fully decoupled React app, or you can consume it from inside a normal Magento theme like Hyva. The second option is the one most mid-market merchants actually want, and it is the one the generic “headless Magento” articles skip.
So the practical setup for most stores on Magento and Adobe Commerce is: keep Hyva as the coupled, fast frontend, and add a headless CMS as the editorial content layer behind it. Commerce data stays in Magento. Marketing content moves to a system built for marketing.
The three ways to run content on Magento and Hyva
Before adding a third-party CMS, be honest about whether you need one. There are three real options, and the native path is enough for a lot of stores.
| Approach | What edits content | Best for | Main cost |
|---|---|---|---|
| Native Magento CMS + Page Builder | Magento admin, Page Builder drag-and-drop | Stores with simple blocks and pages, one or two locales | Page Builder output needs Hyva compatibility work |
| Hyva CMS (part of Hyva Commerce) | Native Hyva editor with live preview and drag-and-drop | Teams that want native authoring without a separate system | Licensed as part of Hyva Commerce |
| External headless CMS (Contentful, Storyblok, Contentstack) | The CMS visual editor, outside Magento | Multi-brand, multi-locale, high content velocity, shared content across channels | A connector module plus cache and modeling work |
Magento’s own CMS supports pages, blocks, widgets, and Page Builder, and Hyva renders all of them; the Hyva CMS documentation is explicit that every native content method is supported, with a Tailwind JIT module that compiles utility classes inside database-managed content. Hyva CMS, the licensed option, adds a native editor with live preview so you are not fighting Page Builder’s markup.
You reach for an external headless CMS when content outgrows the store: several storefronts sharing the same campaign, content editors who need to work ahead of engineering, a locale count that makes the Magento admin painful, or a content team that also feeds an app, a help center, or retail screens from the same source. If that is not you, the native or Hyva CMS path is cheaper and simpler, and adding Contentful is a cost with no return.
Choosing the CMS: Contentful, Storyblok, and Contentstack
The three platforms most Magento teams evaluate differ less on raw capability than on editor experience and how their pricing behaves as you grow.
| Platform | Content model | Editor experience | Pricing shape (2026) | Fits when |
|---|---|---|---|---|
| Storyblok | Stories and nested “bloks” (reusable components) | Visual editor with side-by-side live preview of your real frontend | Five tiers including a free plan; component model keeps mid-market cost predictable | Marketers rearrange and swap sections without a developer |
| Contentful | Discrete content types with typed fields and references | Form-first, with page-building and live preview added later | Generous free tier on users, tight on locales and API calls; first paid step near $300/month; enterprise pricing rose about 30% year over year | Structured content reused across many channels, strong developer governance |
| Contentstack | Modular content types with references | Form-first with visual building tools, enterprise workflow depth | Enterprise-oriented; quote-based | Large orgs needing approval workflows and compliance |
Storyblok’s stories-and-bloks split is the reason it shows up in so many Magento builds: a “blok” is a reusable component with its own schema, so a hero, a promo grid, and a product-story module become things editors place and reorder visually. Its Content Delivery API v2 is what the storefront reads from.
Contentful models content as strongly typed entries linked by references, which is cleaner for content that many surfaces consume but heavier for freeform page building. Its cost curve is the thing to watch. The free tier is tight on locales and monthly API calls, the first real plan starts near $300 per month, and enterprise pricing has climbed faster than the rest of the category. Model your API call volume before you commit, because full page cache changes that number dramatically (more on that below).
Contentstack sits at the enterprise end, worth evaluating when approval workflows and governance matter more than price. Whichever you pick, the integration pattern into Hyva is the same, and that pattern is where projects succeed or fail.
The integration pattern that does not break full page cache
This is the part the commodity guides never cover, and it is the only part that decides whether your fast Hyva storefront stays fast.
Magento runs four cache layers: low-level cache, full page cache, Edge Side Includes, and browser cache. Full page cache is what serves a Hyva page in a few milliseconds without rebuilding it. The danger with an external CMS is obvious: if every page render calls Contentful or Storyblok live, you have added a network round trip to a page that used to be served from cache, and you have thrown away the speed a Hyva build over full headless exists to deliver.
The correct pattern renders CMS content server-side, inside cacheable Magento blocks, with tag-based invalidation:
- Fetch on render, not on request. A Magento block or view model pulls content from the CMS delivery API when the page is rendered and cached, not on every visitor request. Once the page is in full page cache, no CMS call happens at all until the cache is invalidated.
- Cache the API response. Store the CMS payload in Magento’s low-level cache with its own tag, so even a cache miss on the page does not hammer the CMS API. This is also what keeps a metered plan like Contentful’s from running up API calls.
- Attach cache tags to the content. Each rendered piece of CMS content carries a cache tag tied to its CMS entry ID. Standard Magento has a real limitation here: view models cannot natively contribute cache tags to full page cache. Hyva solves it directly with its view model cache tags feature, which lets a view model declare tags that get appended to the response.
- Invalidate from the CMS with a webhook. When an editor publishes a change in Storyblok or Contentful, the CMS fires a webhook to a Magento endpoint that cleans exactly the cache tags for the changed story. Only the affected pages rebuild. The rest of the site stays served from cache.
The open-source Media Lounge Storyblok module for Magento 2 implements this shape: routing, block classes and template conventions, image transformation and WYSIWYG helpers, caching, and sitemap integration, positioned as an alternative to Page Builder. It is a good reference even if you build your own connector, because it shows where the cache-tag and webhook plumbing has to live.
If you would rather consume CMS content through the same GraphQL layer as the rest of a decoupled build, Magento’s own cmsBlocks GraphQL query is the native equivalent for Magento-managed blocks, and the same cache discipline applies. For the deeper mechanics of how Hyva favors private content and tag-based invalidation over ESI hole-punching, our write-up on full page cache and Varnish on Hyva goes further than there is room for here.
The rule to hold onto: a headless CMS should add zero network calls to a cached page view. If it adds one, the integration is wrong.
Modeling content so it scales
A CMS integration that renders fast can still rot if the content model is bad. At scale, the model is the product.
Design components, not pages. Model reusable pieces (a hero, a feature row, a promo banner, a product story, an FAQ) as typed components, then let editors compose pages from them. Storyblok’s bloks and Contentful’s linked entries both support this. A page becomes a list of component references, which is what lets one campaign layout serve many storefronts.
Separate content from presentation. A component stores the content and a variant field, not raw HTML with inline styles. The Hyva template decides how a “promo banner, style B” looks. This keeps Tailwind and design system control in the theme where it belongs and stops editors from pasting markup that breaks on mobile.
Plan localization at the model level. Decide early whether locales are field-level translations or separate content trees. This is exactly where Contentful’s locale limits on lower tiers bite, and where a multi-brand build gets expensive if you did not plan it. If you already run several brands or regions, the content model has to mirror your Magento website and store-view structure, not fight it.
Keep commerce data in Magento. Price, stock, and catalog attributes stay in Magento and render as Hyva’s dynamic, uncached sections. The CMS never holds a price. This is the same discipline as any enterprise integration: one system of record per data type. The pattern mirrors how a PIM feeds product data into Magento and Hyva while the storefront stays fast, and it is worth borrowing that boundary here.
Content modeling is unglamorous and it is the difference between a CMS that serves three brands cleanly and one that needs a rebuild in eighteen months. It is also where an experienced Magento and Hyva partner earns their fee, because the mistakes are hard to see until the content volume exposes them.
Does the platform change the answer? Shopify, BigCommerce, and Shopware
The “CMS as a content source, render server-side, invalidate by webhook” pattern is Magento-shaped, but the same headless CMS platforms integrate across every stack we build on, with different mechanics.
On Shopify and Shopify Plus, a headless CMS usually pairs with a decoupled frontend (Hydrogen or a custom head) because Shopify’s own theming is more constrained, so content and commerce meet in the frontend rather than in a coupled theme. On BigCommerce, the API-first design makes a headless CMS a natural fit, again typically with a separate frontend. On Shopware, the Shopping Experiences builder covers a lot of what a headless CMS would, so the integration question becomes whether an external CMS adds enough for multi-channel reuse to justify the second system.
The takeaway: the CMS choice travels across platforms, but the integration architecture does not. On Magento with Hyva, the winning move is server-side rendering inside cache, which is not how you would do it on a decoupled Shopify head. Match the pattern to the platform.
A rollout sequence that does not stall
Content projects fail by trying to move everything at once. Phase it.
- Baseline first. Record current Core Web Vitals field data and the pages content editors touch most. You are protecting the former while fixing the latter.
- Model a single content type. Pick one high-value, high-churn surface (campaign landing pages) and model it fully in the CMS before touching anything else.
- Build the connector with cache tags and the webhook. Prove that a CMS publish invalidates only the right pages and that a cached page makes no CMS call. This is the acceptance gate.
- Migrate content type by type. Move blocks and pages in waves, not in one cutover. Keep native Magento CMS for anything not yet migrated.
- Hand editors the keys. Train the content team on the CMS visual editor. The whole point was to remove engineering from routine content changes, so measure whether that actually happened.
Bemeir runs this as an extension of your team, with the deep technology partner ecosystem to connect the CMS, ERP, and search layers around a Hyva storefront. If you are weighing whether a headless CMS is even the right call versus native Hyva CMS, that is a scoping conversation worth having before the first line of connector code. Start with Bemeir if you want that call to be honest about when not to add one.
FAQ
Does adding a headless CMS slow down a Hyva storefront?
It should not, if the integration is built correctly. Content is fetched when a page is rendered and stored in full page cache, so cached page views make zero calls to the CMS. The slowdown only happens when a connector calls the CMS API live on every request, which is an implementation mistake, not a property of headless CMS.
Is Hyva itself headless?
No. Hyva is a coupled Magento 2 frontend theme that renders inside Magento using Tailwind CSS and Alpine.js. It is fast because it stays in the Magento render loop, not because it decouples from it. A headless CMS can sit behind a coupled Hyva theme as a content source without making the storefront headless.
Contentful or Storyblok for a Magento and Hyva build?
Storyblok’s stories-and-bloks model and side-by-side visual editor tend to fit merchant marketing teams that rearrange page sections themselves, with more predictable mid-market pricing. Contentful suits structured content reused across many channels with strong developer governance, but model your locale count and API call volume against its tier limits first, since its enterprise pricing has climbed faster than the category.
How does a CMS edit clear the right Magento pages?
The CMS fires a webhook to a Magento endpoint on publish. That endpoint cleans the cache tags associated with the changed content entry, so full page cache rebuilds only the affected pages. Hyva’s view model cache tags feature is what lets that content carry the tags full page cache needs, which standard Magento view models cannot contribute on their own.
Do we still need Magento’s native CMS if we add a headless one?
Usually yes, at least during migration and often permanently for simple blocks. Native Magento CMS and Page Builder keep working alongside an external CMS, and Hyva renders both. Many stores end with a split: transactional and simple content in Magento, editorial and campaign content in the headless CMS.
