Plan headless WordPress as a publishing workflow that connects content records, frontend rendering and authorised preview. Agree how an editor’s change reaches the public page, how drafts remain controlled and which team maintains each layer. The REST API supplies content data; the project still needs an explicit route from editorial intent to delivered page.
Begin with a representative article and follow it through creation, preview, publication and correction. Ask the editor which parts they expect to control, and ask the frontend owner where those changes appear. A content model is most useful when both people can explain the same journey without relying on a developer to interpret every update.
Which content identity should the frontend retain?
The WordPress posts reference describes the record structure. A post has an identifier unique to its record. The post slug is an alphanumeric identifier unique to its type. Keep the record identity and public routing decision distinct in the integration design so a proposed URL change can be reviewed deliberately.
Write a mapping for the title, body, summary and any other field the public template uses. Record which fields belong to the editor and which presentation rules belong to the frontend. A custom layout may need more than the standard post record, so identify additional requirements explicitly and request their schema before treating them as available data.
The post schema distinguishes site-timezone publication dates from GMT dates. Record which value the frontend consumes and how the displayed date is intended to read. Include a sample with an explicit timezone in the acceptance discussion so publication timing does not depend on an unstated assumption by the integration team.
A post can have published, future, draft, pending or private status. Agree the intended treatment of each relevant state. Keep scheduled content and draft preview in the journey map rather than designing only for an already published article. The public route and editorial preview should each have a clear purpose.
The post-list context determines which response fields are present. Inspect the actual request context and returned record during implementation. A field visible to an editor should not automatically be assumed present in a public response or suitable for displaying to every visitor.
How should authentication and preview be designed?
WordPress’s authentication documentation supplies important boundaries. Cookie authentication is WordPress’s standard authentication method. WordPress REST nonces help prevent cross-site request forgery. Identify the authentication route appropriate to the actual integration rather than copying a dashboard example into a separately hosted frontend without review.
Without a nonce, the cookie-authenticated REST request becomes unauthenticated. Cookie authentication applies inside WordPress with a logged-in current user. The current user also needs the capability required for the action. These conditions belong together when assessing a preview workflow: logging into the editor is not the complete specification for another application’s access.
Ask the developer to show the proposed preview route for the intended editorial role and explain where authorisation is checked. Record how a preview request identifies the content and how the frontend obtains the permitted version. Treat sharing a preview with another person as a separately defined requirement with its own access decision.
Keep credentials and private content out of public client assets and shared acceptance records. Have the technical owner document the secret-handling route in the appropriate private operational material. The editor’s handover should explain how to preview safely in normal use without exposing implementation secrets.
| Workflow point | Requirement to agree | Evidence to inspect |
|---|---|---|
| Content retrieval | Frontend maps the intended record and fields | Request context and returned sample record |
| Draft preview | Intended editor can inspect the unpublished version | Authorised preview route and visible revision |
| Public publication | Approved content reaches its public destination | Delivered body and metadata at that URL |
| Later correction | Revised content replaces the intended version | Content source and delivered page agree |
| Slug change | Routing behaviour is deliberate | Old and new destinations behave as specified |
Use the table to assign responsibility as well as to collect observations. Editorial ownership, API integration and frontend delivery may be handled by different people. Each needs to know where to investigate a mismatch and who decides whether the result meets the publishing requirement.
What should happen after an editor saves a change?
Choose a delivery method and document its update path. Ask the frontend owner to explain what causes content to be fetched or rebuilt and how a change becomes visible at the public URL. Record any cache or deployment dependency that affects that path. Avoid promising an update interval until the actual arrangement has been measured and agreed.
Keep a content correction distinguishable from a frontend release. If updating an article requires a build, the owner needs a reliable way to initiate and inspect it. If content is retrieved at request time, the owner still needs to know how failures and stale responses are handled. The suitable design depends on the product’s operational needs.
Inspect the delivered article as a document. Check the body, title, intended links and other required metadata in the output the publishing route returns. An API response containing the correct body and a frontend displaying an obsolete version are different observations. Retain both when tracing a delivery problem.
Also define the editorial recovery route. Ask how a mistaken change can be reviewed and corrected through the actual content and delivery layers. Name the person who can assess the record and the person who can assess its public rendering. An escalation route becomes clearer when the evidence includes the relevant content reference and page URL.
Original draft-to-publication diagnostic
Use a fictional article called Preparing a Project Brief in a separate test environment. Prepare sample text, a proposed public URL and an authorised editorial account. The exercise follows a distinctive sentence through draft preview, publication and correction, making the content version visible at each stage.
First, record the article identity and intended fields. Save the sample as a draft and ask the editor to open the agreed preview route. Check that the distinctive sentence belongs to the intended version, then inspect the public destination according to the project’s unpublished-content requirement. Retain the observed behaviour and access context.
Next, publish through the approved test workflow. Inspect the source record and delivered page together. Record what triggered the update and any step the editor needed to take. A result that depends on an undocumented manual intervention should become an open handover item rather than an invisible operational habit.
Finally, correct the distinctive sentence and repeat the delivery inspection. Have the editor and frontend owner explain the path using the retained evidence. Mark unresolved field mappings, preview permissions and update dependencies explicitly before applying the design to the wider content inventory.
For broader requirements, see WordPress and website development. Get started with your content map and the editorial journey the integration must support.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.