What is CMS live preview?
CMS live preview is a view of the actual website page, rendered with draft content, shown next to the editing form so editors see changes before they publish. In a traditional CMS this comes built in. In a headless CMS the site is a separate front end, so preview has to be wired up on purpose.
That's why missing preview is the most common complaint editors have about headless setups. Without it, they type into fields, publish, check the live site and fix what broke. Preview is part of any good CMS setup for a marketing website, and it does more for editor confidence than any other single feature.
What's the difference between draft preview, live preview and visual editing?
They're three levels of the same idea. Draft preview opens the page with unpublished content after you save. Live preview updates that page as you type. Visual editing adds overlays on the page so you can click any heading or image and jump to the field that controls it.
Level | What editors get | Build effort | Good for |
|---|---|---|---|
Draft preview | A Preview button that opens the saved draft | Low | Every headless site |
Live preview | A side-by-side pane that updates while typing | Medium | Teams editing landing pages often |
Visual editing | Click on the page to edit that field | Higher | Large sites with many editors and blocks |
Most CMSs now support all three in some form. Payload has a Live Preview feature for an iframe pane, Sanity offers a Presentation tool with click-to-edit overlays, and Contentful has live preview and inspector tooling. The details differ, so read your CMS's current docs before you plan the work.
How do you add draft preview mode in Next.js?
In Next.js you add draft preview with Draft Mode: a route the CMS calls with a secret turns on a cookie, and while it's on, pages fetch draft content and skip the cache. The steps below follow the Next.js documentation pattern and work with any headless CMS.
Create a preview route
Add an API route that checks a secret token and the requested slug, enables Draft Mode, and redirects to that page. Reject requests with the wrong secret.
Point the CMS at it
Set the CMS preview URL to that route, passing the document's slug and the secret. Editors now see a Preview button on each entry.
Fetch drafts when Draft Mode is on
In your data functions, check whether Draft Mode is enabled. If it is, request draft or latest versions from the CMS instead of published ones.
Skip the cache for drafts
Draft requests must not be cached or stored in your static pages. Next.js renders draft mode requests dynamically, but check any custom caching layer too.
Add an exit link
Show a small banner while in preview, with a link to a route that disables Draft Mode, so editors know what they're looking at.
Keep preview out of search
Add a noindex header to preview responses and never link to preview URLs from public pages.
How do you add live preview and visual editing to a headless CMS?
Live preview adds a pane inside the CMS that loads your preview page in an iframe and sends it new content as the editor types. The page listens for those messages and re-renders, usually through a small client component or a hook the CMS provides.
- Allow the CMS to frame your site. Your content security policy must permit the CMS origin to embed preview pages.
- Listen for updates on preview only. Load the live preview script only in Draft Mode so public pages don't ship extra code.
- Handle relationships. When an editor changes a linked testimonial or author, the pane should refresh that data too.
- Match breakpoints. Let editors switch the pane between desktop and mobile widths, since most layout breaks happen on mobile.
Visual editing goes one step further. The front end tags each rendered field with information about where it came from, and the CMS draws clickable outlines over the page. It's worth it for teams with many page builder blocks, where finding the right field in a long form is the slow part.
How is CMS preview different from preview deployments?
CMS preview shows content changes on the current code. Preview deployments show code changes, such as a new block or a redesigned section, on a temporary URL before they reach production. You want both: editors use CMS preview daily, and developers use preview deployments for every pull request.
Example: how preview works on a Payload site
On our own Payload site, every blog post and project has a preview link that opens the real page for that slug, and blog posts stay drafts until published. Only published posts reach the site and the sitemap.
For a team that edits landing pages daily, we'd add Payload's Live Preview pane on top, so editors see the page update while they type. The full setup is in our article on Payload CMS for marketing sites.
How do you test that preview works?
Test preview the way editors will use it: with real content, on mobile widths, signed in with an editor account rather than an admin one. A preview that only works for developers isn't done.
- Change a headline in a draft and confirm the preview shows it while the live page doesn't.
- Edit your longest page, with the most blocks, and check the pane stays responsive.
- Change a related item, like an author or testimonial, and confirm the page updates.
- Open a preview URL in a private window without the secret and confirm it's refused.
- Check the response headers include noindex and no caching.
If editors still hesitate after preview works, the problem is usually elsewhere: confusing fields, or a role that shows them too much. Our guides on why marketing teams can't edit the website and CMS roles and permissions cover those fixes.
