Headless CMS: Define the Editorial Workflow Before You Build

Before approving a headless CMS build, define how editors will create, preview, approve, publish, and correct content. Ask for a working demonstration of those tasks using your own page types. A flexible content API is useful, but the project is not ready for handover until the people maintaining the website can complete their everyday work.

For design agencies, this is a scoping problem worth resolving before quoting. A polished front end can hide an unfinished editing experience. The brief below turns “the client can update the website” into specific behavior your designer, developer, and client can review together.

What headless means for the person editing the site

In a headless setup, the content management system stores and manages content while a separate application presents it to visitors. That separation can support different websites or applications using shared content. It also creates a connection the project team must design and maintain.

WordPress can serve content to separate applications through its REST API; headless does not necessarily mean replacing WordPress. Its REST API handbook explains both this capability and why an existing site does not need to adopt the API simply because it is available.

For the editor, the useful question is concrete: after changing a record in the CMS, where can I see the result, who approves it, and when will visitors see it? Answer that before choosing the implementation around a framework preference.

Start with three real publishing tasks

Our recommendation is to scope the editing experience with representative tasks, rather than a list of screen designs alone. Include one routine update, one new page, and one coordinated change.

For a fictional museum, those could be correcting opening hours, creating an exhibition, and announcing a seasonal program across several pages. For a service business, use a staff update, a new service page, and a campaign launch. These are planning examples, not client results.

Write down the starting content, the editor's role, the steps, and the visible outcome. Include the less convenient conditions: a long title, a missing translation, an image with a different crop, and an exhibition without a booking link. They reveal whether the system helps editors or forces them to work around its assumptions.

Separate reusable content from page layout

Decide which information should have a single source. An exhibition might have a title, dates, venue, description, image credit, and booking URL. The same record could appear on its detail page, the homepage, and a listing. A date correction should not require finding three unrelated text boxes.

Then decide where editors need layout choices. A controlled set of sections can give a marketing team flexibility while keeping typography and spacing consistent. Unlimited layout control is a different scope from editing fields inside approved templates.

Our suggested review questions are:

• Which records are reused, and which fields are required?
• Can editors reorder sections or create new combinations?
• What happens when a referenced record is unpublished or deleted?
• Who can change navigation, page addresses, and shared settings?
• Which changes require development rather than a content edit?

Use a small content model and a working example to settle these questions. A diagram alone will not reveal whether an editor understands a field label or knows which image will appear in a listing.

Make preview a deliverable

A CMS form showing a saved draft is not the same as previewing the finished website. Ask to see an unpublished page in the actual design, at desktop and mobile widths, with its related content and navigation working as intended.

Next.js, for example, provides Draft Mode for previewing unpublished content. Its Draft Mode guide describes integrating a CMS preview URL with a protected route and displaying draft content. That is a capability developers configure, not evidence that every Next.js website already includes a complete preview workflow.

For your acceptance brief, specify who can open a preview, whether someone outside the CMS can review it, and how that access ends. Distinguish a preview of one page from a preview of a whole future release. Ask the team to make the preview state obvious so a reviewer does not mistake a draft for the public site.

A useful demonstration changes an existing page and creates a new one. Both should be reviewable before publication. Also verify that ordinary visitors cannot retrieve unpublished content through the public site or its exposed data requests.

Define what the Publish button actually does

Publishing in the CMS and refreshing the public website are separate steps in some architectures. Agree on how a content change reaches the live pages, how long that normally takes, and how the editor learns that an update failed. Avoid leaving “it will rebuild” as the entire operating explanation.

Coordinated releases need their own scope. Some systems support grouping and scheduling document changes; Sanity's Content Releases documentation provides one example. Availability depends on the product and plan, so verify the required features before putting them in a proposal.

Our recommended acceptance scenario is a scheduled announcement with a new page and a homepage reference to it. Confirm the intended time zone, preview both changes, publish them, and inspect the public result. Then test how the team would correct a wrong date or withdraw the announcement. A CMS feature does not, by itself, prove that every connected website has refreshed successfully.

Give approvals and corrections named owners

Decide who can save a draft, approve a change, publish it, and alter the content structure. A small team may combine roles. A larger institution may need a review step between an editor and a publisher. The important point is to agree on the real process instead of creating permissions that nobody uses.

Include a correction path. If an editor publishes the wrong image, can they restore a previous content version? If a developer changes a template, is that a separate release? Document the difference so the client does not expect a content undo button to reverse a code deployment.

For multilingual content, agree on what happens when one language is ready and another is not. Show the fallback behavior to the client. “Multilingual support” is too broad to settle whether a missing translation should hide a page, show another language, or block publication.

Price the workflow and handover explicitly

The estimate should identify content modeling, editor configuration, preview integration, publishing behavior, permissions, and training alongside the visible website. List any subscriptions or usage limits that affect the proposed arrangement, and name the owner of each account.

At handover, ask an editor to complete the original three tasks without the developer driving. Record any missing steps, confusing labels, or dependencies on support. Deliver instructions for routine publishing and a clear reporting path for failures.

This is separate from the ongoing maintenance agreement. Our maintenance planning guide covers continuing support responsibilities. If existing page addresses will change, use a separate URL migration plan rather than hiding that work inside CMS configuration.

Frequently asked questions

Does a headless CMS mean the client needs a developer for every edit?

No. Routine editing can be designed for the client's team. The boundary depends on the content model and the controls included in the project. Ask which changes editors can make independently and demonstrate them before approval.

Can we keep WordPress as the editing system?

Yes, WordPress can provide content through its API to a separate front end. Existing themes and plugins still need individual review: do not assume their visitor-facing features automatically appear in a different application. Scope the behavior your site actually uses.

Is headless automatically faster or better for SEO?

No architecture label establishes those results. Judge the delivered pages and the implementation. Performance testing remains a separate task; our PageSpeed guide explains what to measure.

Should we go headless for a small brochure website?

Start with the requirements. If the current editing and publishing setup meets them, separation may add responsibility without a useful benefit. Ask the developer to explain which specific requirement justifies it and what the client will operate after launch.

What should an agency send before requesting an estimate?

Send the proposed page types, representative content, editor roles, preview and approval needs, and any applications sharing the content. Include the existing platform and integrations. ROAR can work through those requirements with your team and define a development scope; see how we work with agencies or send us your brief.