Content Models
A content model defines the fields, types, and constraints of a content type — what separates content that can be filtered and reused from content trapped on a single page.
An article is not a chunk of formatted text. It is a structured object with a title, a description, an author, a publication date, a category, a collection of tags, and a body. If those fields are modelled explicitly — stored separately, validated independently, and linked relationally — the article can be rendered in multiple contexts, searched, filtered, syndicated, and maintained as the product evolves. If those fields are not modelled — if “article” means “a blob of HTML in a database” — none of that is possible without extraction and reprocessing.
This is what a content model is: the specification of a content type as a structured set of fields with defined types and constraints. It is the difference between content as data and content as text.
Why content models matter
Content without structure is trapped in the context it was written for. A product description written as a block of prose, with the price embedded in the text, cannot be displayed separately from the prose, cannot be queried, cannot be filtered, cannot be compared across products. To extract the price, you either rewrite the content or build a parser.
Content with structure is portable. A product description modelled as a set of fields — name (string), price (number), currency (enum), description (rich text), images (array of assets), category (relation) — can be rendered in a product page, a search result, a comparison table, an email, a mobile app, and a sales report, using the same source data. The model is the contract between content and presentation.
Designing a content model
A content model starts with a question: what is this content type, and what does a consumer of it need to know?
For an article, the consumer needs: a headline to display, a description for previews, a publication date for ordering and display, a body for full reading, and categories and tags for navigation and filtering. These become the fields of the model.
For each field, specify:
- Type — text, number, date, boolean, rich text, asset, relation, array, enum
- Required or optional — what must be present for the content to be valid
- Constraints — maximum length (especially for SEO-critical fields like title and description), accepted values for enums, allowed asset types
The constraints matter as much as the fields. A description field without a maximum length will eventually contain a paragraph that breaks every card and preview it appears in. A category field modelled as free text will accumulate synonyms, misspellings, and inconsistencies. Constraints are how the model enforces consistency without requiring editorial intervention.
Content model and design
A content model shapes design decisions, and design decisions shape content models. When a designer specifies a card with three lines of description, the content model must constrain the description field to fit. When a content model defines a field as a relation to another content type, the design must accommodate the possibility that the related content has not yet been created.
This interdependency is why content modelling is a collabourative activity. A content model designed in isolation from the design produces constraints that do not match the visual system. A design created without reference to the content model produces layouts that the content will not fit.
Headless CMS and content modelling
The rise of headless CMS platforms (Contentful, Sanity, Strapi, and others) has made content modelling a practical discipline for web teams rather than a theoretical one. In a headless CMS, the content model is the first thing you define — before writing content or building presentation. This forces the conversation about structure to happen early, when it is cheap, rather than late, when the cost of remodelling is high.
The lesson from headless CMS practice is transferable to any content-bearing system: define the model before you create content, not after. Structure is much harder to retrofit than to build in from the start.
Continue to metadata and taxonomy — how to organise and classify content so users can find it.