Headless CMS Preview: Keep Drafts Away From Public Pages

Treat preview as a restricted editorial journey

A headless CMS separates content storage from the website that renders it. Editors still need to inspect a draft in its real layout before publication. That preview is a distinct access path, not simply a public URL with a query value saying draft. Define who can enter it, which draft records they can inspect and how they leave it. This guide concerns unpublished-content access and publishing QA. The rendering guide explains static and request-time choices, while islands architecture explains selective interaction; neither supplies preview authorisation automatically.

Write the difference between save, preview, approve and publish in the editorial process. A saved draft should not become public merely because a renderer can retrieve it. Conversely, a published edit should have a known path to the live site. Identify which action changes the public version and which system performs that change. This prevents editors from interpreting a successful preview as evidence that customers see the same content or assuming that publication happened when a build failed.

Validate entry and avoid client credential exposure

Framework preview mechanisms, such as Next.js Draft Mode, offer a way to render draft-aware content, but the entry route needs appropriate validation. Follow the current framework and CMS documentation for the actual setup. Do not distribute a privileged CMS token in browser code or accept arbitrary content identifiers without checking access. A preview link should enter a controlled journey, not provide open read access to the entire draft repository. Decide whether and how a reviewer can share access with another authorised person.

If a callback uses a destination from a query, validate it against the intended routes rather than redirecting to any supplied address. Keep server-held credentials appropriately scoped. Review logs and analytics because preview URLs or responses can contain unpublished information. A visual label reading Preview helps editors orient themselves, but it is not an access control. Test the route from a logged-out session and without the expected authorisation context. The public site should not retrieve the draft simply because a guessed parameter is present.

Keep draft responses out of shared public caching

Draft rendering and the public cache need a deliberate boundary. An editor opening unpublished copy must not cause that response to be served to normal visitors. Review application and edge behaviour together, including cookies and response headers. Do not assume that the presence of a preview cookie automatically makes every intermediary response private. Document the public request path and preview request path separately. If the platform requires a cache bypass or distinct response policy, implement and verify it through the actual hosting arrangement.

Worked example: the correct preview, wrong public response

Imagine an editor opens a new service draft and confirms the layout. A shared cache then stores the preview response under the ordinary public path. The next anonymous visitor sees unpublished claims. Investigate the preview access and cache key rather than removing only the visible Preview badge. Separate the response policy and purge the affected public entry according to the platform process. Then test an editor session and a clean anonymous session in both orders. This hypothetical case demonstrates why draft functionality and cache isolation must be reviewed together.

Check publication and preview exit

After approval, test the real publish path from CMS action to deployed or refreshed public output. Confirm the archive, related links and metadata use the published record. If publication fails, show or record a meaningful state so staff do not assume the page is live. Test exit from preview and opening another page; draft context should not linger unpredictably. Keep unsupported draft fields from breaking the whole preview with no understandable feedback.

Maintain representative tests for an unauthorised request, an authorised draft, a missing draft and a published update. Revisit the boundaries when CMS or framework versions change. Keep indexing controls and access protection distinct: a noindex instruction can influence search appearance, but it does not protect unpublished content from access. A reliable preview workflow lets editors inspect real layouts while keeping the public site accurate and drafts limited to their intended reviewers.

Test a reviewer opening a shared preview link after their access has been removed. The response should follow the intended authorisation policy, not continue exposing content because the link remains memorable. Include that state in preview QA when the project supports temporary reviewer access or externally shared approval journeys.

Practical checklist

• Separate save, preview and publish states.
• Validate preview entry and destinations.
• Keep privileged CMS tokens off the client.
• Test editor and anonymous requests in both orders.

Frequently asked questions

Related Articles