Editorial Workflow in Headless WordPress: Preview and Drafts

Headless WordPress preview works when the Preview button in WordPress opens the real front end in a draft state, authenticated, uncached and clearly labelled, so editors see exactly what will go live. Add reliable scheduled publishing and a simple approval path, and most editor complaints about headless disappear. Leave any of the three to chance and editors quickly lose trust in the new site.

This guide covers the editorial side of a headless build: what breaks, why, and how to fix it. For the technical foundation, see our headless WordPress with Next.js reference architecture.

Why editors struggle after a headless launch

In traditional WordPress, the theme and the editor live in the same system. Preview, scheduling and publishing all just work. Headless splits the system in two, and every feature that crossed the boundary has to be rebuilt deliberately.

How headless WordPress preview should work

The goal is simple: an editor clicks Preview and sees the draft on the real front end, with the real design, in a new tab. Behind that click, four things happen.

1. WordPress builds a preview link to the front end. A small plugin or filter replaces the default preview URL with a link to a secured preview route on the Next.js site, passing a shared secret and the post ID.
2. The front end validates and switches mode. The route checks the secret, confirms the post exists, enables draft mode and redirects to the page. The Next.js Draft Mode documentation describes this pattern: a cookie that makes that editor's requests bypass cached and prerendered content, while normal visitors keep seeing the cached page.
3. The front end fetches the draft with credentials. Unpublished content is not public, so the server side fetch must authenticate against WordPress.
4. The page shows that it is a preview. A visible banner and an exit control stop editors confusing a preview with the live site, and stop preview links being shared by accident.

Draft preview in Next.js with WPGraphQL

If the front end reads content through WPGraphQL, its preview documentation explains the current approach. A preview applies only when the request is authenticated, the user can edit the post, and the preview context matches the post being resolved. If any check fails, the request quietly returns published content with no error, which is the most common reason a preview "shows the old version". The docs also note that previews overlay fields from the latest autosave, and that preview responses are marked as not cacheable.

Draft preview with the REST API

With the WordPress REST API, the front end requests the post or its latest revision using an authenticated server side call, often with an Application Password belonging to a read only preview account. Never expose those credentials in the browser.

Preview checklist

• Preview opens the front end domain, not the WordPress domain
• New, never published posts preview correctly, not only edits to live posts
• Custom fields and blocks appear in preview, not only title and body
• Both language versions preview correctly, including right to left layout for Arabic
• The preview banner is visible, and exiting returns the editor to the live page
• Preview pages are excluded from search engines and from any shared cache

Drafts, revisions and the editorial workflow

WordPress has a built in set of post statuses that form a basic editorial workflow. The WordPress post status documentation lists them, including draft, pending (awaiting a user who can publish), future (scheduled) and publish. Users who can edit but not publish see "Submit for Review" instead of "Publish", which sets the post to pending.

Map statuses to people

Before adding plugins, write down who does what. A typical content team in a UAE company might look like this:

Our guide to WordPress admin roles, approvals and MFA covers permissions in more depth.

Content approval for regulated sectors

Healthcare, financial services and education often need a documented sign off before publishing. If the built in pending status is not enough, add custom statuses (for example "legal review") with an editorial workflow plugin, and keep a record of who approved what and when. Confirm with your compliance team what evidence the relevant regulator expects; the CMS should support that process, not define it.

Hypothetical example: an Abu Dhabi clinic group drafts a new treatment page in English and Arabic. The writer submits both for review, a clinical reviewer checks the medical wording in preview, and the marketing lead schedules the pair to go live together. Each step is visible in the post history, and the preview link shows the real page design throughout.

Scheduled publishing that actually fires on time

Scheduled publishing is the quiet failure of many headless sites. Two separate problems combine.

Problem one: WP Cron depends on traffic

The WordPress cron documentation explains that WP Cron is triggered on page load, so a task set for 2pm may not run until someone loads a page later. In a headless build, almost nobody loads WordPress pages: visitors go to the Next.js front end. Scheduled posts can therefore stay in the future status long after their time.

Fix: disable the page load trigger and call WordPress cron from a server scheduler or your hosting platform's scheduled task feature at a short, regular interval.

Problem two: the front end does not know the post went live

Even when WordPress publishes on time, the front end may keep serving a cached page. The publish event must trigger the same revalidation webhook that a manual publish uses, so listing pages, the home page and the new post itself refresh together.

Test the full chain

• Schedule a test post a few minutes ahead in staging
• Confirm the status changes on time without anyone visiting WordPress
• Confirm the post, its category page and the home page update on the front end
• Check the webhook log for the revalidation call

When the editorial workflow spans more than one channel

If the same content feeds a website, a mobile app or in store screens, preview has to answer "what will this look like on each channel?" Most teams start with web preview and add channel previews only where layout differs enough to matter. Our comparison of WordPress and Strapi for multi channel content covers how the CMS choice affects this.

And if preview, scheduling and approvals already feel like a lot of engineering for your team, it is worth reading when headless is overkill before committing further.

Fix the editor experience with Codeeo

Codeeo builds and supports headless WordPress sites, including the preview, scheduling and approval flows that editors rely on day to day. With a team of 80+ across Dubai, Riyadh and Karachi and 200+ projects delivered across the UAE and the US, we can review an existing build or plan a new one, and UAE clients can meet us at our Dubai office. Explore our WordPress development and Next.js development services, or start with a website audit.

Tell us what your editors find frustrating today, and contact our team to talk through the fixes.