HEADLESS · CONTENT · INTEGRATIONS · 7 OCTOBER 2025 · 6 MIN READ
Headless CMS choices for a Shopify storefront
The shortlist matters less than the four decisions underneath it — and the first one is whether you need a CMS at all.
Start by checking whether Shopify’s own metaobjects will do, because for a large share of headless storefronts they will, and a second system is a second thing to run, sync, pay for and break. If you do need a CMS, the vendor matters much less than four decisions: how it models references between content and products, how its idea of a locale lines up with Shopify Markets, how an editor previews unpublished content in your front end, and how many round trips a page costs once content and commerce come from two APIs. Sanity, Contentful, Storyblok, Prismic and Contentstack will all render a Shopify storefront perfectly well. We would not rank them, because the one that succeeds is the one your content team opens on a Tuesday without asking a developer for help.
IN SHORT
- Shopify metaobjects are the default answer for a headless content model: typed fields, translations, draft and active status, and Storefront API access with no extra system to run.
- Metaobjects run out at editorial workflow beyond draft and active, at content sourced from outside Shopify, and at reads the Storefront API cannot express — it cannot filter metaobjects by field value.
- Never store product data in the CMS. Store a reference and resolve price, stock and title from Shopify at render time, or you will ship a page showing last quarter’s price.
- Preview decides adoption. A CMS whose draft content cannot be seen in your actual front end will be abandoned by editors within two months.
- Two systems means two locale models. Shopify contextualises queries with the `@inContext` directive taking country, language and buyer arguments; your CMS has its own locales, and the mapping between them is code you own.
- Fetch content and commerce in parallel and cache them separately — they change on completely different schedules, and a page that awaits both serially is as slow as the slower one.
First, check whether you need one
A headless build does not automatically require a CMS. Shopify’s metaobjects are a real content modelling system: a definition gives you typed fields, and the documented capabilities cover publishable status, translation, rendering with SEO data, and eligibility to appear as a page. Access is set per API, so a type can be readable by the Storefront API or not. Content lives next to the products, in the admin your team already uses, with no sync to maintain and no bill.
For a storefront whose content is commerce-adjacent — size guides, ingredient lists, store locations, care instructions, landing-page modules, an editorial series — that is often the whole requirement, and the second system would be storing a copy of something Shopify already knew.
Three things push you off metaobjects, and they are worth testing honestly against your own workflow rather than assumed.
- Editorial workflow. Metaobjects give you draft and active. If you need review, approval, scheduled publishing, versions and a way back to last week’s copy, that is a CMS.
- Content from outside Shopify. A newsroom, a print catalogue, a services arm, content shared with a mobile app or a second brand. If Shopify would be holding a copy rather than the record, hold it elsewhere.
- Reads the API cannot serve. The Storefront API’s metaobjects query requires a type and offers no field filtering, sorting only by
idorupdated_at. Anything needing search, facets or cross-type queries needs an index somewhere else — and a CMS with a query language is one place to put it.
What you are actually choosing between
Vendor comparison pages are feature grids, and feature grids do not predict which project succeeds. Four properties do.
Reference modelling. Every content model on a commerce site eventually needs "this article features these products" and "this product has this care guide". How the CMS expresses a reference to something that lives in Shopify — a handle, a global id, a typed reference validated against nothing — determines how much glue code you write and how the page breaks when a product is unpublished.
Localisation model. Some systems treat a locale as a field-level variant, some as a separate document, some as a whole separate space. Each of those maps differently onto Shopify Markets, and the mismatch is your code to write and maintain.
Preview. Whether an editor can look at unpublished content in the real front end, at a real URL, without a developer. Covered below, because it is the one that decides adoption.
The shape of its read API. How many requests a page costs, whether you can get a whole page’s content in one query, and how cacheable the responses are. A content model that requires six requests to assemble a landing page is a slow storefront regardless of how fast the CMS is.
The join: reference, never copy
The single most common bug in Shopify-plus-CMS builds is product data stored in the CMS. Somebody needed a product title and price inside a content block, the CMS made it easy to type one in, and now there are two answers to what a product costs.
The rule is that the CMS stores a reference and nothing else about the product — the handle or the Storefront API id — and the front end resolves title, price, availability and image from Shopify at render time. Price, stock and publication status change without anyone touching the CMS; a copy is stale from the moment it is saved.
Design the failure case too, because it happens weekly on a large catalogue: what does the page do when a referenced product has been unpublished or deleted? The answer must be a deliberate one — omit the card, show the rest of the block, log it — rather than an exception. A featured-products block that throws because one of six products was archived is a homepage outage caused by a merchandising action.
Preview is what decides whether editors use it
A headless build takes away the theme editor. Whatever replaces it has to be good enough that a merchandiser can write a landing page, look at it, adjust it and publish it without involving an engineer. If it is not, they will keep asking for developer time, and the CMS becomes an expensive place where content is typed before someone else builds the real page.
So make preview a requirement in the build, not a phase two. Concretely: a draft-aware route in the front end, a preview token the CMS passes to it, and a link from the editing interface that lands on the page as it will look. Which CMS you choose barely changes the amount of work; skipping it changes whether the project was worth doing.
The test to apply before launch is simple and unforgiving. Ask a merchandiser to build a campaign page from scratch, alone, and time it. If it takes longer than it did on the theme, the content model is wrong — usually too many small types where there should be one page type with a list of blocks.
Two systems, two ideas of a locale
For a single-language store this section does not apply. For anyone selling across markets it is the largest hidden cost in the whole decision.
Shopify contextualises a query using the @inContext directive, which takes an optional country code, an optional language code and an optional buyer argument — so product titles, prices and currency come back localised from the same query. That covers everything Shopify holds, including metaobject translations where the type is translatable.
Your CMS has its own locale concept, its own fallback rules, and its own opinion about what happens when a translation is missing. Between them sits code you write: mapping a route to a Shopify country and language plus a CMS locale, deciding what to render when content exists in one and not the other, and making sure the commerce half and the content half of a page never disagree about which market the customer is in.
Two practical rules. Derive both from one source — the route — rather than letting the CMS and the Storefront API be configured independently. And decide the fallback deliberately per content type: a missing legal page should not silently fall back to English, whereas a missing blog post probably should.
Round trips, and the page that waits twice
Every page on a headless storefront now depends on two networks. The naive implementation fetches content, then fetches commerce, and is as slow as the sum. Fetch them in parallel wherever the content query does not depend on the commerce response — which is most pages, because the content usually contains the references rather than the other way round.
Cache them separately, because they change on entirely different schedules. Content changes when someone publishes; prices and stock change constantly. One cache policy over both either serves stale prices or throws away content that was good for hours.
And keep the content model shallow. A deeply nested model that looks elegant in the CMS interface turns into either a large nested query or several sequential ones, and the second is how a headless storefront ends up slower than the theme it replaced. One request per page for content is a reasonable target to design towards.
What we would actually do
Metaobjects first, and stay there if the workflow requirements are honestly draft-and-publish. That decision has never been the thing that sank a project.
If you need a CMS, shortlist on the four properties above, then choose on the interface your content team prefers after they have each built a page in a trial. We are deliberately not naming a winner: every system on the usual shortlist is capable, and the differentiator in every project we have seen is whether the people who publish content liked using it.
And the option worth keeping on the table: do not go headless. If the reason a CMS is being discussed is that marketing waits a week for a landing page, a section library on the theme fixes that directly, keeps the theme editor, keeps the app ecosystem, and costs a fraction as much. A headless build plus a CMS is two systems to solve a problem that is often one system too many.
Questions this raises
Which CMS works best with headless Shopify?
The one your content team will use without help. Sanity, Contentful, Storyblok, Prismic and Contentstack all integrate fine, and the technical differences between them matter less than reference modelling, locale mapping, preview and the shape of the read API. Before choosing any of them, check whether Shopify metaobjects already cover your model — for many storefronts they do.
Can you use Shopify metaobjects instead of a headless CMS?
Often, yes. Metaobjects give you typed fields, translations, publishable status and Storefront API access with no second system to run. They run out when you need real editorial workflow beyond draft and active, when content originates outside Shopify, or when the reads need filtering and search — the Storefront API cannot filter metaobjects by field value.
Should product data live in the CMS?
No. Store a reference — a handle or a Storefront API id — and resolve title, price, availability and image from Shopify at render time. Anything copied into the CMS is stale from the moment it is saved, and price is the field that gets copied most often and matters most when it is wrong.
How do you handle multiple languages across Shopify and a CMS?
Derive both from the route, never independently. Shopify localises a query through the `@inContext` directive, which takes country, language and buyer arguments; the CMS has its own locales and fallbacks. Write the mapping once, and decide fallback behaviour per content type — a missing legal page should fail visibly rather than quietly serving English.
Does adding a headless CMS make the storefront slower?
It can, and the usual cause is sequencing rather than the CMS. Fetch content and commerce in parallel, cache them separately because they change on different schedules, and keep the content model shallow enough that a page costs about one content request. A deeply nested model that needs several sequential queries is how a headless storefront ends up slower than the theme it replaced.
What happens to the theme editor on a headless build?
You lose it on day one, and whatever replaces it has to be usable by the people who publish. Budget for a draft-aware preview route and a page-level content model with composable blocks, then test it by asking a merchandiser to build a campaign page alone and timing them. If it is slower than the theme was, the content model needs fixing before launch, not after.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.