Most website projects start with a sitemap and a set of page designs. Content gets poured into those designs near the end, usually in a rush, and the CMS is configured to match whatever the mockups happened to show. It works on launch day. Six months later the marketing team is copying and pasting the same office address into twelve pages and asking a developer to add a field every time they want to publish something slightly new.
The missing step is content modelling. It is not glamorous and it rarely appears in a proposal as its own line, but it decides how pleasant your CMS is to use for the whole life of the site. Here is what it involves and how to do it without turning it into a months-long exercise.
What a content model actually is
A content model is a description of the types of content your organisation publishes, the fields each type has, and how the types relate to each other. It is written in terms of meaning, not layout.
A page design might show a card with a photo, a name, a job title and a short bio. A content model says there is a Person type with fields for name, role, headshot, short bio and full bio, and that a Person can be linked to one or more Departments and authored Articles. The card is just one way of displaying a Person. The same record might also appear on an article byline, a team page and a speaker list for an event.
Once you think this way, you stop building pages and start building a small database of things your organisation knows about. Pages become views onto that data.
Why skipping it causes problems later
When content is modelled around page layouts rather than meaning, a few predictable things happen.
- Duplication. The same facts live in several places and drift out of sync. A price changes on one page but not the other three.
- Rigid templates. Editors can only publish things that fit the shapes the designer drew. Anything new needs a developer.
- Poor reuse. You cannot pull a filtered list of case studies by industry if industry was never captured as structured data, only mentioned in body text.
- Painful redesigns and migrations. Content trapped inside long rich text fields full of layout markup is hard to move to a new design or a new platform.
- Weak search and SEO. Structured fields make it far easier to output proper metadata, schema markup and clean listing pages.
How to build a content model, step by step
You do not need special software. A spreadsheet or a shared document is fine. What matters is getting the right people in the room: someone who publishes content day to day, someone who owns the brand or marketing goals, and the developer who will configure the CMS.
1. Audit what you already publish
Go through the existing site and list every distinct kind of thing on it. Not every page, every kind of thing: services, team members, locations, blog posts, case studies, FAQs, testimonials, downloads, events. Note which ones repeat and which appear in more than one place.
2. Name your content types
Group those things into types. Use the words your team already uses. If everyone says “projects” rather than “case studies”, call the type Project. Clear naming saves a lot of confusion in the editor later.
3. Define the fields for each type
For each type, list the fields and what kind of data each one holds: plain text, rich text, date, number, image, choice from a list, or a reference to another type. Be specific. “Location” might really mean a street address, a city and a map pin, which are three fields, not one.
4. Map the relationships
Draw lines between types. A Project has one Client, many Services and many Team members. An Article has one Author and many Topics. These relationships are what let you build useful listing pages and cross-links without manual effort.
5. Decide what is reusable and what is page-specific
Some content belongs to one page only, like the intro text on your About page. Some should be shared, like a call-to-action block or a testimonial. Shared items should be their own records that pages reference, so updating one updates everywhere.
6. Test it against real content
Fill the model in with three or four real examples of each type. Gaps appear quickly.
Write a one-line description for every field, aimed at the editor. Most CMS platforms let you show this as help text in the admin. It turns a confusing form into one that explains itself.
Structured fields versus flexible page builders
There is a real tension here. Highly structured models keep content clean and reusable, but they can feel restrictive to marketing teams who want to build a campaign landing page by Thursday. Page builders and block editors give freedom, but too much freedom produces inconsistent pages and content that is hard to reuse.
The best setups use both, deliberately. Core content such as products, services, people and articles is strictly structured. Marketing pages are assembled from a set of approved blocks that each have their own small, structured fields. Editors get flexibility in layout without inventing new data shapes on every page.
| Approach | Works well for | Watch out for |
|---|---|---|
| Strict structured types | Products, people, locations, case studies, events | Can feel rigid for one-off pages |
| Modular blocks | Landing pages, campaign pages, home page | Too many block types becomes confusing |
| Free rich text | Long-form articles, policy pages | Hides data that should be structured |
How it differs between platforms
Every CMS has a way to express a content model, but the tools differ.
- WordPress uses custom post types, taxonomies and custom fields, often through a plugin such as ACF. It is flexible, but it is easy to end up with everything stuffed into the default Page type. Our WordPress development work always starts by setting proper types up front.
- Webflow has CMS Collections with reference and multi-reference fields. It handles straightforward models well, though there are limits on collection and field counts to plan around.
- Craft CMS is built around content modelling, with sections, entry types and flexible field layouts. It suits complex editorial sites.
- Headless platforms such as Sanity, Contentful and Storyblok make the content model the centre of everything, because the same content may feed a website, an app and other channels.
The platform matters less than doing the thinking. A well-modelled WordPress site will be easier to run than a badly modelled headless one.
Common mistakes to avoid
- Modelling around the current design instead of what the content means.
- Creating a new content type for every small variation instead of using a field or category.
- Using free text where a fixed list would keep data consistent, such as country names or service categories.
- Forgetting SEO fields such as meta title, meta description and social image at the type level.
- Leaving editors out of the conversation, then discovering the model does not match how they work.
When to do it
Content modelling belongs after discovery and before design is finalised. If designers know the model, they design components that fit real content. If developers know it, they configure the CMS once instead of reworking it mid-build. On most projects it takes days rather than weeks, and it is usually the cheapest point to prevent the problems described above. We cover where it sits in a typical build on our process page.
Planning a new site or a rebuild?
If you would like a second pair of eyes on your content model before you commit to a build, get in touch and we will talk it through with you.
