Content modelling, explained for non-technical content teams
If you are a content lead in an Australian government agency, content modelling is something you should be running. It is not a job to wait for a developer to do for you. This guide is a plain-language explainer of what content modelling is, why content people are the right people to lead it, and how to build a model your engineers can take to a CMS.
What content modelling is
A content model is a structured list of decisions. It says: these are the content types we publish, this is what each type contains, and this is how they relate to each other.
A worked example. A health agency website might have content types called "Service", "Eligibility criteria", "Office location", and "News update". The Service type contains a name, a one-line description, the eligibility criteria that apply (linked from the Eligibility type), the offices that deliver it (linked from Office), and a list of next steps. The model says, once, what every Service page contains and how it connects to the rest. Every individual service page is a filled-in version of that template.
That is the whole concept. Content modelling is not technical in nature. It is a content design discipline that produces a specification engineers then build against.
A content model is a content design decision in a technical wrapper. The decisions belong to content people.
Why content people should lead this work
When developers lead content modelling, you usually end up with a model that mirrors the database. Efficient to store, painful to publish into. Fields get added because they are easy to add, not because users need them. Relationships get modelled by what is technically convenient, not by how content actually gets used.
In my experience, consolidation only works because content people made the modelling decisions. We decided what types of content existed, what each one needed, and how they related, before we briefed any engineering. That is the order it has to happen in. Reverse it and the technology bakes in content problems you cannot then unbake.
Content modelling is also where structured publishing gets decided. If your content needs to surface on the web, in a service app, through a chatbot, and in an AI-generated answer, the model is what makes that possible. The Australian Government Digital Service Standard expects services that work across channels. You cannot deliver that without a content model that supports it.
Before you start
You need three things before sitting down to model.
A clear scope. The website or service area you are modelling, with the boundaries written down.
A representative sample of existing content. Not all of it, but enough to see the patterns.
Someone with authority to make decisions in the room. Modelling without decision authority is theatre.
You do not need a CMS chosen yet. The model precedes the platform. Choosing the platform first is one of the most common ways agencies bake content problems into their next redesign.
How to build a content model in six steps
Step 1: List the content types you have, and the ones you need
Walk through your sample content and group it. What is repeating? A "Service" page is a content type. A "Policy update" is a content type. A "Form instructions" page is a content type if it has a consistent shape across the site.
You are not listing every page. You are listing the underlying templates that pages are filled into.
Resist the urge to give every section its own type. If two things have the same structure and serve the same purpose, they are one type with different content in it.
Step 2: For each content type, decide what fields it must contain
For each type, list the fields. A field is a piece of structured information: a title, a short description, a date, an image, a link to another content type.
The mistake to avoid is making everything a "body" field with free text inside. That is how you end up with content that looks consistent but cannot be reused, restructured, or published anywhere except the page it was written for.
For a Service type, the fields might be: name, plain-language summary, who it is for, eligibility, how to apply, contact, and related services. Each of those is a field. Each can then be reused or restructured later. The body field is the last resort, not the default.
Step 3: Map the relationships between content types
Content types relate to each other. A Service is delivered at one or more Offices. A Service is supported by one or more Forms. A News update may relate to a Service.
Draw it. A whiteboard works. So does a piece of butcher's paper. The point is to make the relationships visible so the model can be questioned and refined before anything is built.
Step 4: Decide reuse rules
For each piece of content, decide where it appears. A service summary might appear on the service page itself, in a service finder, in an AI-generated answer, and on a campaign landing page. Decide that now.
The reason: if a piece of content appears in five places, it cannot live inside a paragraph in a body field on one page. It needs to be a structured field that can be pulled by reference.
Step 5: Validate the model with a real piece of content
Take three real services and try to fit them into your model. Where does it strain? Where do you have to invent a field? Where do you have to leave fields blank?
A model that fits 95 percent of cases is a good model. A model that fits 100 percent is usually a model with too many optional fields. Adjust until the strain is in the right places.
Step 6: Hand over to engineering with the decisions documented
The handover document is the model you have just built. The types, the fields, the relationships, the reuse rules. Engineering then implements that in whichever CMS you are using.
The handover is the moment content modelling stops being a content design job. Until that point, content people are the decision-makers. After that, engineering is.
What good looks like
When the model is right, three things happen.
Content teams can answer the question "where does this go?" without a meeting. Engineering can build new content types without re-litigating what the structure should be. And the same piece of content can move into a new channel, an app, a chatbot, an AI answer, without being rewritten.
Content modelling is not a technical discipline. It is a structured way of making content design decisions visible. If you are leading content in an agency and you are not running this work, you are leaving the most consequential decisions about your content to people whose job is the database, not the user.
What is one content type on your site you could model in an afternoon?
Photo by Shiona Das on Unsplash