Content modeling defines the shape content must follow

Pick a field type, name it, and mark it required — the JSON schema updates live.

{
  "id": "headline",
  "type": "text",
  "required": true
}

What is content modeling

Content modeling means defining the structure content will follow before anyone writes it. That covers four questions: what fields exist, what type each one is, what values count as valid, and how entries relate to each other. A blog post might have a title, a slug, a body, and a link to an author, each with its own type and rules. The model gets written once, by whoever owns the schema. Every new entry has to match it.

Without a model, every page becomes a blob of HTML. Nothing stops an editor from skipping a title, or pasting an image where a date belongs. A CMS with no model can store that text but can't tell you it's wrong. So two editors on one team end up with two different shapes for the same content, and nobody notices until a template breaks. Every new editor makes it worse, because there's no shared rule to check work against. Fixing it later means opening every entry by hand.

That is the default state of most of the web. Sites run on a CMS are over 54% of those measured. WordPress runs about 64% of them. Its native unit is a page with one big body field, not a typed entry. (Source: HTTP Archive Web Almanac 2025) Modeling picks the fields before the blob hardens into a habit.

This is also where content mapping and rules start. Once fields and types are set, the same field maps the same way every time, and you can control who edits what and when it goes live. Dates, authors, and categories become typed fields instead of free text. A category stored as a real field can be filtered and searched; a category typed into a paragraph cannot. Teams lean on this daily, because it lets them check content at scale without opening every entry. It changes how content moves between systems, too. A modeled entry moves field by field, every value with a known type on the other end. A loose blob gets parsed and guessed at on each crossing, and each guess is a new place for the data to drift.

How to build a content model, step by step

Seven steps, in order. None of them need a CMS account — the first five are done on paper or in a spreadsheet, and the work holds up whichever platform you end up on.

1. Inventory what already exists. List every page and every recurring block on the current site. You are looking for the shapes that repeat, so a spreadsheet with one row per page beats a whiteboard here.
2. Name the distinct types. Group the inventory until each group is one real-world thing: a post, an author, a product, a landing page. If two groups differ only by layout, they are one type.
3. Break each type into fields, and pick a type per field. A date is a date field, not a string that happens to read like one. This is the step that decides what can be sorted and filtered later.
4. Define validation per field. For each field, write down what would make a value wrong: empty, too long, not a URL, out of range. That sentence is the validation rule.
5. Map the relationships. Wherever one type mentions another, that is a reference, not pasted text. Decide whether each reference holds one entry or several.
6. Decide what is localized and what is global. A price and a slug usually differ per locale. An internal name usually doesn't. Getting this wrong is expensive to undo after translation starts.
7. Review with the people who fill the form, then write the schema. Walk an editor through creating one entry against the model on paper. Every question they ask is a missing help text or a missing field. Only then build the template.

Steps 1 and 2 take the longest and get skipped the most. A model built straight from the current page templates inherits the layout of a site you're about to replace.

Content modeling best practices

Seven rules that hold up across projects. Most of them cost nothing on day one and save a migration later.

Four of these map to real settings rather than good intentions: validation and help text are per-field options on a Draftbase template, references are a field type, and every save keeps a revision, so a model change is reversible. The other three are judgment. No schema editor can stop you from naming a field after a sidebar.

A worked example: modeling a blog and its authors

Two templates, because a blog post and the person who wrote it are two different things. What a content type is covers the definition; this is what one looks like filled in.

Template 1: blogPost

Template 2: author

The interesting field is author. It is a reference, so a post points at an author entry instead of storing the name as text. That single choice is what makes the model relational. The author's name, bio, and avatar live in one entry, and every post rendering a byline reads that same entry.

Now the wrong version. Put all of it in one richText field: title, byline, bio, and body in a single blob per post. Three things become impossible. You can't list every post by one author, because there's no author field to filter on. You can't reuse the bio, because it's pasted into each post separately. And you can't rename an author once — a name change means opening every post they wrote and editing prose by hand. The blob stores the same words. It just can't answer any question about them.

How Draftbase implements content modeling

Draftbase turns the four parts of a content model into real settings on a template. Fields, types, rules, and links between entries. This isn't a doc someone has to maintain by hand. Each piece maps to a control in the schema editor. A field is done once its type, its rules, and its default value are set. There's no second system to keep in sync. The schema is the source of truth for what an entry can hold.

Prototyping a schema by hand first? Try the free JSON to TypeScript converter or the slug generator for a field that has to match Draftbase's own slug pattern.

Text fields carry the most options. A field can be marked as a slug, locked to a fixed set of values shown as a dropdown, or checked against a pattern with a custom error message. Number fields take min and max bounds. Any field can carry a default value and help text, so a new entry starts pre-filled and an editor sees why a field exists without asking on Slack. Fields can also be marked localized: each language gets its own value under one schema, with no separate template per locale.

None of this needs a plugin or a third-party layer, and none of it is optional depending on how an entry arrives. The same rules apply whether the entry comes from the dashboard, the MCP server, or the API. Permissions sit on that same schema — who can edit a template, who can publish an entry — rather than in a second system someone reconciles by hand.

Content modeling vs. unstructured content

The gap between structured and unstructured content shows up in four places. Do values get checked? Can entries safely link to each other? Do changes leave a trail? Can content be reused elsewhere? Generic headless CMS platforms close part of that gap. Draftbase closes the rest, with revision history built into the schema itself. Tracking changes isn't a bolted-on feature here. It's part of the model. The table below lines up all three approaches on those same four points.

Multi-channel reuse looks the same for a generic headless schema and for Draftbase. Both expose an API. Call that row a wash. The other three rows are where skipping content modeling costs you. That usually shows up as a broken link. Or an edit nobody can trace, found weeks later. A reference field that points at a deleted entry is a bug. You can find it and fix it. A hardcoded ID pointing at that same deleted entry is a bug too. Nobody notices, until a page breaks.

Why content modeling matters more as teams scale

Manual content work slows teams down as they grow. 47% of teams call slow, manual content work their biggest problem. (Source) That's from a Content Science survey, cited in Storyblok's 2025 CMS report. A defined model removes that manual step. Checks and structure run once, in the schema. Not by hand on every entry. A small team can get by on shared habits about how content should look. A larger team, with editors across time zones, can't. Rules about who publishes what tend to show up as a team grows too. A model with draft and publish states, plus a change log, meets that need. No separate tool bolted on later.

The payoff shows up in dollars, not only in hours saved. 86% of headless CMS users in a Netherlands survey said they saw more return after the switch. (Source) That return tends to add up. A well-built template gets reused on every new channel a team adds. A loose blob has to be rewritten each time. The upfront cost of modeling content is small and fixed. Skipping it costs more. More editors, more channels, more entries added on top of a loose structure.