How Do You Model Content in a CMS So It Still Works in Three Years?

What is content modelling and why does it decide everything later?

Content modelling is deciding what kinds of things your site holds, what each one is made of, and how they relate. It sounds like an afternoon of admin. In practice it is the decision that determines whether adding a new page type next year takes an hour or a rebuild.

We see the consequences of this constantly. A site that works beautifully for eighteen months and then hits a wall, where every new request needs a developer because the structure cannot express the thing the marketing team wants to publish.

Nobody plans for that. It arrives because the first model was drawn around the first design, and the design changed.

Why do content models go wrong?

Almost always for one reason. Somebody modelled the page instead of the thing. They created a collection called Homepage Cards, with fields named Card One Title and Card Two Title, because that is what the layout needed that week.

It works immediately, which is the trap. Then the homepage gets redesigned with three cards instead of two, and a field called Card Two Title now means nothing. The content is welded to a layout that no longer exists, and the only way out is to touch every record.

The second common cause is modelling around who asked. A field gets added because someone in sales wanted a badge on one page. Two years later there are forty fields, six of them used once, and nobody remembers which are safe to delete. Our notes on design debt cover the same rot on the visual side.

What is the first question to ask?

Ask what this thing is in the real world, with no reference to the website at all. A case study is a case study whether it appears as a card, a full page, a row in a table, or a line in a search result. Model the case study. Let the templates decide how it looks.

A useful test is whether you could describe the record to a colleague who has never seen the site. If you find yourself saying it is the box on the left of the pricing page, you are modelling a layout. If you can say it is a customer story with an outcome and an industry, you are modelling a thing.

This single habit prevents most of the pain. It does not require any special tooling, and it works the same way in Webflow, WordPress, Contentful, Sanity, or Storyblok.

When should something be a field and when a collection?

Make it a collection when the thing has its own identity and might be reused, referenced, or listed. Make it a field when it only ever describes one parent record and has no life of its own.

An author is a collection, because the same person writes many posts and you want their bio in one place. A reading time is a field, because it belongs to exactly one post and means nothing alone. An industry is usually a collection, because you will eventually want a page listing every case study in that industry.

When you are genuinely unsure, ask whether you would ever want a page for it. If the answer is maybe, make it a collection. Promoting a field to a collection later means a migration. Demoting a collection to a field is comparatively painless.

How many collections is too many?

There is no magic number, but there is a smell. If your collections outnumber your templates by a wide margin, and several of them hold fewer than five records that never change, you have modelled configuration as content.

Those tiny collections usually should have been a field with a fixed set of options. They add joins, they add editor confusion, and they add places for someone to create a duplicate with a slightly different spelling.

The opposite failure is worse though. One giant collection with a type field and thirty mostly empty fields, where a record is a case study or an event or a job depending on which checkbox is ticked. That is a spreadsheet wearing a CMS costume, and it makes every template full of conditional logic.

What do reference fields actually buy you?

Consistency and the ability to ask questions later. When industry is a reference rather than a text field, you can build an industry page without cleaning data first, and nobody can type Financial Services in one record and Finserv in another.

They cost you something too. References make imports fiddlier, because the target has to exist first. They make bulk editing slower. And in most platforms they impose limits on how deep you can traverse, which is worth knowing before you design a three level relationship you cannot actually render.

Our rule is to use references for anything you will want to filter or group by, and plain fields for everything else. Our guide to reference fields in Webflow covers the platform specific mechanics.

Should you model for the design or for the meaning?

For the meaning, with one pragmatic exception. Meaning survives redesigns and layouts do not, so the structure should describe the content. The exception is that you can and should add explicit presentation fields when a choice is genuinely editorial.

A field called featured is fine, because whether a story is featured is a decision a person makes about importance. A field called show in the third slot on the homepage is not fine, because it encodes a layout that will change.

The line between them is whether the field would still make sense if the page were rebuilt from scratch. Featured survives. Third slot does not. This is also why a clean model makes template level fixes possible. WebAIM's Million report, published in February 2026, found that 96 percent of all detected accessibility errors across one million home pages fall into just six categories. Those are template problems, and a site with a clean model fixes them once rather than per page.

How do you handle content that does not fit?

Resist the urge to add a field, and check whether it is actually a new kind of thing. The request for a slightly different case study with a video instead of a quote is usually not a new collection. The request for a partner listing that happens to look like a case study probably is.

The tiebreaker we use is the audience and the lifecycle. If a different team owns it, it is updated on a different rhythm, or it appears in a different navigation, it is a different thing. If none of those differ, it is the same thing with a variation, and a variation is a field.

Keep a short document explaining what each collection is for, in plain language, and put it where editors can find it. Most model decay happens because the original reasoning was never written down and the person who knew it left.

What does a migration reveal about your model?

Everything, unfortunately. Migration is where a bad model presents its bill. Every field that meant two things, every collection that was really three, and every value someone typed by hand becomes a decision you have to make one record at a time.

It is also the best time to fix things, because you are touching everything anyway. We treat a migration as the moment to merge duplicate fields, convert repeated text into references, and delete the fields nothing renders. Doing that work outside a migration rarely gets prioritised.

Plan for the URLs separately from the content, because that is where the real risk sits. Our guide to migrating without losing SEO covers the redirect side of the same project.

Does the platform you choose change any of this?

Less than people expect. The modelling principles are the same everywhere, and the platform mostly changes the cost of getting it wrong. The HTTP Archive Web Almanac's 2025 CMS chapter found that CMS driven sites account for over 54 percent of observed websites, with WordPress powering roughly 64 percent of them, Shopify between 7.3 and 7.8 percent, Wix around 5 percent, and Squarespace roughly 3 percent.

What differs is flexibility and limits. Some platforms let you restructure freely and some make a change to a field type a genuine project. Knowing which kind you are on should change how much time you spend modelling up front, not whether you do it.

If you are choosing between an all in one platform and a headless setup, our piece on headless CMS covers the trade offs behind that decision.

How would we start a new model?

On paper, before anyone opens the CMS. List the things the business talks about. Case study, service, author, industry, job, event. For each one, write what it is in a sentence and what it is made of. Then draw the lines between them.

Only then check the design, and treat any mismatch as a question rather than an instruction. If the layout needs something the model cannot express, either the model missed a real thing or the layout invented one. Both happen, and finding out on paper costs nothing.

If you are staring at a CMS that has stopped bending and trying to work out whether it needs a remodel or a rebuild, we are happy to take a look. You can find us at phoenix.studio.