How to Model Content for Headless WordPress Without Rework

Before any field list is drafted, the model needs its business objects. These are the things that would still exist if WordPress disappeared tomorrow: a product, event, person, location, episode, policy, or campaign. Fields come later.

An easy test is to ask what can change, be owned, be reused, or be published independently. If it has its own lifecycle, it is usually an entity. If it only describes one entity, it is an attribute. If it connects two entities, it is a relationship.

• Entity: has identity, history, permissions, or its own URL
• Attribute: title, SKU, publish date, hero image, summary
• Relationship: author of article, speaker at event, product in collection

Relationships deserve more respect than teams often give them. “Speaker at event” may need role, order, time slot, or status. That is not a stray field on either side; it is relationship data.

Keep one authority unless duplication is deliberate

A single source of truth should hold values that must stay correct everywhere: pricing on the product, bio on the person, venue details on the location. Duplicate only when there is a clear payoff, such as faster card rendering, immutable historical snapshots, or simpler editorial workflows.

When duplication is allowed, the authority and refresh rule should be explicit. If the copied value can drift, the model is incomplete.

A simple rule helps: store data in the most structured place that supports its future queries and rules.

• Use a post type when the thing has its own URL, status, authoring workflow, revisions, permissions, or relationships.
• Use a taxonomy when many items share the same controlled label set and those labels must be filterable, countable, and reusable.
• Use meta/ACF fields for attributes of one item: price, duration, hero image, launch date.
• Use an options page only for global settings with no independent lifecycle, such as a support email or default CTA.

What to ask before choosing

If editors will ask “show all items where X” or APIs will filter, sort, or aggregate by a value, that value must be queryable. Taxonomies and well-typed meta support this; serialized arrays, JSON blobs, and repeater substructures often do not.

If a value needs validation, model it explicitly. Dates should be dates, references should be references, and finite choices should use enums or controlled terms. Free-text fields invite drift.

Where teams get trapped

The expensive shortcut is hiding relationships inside blobs: IDs in text fields, labels in repeaters, JSON in meta. It looks fast, then blocks joins, weakens validation, complicates migrations, and forces application code to reconstruct meaning that the model should have expressed.

A field leaks presentation when its name describes where it appears or how it looks instead of what it means. Hero title, left column copy, and CTA color are warning signs: they bind content to one template and force remodelling when layouts change.

Prefer small, semantic fields that can travel across channels:

• headline instead of homepage heading
• summary instead of card text
• image plus alt_text instead of desktop banner
• link_label and link_url instead of one pasted HTML button

Keep the raw source value whenever formatting may change later. Store a date as ISO 8601, a price as amount plus currency, and an address as separate parts if filtering, mapping, or localization may matter. Render-friendly strings can be derived downstream.

Constrain values wherever the business rules are known. Use enums for status, booleans for flags, integers for sort order, and validated URLs instead of free text. Every constraint removes ambiguity, reduces editorial drift, and makes API consumers safer to build.

Page builders solve assembly. They control order, emphasis, and layout at the page edge; they should not become the system of record. A landing page may include a speaker card block, but the speaker’s bio, image, and links usually belong to a speaker entity that can power event pages, search, and feeds. The same discipline matters when handling Gutenberg blocks without rework.

Use a block as a standalone unit only when the content is local, short-lived, and unlikely to need independent governance:

• campaign hero copy
• one-off legal notes
• temporary promotional panels

Reference a canonical entity when the same fact must stay consistent across pages, appear in APIs, carry workflow, or be queried directly. Common examples include people, products, locations, FAQs, and reviews.

The real risk is a block tree that hides business data inside nested JSON. Once facts live only there, validation, search, deduplication, and migration become expensive. Keep blocks thin: composition, local overrides, and references.

Before bulk entry starts, seed the model with a small but awkward set of records: empty values, multiple relationships, scheduled changes, translations, and one item reused in several contexts.

Inspect the actual REST or GraphQL payloads, not the editor screen. Confirm field names, null handling, relationship shapes, ordering, and whether consumers can use the data as delivered without parsing prose or stitching together ad hoc fragments.

Run the same sample content through at least three outputs: a page, a card/listing, and a feed or app view. If any channel needs one-off mapping logic, the schema still contains presentation debt.