What it is, and what it is not
A content model is the answer to two questions. What kinds of thing exist on this site, and what does each of them consist of? A service has a name, a summary, a list of what is included and a slug. A case study has a client, a date, a result and a set of images. A location page has a city, a country and a statement of whether anybody is actually based there.
It is not the CMS. WordPress, Sanity, Contentful, Payload and a folder of typed files are all tools that can hold a model, well or badly. Choosing the tool is a procurement decision that takes an afternoon. Choosing the model is a design decision that takes an hour and then constrains everything for years, and only one of those two usually gets a meeting.
The reliable way to tell them apart: if the answer changes when you switch platforms, it was a tool decision. If it survives the switch, it was the model. A good model is portable by construction, which is also why it is the part that protects you from lock-in.
The default, and why it always wins at first
Left alone, almost every site converges on the same model: a page has a title and one large field containing everything else. It is the fastest thing to build, the most flexible thing to edit, and it is what page builders produce whether or not anybody chose it.
It works. That is the important part, and the reason arguing against it feels pedantic for about a year. Then somebody asks for a page listing every service with its price band, and there is no price band, because the price band is a sentence in the middle of a paragraph inside a blob of markup on each of eleven pages.
- You cannot list what you did not separate. A listing page needs the fields to exist as fields.
- You cannot restyle what you did not separate. A design change means opening every page, because the layout is stored inside the content.
- You cannot reuse what you did not separate. The same fact in an email, an app or a search result has to be extracted from prose by a person.
- You cannot validate what you did not separate. Nothing can tell you that four services are missing a summary, because there is no summary field to be missing.
- You cannot mark up what you did not separate. Structured data for search engines needs discrete values, and a paragraph is not one.
None of those is a catastrophe on its own. Together they are the reason a site gets rebuilt after three years rather than extended, and the rebuild is usually described as a redesign because that is what it looks like from the outside.
What a real model buys, measured on this site
This site runs on four content families, each a typed model with required fields. The long-form tier will not compile without at least one source and at least one stated limitation. Answers carry their own updated date. Every family knows which subject area it belongs to. None of that is convention; it is enforced, and a piece missing any of it fails the build rather than getting published slightly wrong.
| Capability | With a model | With one big field per page |
|---|---|---|
| Listing pages | Generated from the fields | Written and maintained by hand |
| Coverage reporting | Computed per subject area | Somebody's spreadsheet, immediately stale |
| Staleness detection | A date field and a review interval | Nobody knows what is old |
| Structured data for search | Emitted from discrete values | Hand-written per page, and it drifts |
| Design change | One template | Every page opened individually |
| Moving platform | Export the fields | Export the markup and start again |
The one worth dwelling on is the second. Because every piece declares its area and its type, a script can report which subjects have depth behind them and which have answers with nothing underneath. That report is the thing that decides what gets written next, and it exists only because the model has the fields to compute it from.
How to sketch one in an hour
This is not technical work and it goes badly when it is treated as such. It is naming the nouns the business already uses, which means the useful version of the conversation happens with whoever does the job rather than whoever will write the code.
- List the nouns. Service, case study, team member, location, article, event. Anything you would say the site has several of.
- For each, write the fields somebody would fill in. Keep going until a colleague could enter a real one without asking you a question.
- Mark which fields are required. A field that is optional everywhere is a field that will be empty on the pages that matter.
- Draw the relationships. A case study belongs to a client and mentions two services. Those are joins, and deciding them now is what makes listings possible later.
- For each noun, ask where else it appears. If a service shows up on a hub page, in a footer, in a proposal and in structured data, those are four consumers and none of them can read a paragraph.
- Name what you are deliberately leaving out, and write down why. The model you can explain is the one somebody can extend without you.
The single highest-value question in that list is the fifth. Almost every expensive content problem is a value that lives in one place and is needed in four, and the cheap moment to notice is before anything is built.
What to ask whoever is building it
- Show me the content types and their fields. If the answer is "pages", there is no model and the site will be rebuilt rather than extended.
- What can I add next year without a developer? A new item of an existing type should be trivial. A genuinely new type reasonably is not.
- Which fields are required, and what happens if one is empty? An answer of "nothing" means the model is decoration.
- How does this content come out if we move? Ask for an export today rather than a description of one.
- Where does the same fact appear more than once, and is it stored once or copied? Copied values are the ones that go out of date silently.
None of those questions requires you to be technical, and all five are answerable in a sentence by somebody who has thought about it. The value is mostly in whether the answers arrive quickly, because a supplier who has designed a model before will have them ready and one who has not will describe the editing interface instead.
What this does not cover
- This describes modelling content for a website or a small application. Modelling for a data warehouse, an event pipeline or a product catalogue with tens of thousands of items involves constraints this page does not touch.
- The measured claims are about one corpus, ours. It is a few hundred pieces maintained by one studio, and a model that suits that is not automatically right for a newsroom or a team of thirty editors.
- It names no CMS as the right answer and does not intend to. The point of the piece is that the model is the decision that outlives the tool, and a recommendation would work against that.
- There is a real cost to structure and this page is not neutral about it. Setting up types and fields is slower than typing into one box, and for a genuinely small site that rarely changes the simpler option is the honest one.
- Nothing here covers editorial workflow, permissions or approval chains. Those matter enormously once more than about three people edit a site, and they are a separate design problem from the model itself.
Sources
- The whatscene.in content corpus, four typed families. The claims about what a model makes possible are a description of this site rather than an analogy. Every family is a TypeScript type with required fields, and the test suite refuses a piece missing a source, a stated limitation, a date or an area. The coverage and staleness reporting described above is computed from those fields and committed as an artifact on every run. Run: lib/content/register.ts and content/REGISTER.md, regenerated by scripts/content-report.mjs.
- Schema.org, the vocabulary structured content is usually mapped onto, Schema.org community. Retrieved 3 September 2026.
Revisions
- 3 September 2026 First published.
This page is revised in place rather than replaced, so its address does not change.