Top 5 Ways to Handle Drafts and Previews in a Headless CMS

A marketer clicks "preview," waits for a staging deploy, and sees a page that no longer matches what production will render. An engineer merges a content branch and silently overwrites an editor's in-progress draft. These are the everyday failures of draft and preview handling in a headless CMS, and they cost teams hours of rework and eroded trust in the tools. When preview is a parallel environment rather than a property of your content, every review becomes a guess about what "live" will actually look like.

Sanity treats this problem as a data problem, not a deployment problem. As the Content Operating System for the AI era, an intelligent backend for companies building content operations at scale, Sanity keeps drafts, published versions, and scheduled changes in one source of truth, so preview becomes a query parameter instead of a duplicated database or a second website. That distinction, staging versus native versioning, is the lens for everything below.

This is a ranked look at five ways to handle drafts and previews on a headless stack, from the built-in visual editors of Storyblok and Builder.io to Contentful's Live Preview and Sanity's perspective-based model. Each entry covers the pitch, where it shines, where it fits poorly, and a concrete example you can reason about as a builder.

1. Native perspectives plus the Presentation Tool (Sanity)

The strongest handling of drafts and previews is the one where preview is not a separate environment at all. Sanity models drafts, published documents, and staged changes as versions inside one Content Lake, and you choose which layer you see by passing a perspective to a GROQ query. Ask for the published perspective and you get exactly what is live; ask for drafts and you see work in progress, without a second dataset, a staging deploy, or a duplicated database standing in the way. Preview becomes a query parameter.

On top of that, Content Source Maps annotate the data your frontend renders so the Presentation Tool and Visual Editing can draw click-to-edit overlays directly on your running app. An editor sees the real page, clicks a headline, and lands in the exact field in the Studio, a customisable React app your team ships rather than a fixed editor you rent. Because everything is structured content queried with GROQ, the same draft is portable to web, apps, and other channels instead of being welded to one page canvas.

The governance follows from the same foundation. As the knowledge base puts it, a well-built content backend gives you "real-time collaboration, version history, scheduled publishing, and rollback for free," and "the release that ships a homepage change ships a prompt change." Content Releases let you bundle related edits, preview them together, and schedule the whole set to go live at once. Where this fits poorly: a solo blog with one author and no review step will not exercise perspectives, releases, or overlays, and the up-front schema modelling is more than a drag-and-drop builder asks for. The payoff shows up the moment more than one person touches content and "what will production look like" has to be answerable without a deploy.

2. Built-in Visual Editor (Storyblok)

Storyblok leads with a Visual Editor that renders your live site inside the editing interface, so a content author edits fields on the left and watches a side-by-side preview update on the right. For teams whose primary buying criterion is "marketers want to see the page while they edit it," this is a genuinely strong out-of-the-box experience, and it is the feature Storyblok is best known for.

Where it shines is speed to a working visual workflow. You point Storyblok at a preview URL, wire up its bridge script, and non-technical editors get inline, click-to-edit previews without a developer building the overlay layer themselves. Component-based "blocks" map cleanly onto page sections, which suits landing-page and campaign work where the shape of a page is fairly predictable.

Where it fits poorly is when content needs to live in more places than a page. Because the visual model is anchored to rendering a preview of a specific site, content that has to feed an app, a kiosk, a voice assistant, and a website equally can feel like it is being authored through the lens of one channel. Draft handling exists, but the mental model centres on the page you are looking at rather than a version of a portable document you can query from anywhere. A concrete example: if your homepage hero and your mobile app onboarding screen share the same promotional copy, a page-canvas-first tool nudges you to duplicate that copy per surface, whereas a query-per-perspective model lets both surfaces read one draft. Storyblok is an excellent fit for visual-first, web-centric teams and a looser fit for genuinely omnichannel content operations.

3. Live Preview with the SDK (Contentful)

Contentful offers Live Preview and inline editing, and for teams already standardised on Contentful it closes much of the gap with visual-first tools. The pitch is that editors can see draft content rendered in a real frontend and, with the inline editing setup, click into fields from within the preview. Contentful genuinely supports live preview; the honest distinction is in how much wiring it takes.

What Contentful does well is fit into an established, API-first delivery model. Its Preview API serves draft content over a separate endpoint, its Live Preview SDK bridges the running frontend back to the editor, and large organisations with existing Contentful investments get a preview story without changing platforms. Where it fits less cleanly: the visual and inline editing experience depends on adding and configuring Contentful's own SDK and preview API, so "preview" is a set of pieces you assemble rather than a single bundled surface. Draft state is also modelled around published-versus-draft entries rather than a query where you name the perspective you want.

A concrete example of the difference: to swap a preview build from published to draft content in Contentful you typically point your frontend at the Preview API with a preview token; in Sanity you change one perspective on the same GROQ query against the same Content Lake. Both get you a draft preview. One is a configuration of endpoints and SDKs; the other is a parameter on the query you already wrote. For an engineering team that wants preview handled through data rather than plumbing, that difference compounds across every route that needs a preview mode.

4. Page-builder preview as the editing surface (Builder.io)

Builder.io takes the most aggressive position on preview: the preview canvas is the editing surface. You compose a page visually, drag components onto it, and what you see is what you are building. For marketing teams that want to assemble and ship landing pages with minimal engineering involvement, this collapses the gap between "editing" and "previewing" almost entirely, because they are the same screen.

Where Builder shines is fast, autonomous page assembly. Non-technical users get real drag-and-drop control over layout, and because editing and preview are unified there is no separate "does the preview match production" anxiety for the pages built this way. That is a real advantage for high-velocity campaign and landing-page work.

Where it fits poorly is anywhere content has to be structured, portable, and reused rather than laid out. When the primary artefact is a visual page, drafts tend to be coupled to that page canvas, which makes it harder to treat the same content as data feeding several channels. A concrete example: a product description authored as a Builder page section is designed to render in that page; the same description modelled as a structured document in Sanity is queried with GROQ and rendered by a website, an app, and a Slack notification from one draft. Builder is an excellent fit when the deliverable genuinely is a page and a strained fit when the deliverable is content that many surfaces consume. The trade you are making is authoring convenience on one canvas versus portability across many.

5. Staging environments and homegrown preview

The default many teams inherit is not a CMS feature at all: it is a staging environment, a duplicated database, or a preview branch that mirrors production. The pitch is intuitive. Copy the system, let editors work in the copy, and promote when it looks right. Plenty of organisations run this way for years.

Where it fits at all is early and small: one content branch, one reviewer, infrequent changes. The failure modes arrive with scale. Staging drifts from production, so "it looked fine in staging" stops being a guarantee. Two editors working the same duplicated database race each other. Promotion is a deploy, which means content changes inherit code-release cadence and risk. And previewing several related changes together means coordinating them across a parallel environment by hand.

The contrast with a native model is the whole argument of this list. In Sanity, drafts, perspectives, and Content Releases live in one source of truth, so preview is a query parameter rather than a parallel deployment, and, per the knowledge base, teams "stage with Content Releases the same way you stage your website" and "preview before you ship" with "drafts, scheduling, history, permission gating, audit trails, the governance you already use for the website." Legacy and homegrown systems bolt preview on as infrastructure; Sanity makes it a property of the content itself. A concrete example: scheduling a coordinated homepage, pricing-page, and banner change for a launch is one Content Release you preview as a set, not three promotions timed across a staging box you hope stays in sync with production.