What is a content model? A plain-English guide
What is a content model? The list of things a site contains and the fields each one has. A plain-English guide, with the decisions that matter on day one.
Every website project has a content model. Most of them are never written down. They live in the developer's head, in the shape of a page builder, or in whatever a theme happened to ship with, and they surface six months later as a client asking why they can't add a second location.
So, plainly: what is a content model? It's the list of things a site contains, and the fields each of those things has. That's all. The value is in writing it down before you build, because every decision in it is cheap on day one and expensive on day ninety.
A restaurant, as an example
Take a small restaurant group with two sites. List what the website actually holds, not the pages it has.
There are menu items: a name, a description, a price, dietary flags, a photo. There are locations: an address, opening hours, a phone number, a booking link, a map pin. There are pages: Home, About, Private dining, Contact. And there are repeating sections that appear on those pages: a hero banner, a block of opening hours, a gallery, a call to action.
Each of those is a type. Each type has fields. That list, with the field names and what kind of value each one holds, is the content model. A menu item's price is a number, not a sentence. A location's opening hours are structured, not a paragraph someone retypes. Small choices, and every one of them shapes what the client can and can't do later.
The four building blocks
Almost every structured content tool reduces to four ideas, whatever it calls them.
A field is one unit of data: a title, a price, a date, an image.
A document is a group of fields with its own identity. A menu item is a document. So is a location. You can list them, link to them and query them.
A section (some tools call it a block, a component or a stack) is a reusable group of fields with no identity of its own. A hero banner lives inside a page; it doesn't exist anywhere else.
A reference is a link from one document to another. A menu item belongs to a location. A blog post has an author.
If you want the longer version of why references deserve to be first-class, rather than a field that holds a name, read why our content model is a graph, not a table. For the short version: a reference that is a real link can be followed in both directions and can't drift out of sync with the thing it points at.
The one question to ask of every type
When you're unsure whether something is a document or a section, ask: does this need its own identity?
Would anyone want to list all of them? Link to one from somewhere else? Show it on two different pages and edit it once? If yes, it's a document. A staff member who appears on the About page and on their own profile page is a document. A testimonial that appears only inside one page's slider can be a section, until the client asks for a testimonials page, at which point it should have been a document all along.
That last case is the common one. When in doubt, give it an identity. It's much easier to show a document in one place than to rescue twenty copies of the same quote from twenty pages.
The mistakes that cost the most
One page type with fourteen optional fields. The generic page that grew a field for every special case: an optional map, an optional price, an optional "show the booking widget" switch. The editor becomes a long form where most fields don't apply, and nobody can tell which ones matter. If a page has different fields, it's probably a different type.
Modelling layout as content. Fields called "column count", "left image width" or "background colour of section three". These aren't content, they're design decisions, and once they're in the model the client can change them. Model what the thing is, not how it looks. The theme decides how it looks. We make the longer argument in structured content, not page layouts.
Free text where a reference belongs. A blog post with an "author name" text field instead of a link to an author. It works until the author changes their surname, or you want an author page, or someone types it three different ways. Anything that is a real thing in the world deserves to be a document, linked by reference.
Fields named after where they appear. "Homepage intro" is a field that can only ever be on the homepage. "Summary" can be used anywhere. Name fields after what they hold.
Who owns the model
The model is structure, and structure belongs to whoever builds the site. Content belongs to the client. Keeping those two apart is most of what makes a site survive its first year.
In practice that means the client can add a menu item, change a price and write a post, but can't add a field, delete a type or change what a section contains. A request to change the model is a change to the build, and it gets quoted like one. How to split those permissions in practice is in client roles and permissions.
How Contentive treats the model
In Contentive the model is the first thing you build, and everything else is generated from it. You define content types, fields, reusable sections (we call them stacks) and references; the client's editor is built from that definition, so a menu item's form shows a menu item's fields and nothing more. Pages are composed as an ordered list of sections, and changing the model is a separate permission from editing content. The model is also what the GraphQL API is generated from, so a developer building a bespoke front end reads the same definition.
That's an aside, though. Everything above holds whatever tool you use.
What it costs to do this properly
It costs an afternoon before the build starts, and it costs you the comfort of finding out as you go. It also forces decisions the client may not be ready to make: is a "service" a page or a type? Do events have locations? You'll get some of it wrong and change it later. That's fine. Changing a written-down model is a conversation. Changing an unwritten one is an archaeology project.
Do this before the next build
Before you open any tool on the next project, take one sheet of paper. Write every type down the left. Next to each, list its fields and the kind of value each one holds. Draw a line for every reference. Mark which things are sections rather than documents.
If it doesn't fit on one sheet, the site is more complicated than the quote assumes, and that's worth knowing now. If it does, you have the start of your scope document, which is where scoping a website project picks up.