Your CMS model decides what you will be able to fix later

The rename that reveals the model

A product gets renamed. It is a normal thing that happens to normal companies, usually about eighteen months after the CMS was set up.

In one model, the name lives in a product record, and every place it appears is a reference to that record. The rename is one edit and every page follows. In another model, the name was typed into a text field on each page as it was written, because that was faster and read more naturally at the time. The rename is now a search across the site, done by hand, with a residue of misses that will surface for months.

Nothing about the second model was incompetent. It was the reasonable choice for producing the pages that existed then. It was made without asking what would happen when the thing it described changed, and that question is the entire subject of CMS modelling for operations.

Modelled for the page, or modelled for the system

Almost every CMS collection I have looked at was modelled backwards from a specific page design. Here is the layout, here are the slots, therefore here are the fields.

That produces a model that renders one page well and answers no questions. Which products does this integration support. Which pages state a price. Which features belong to which plan. All of those are answerable in a system model and unanswerable in a page model, and all of them are the questions you need answered when something changes.

The alternative is not more abstraction, which is its own failure. It is asking one additional question per field: is this a fact about the thing, or a decision about this page. Facts belong to the entity. Presentation decisions belong to the page. Most collections mix them freely, and the mixing is what makes them brittle.

Values where references belong

This is the single most expensive modelling mistake and it is worth stating on its own.

Any fact that exists independently of the page should be stored as a reference to the thing that owns it, not copied as text. Product names, plan names, prices, plan limits, integration names, people's job titles. Each of those has an owner somewhere, and every copy is a future disagreement.

The counterargument is real: references make the editing experience worse, and a marketer filling in a form finds a text field easier than a relationship picker. That is true and it is a solvable interface problem, whereas a site where the same fact is typed in forty places is not a solvable problem at all.

The test for a field is simple. If this value changed everywhere in the company tomorrow, how many places would somebody have to edit. If the answer is more than one, it should have been a reference.

One caveat on prices specifically. A price often has a lifecycle that a CMS is not the right owner of, because it is agreed elsewhere and has approval attached. In that case the CMS field should be a reference to whatever does own it, or at minimum a read only field populated by a build step, so the site cannot disagree with the source. The failure to avoid is a freely editable price field, in a CMS, that somebody can change without the change being visible to finance.

Validation belongs in the model

The second thing that goes missing is validation, because CMS tools make it optional and the person setting up the collection is usually also the person who will fill it in first, and they know what they meant.

Then somebody else fills it in. Then a third person. Two years later you have a status field containing coming soon, Coming Soon, soon, and beta, which are four values that mean one thing and are not filterable, so nothing can be built on top of them.

The fields worth constraining are consistent across most sites: anything with a fixed set of allowed values should be an enum rather than text. Anything required for the page to render should be required in the model rather than hoped for. Anything with a format, a URL, a date, a currency, should be typed rather than a string.

The general principle: a constraint in the model is enforced on everybody forever. A constraint in a style guide is enforced on whoever read it, which after the first year is nobody.

Relationships you will wish you had modelled

Three relationships come up on nearly every site, are almost never modelled, and each one is the answer to a question people ask constantly.

Feature to plan. Sites list features on the product page and plans on the pricing page and never connect them, which is why the most common buyer question, is this feature included in my plan, has no answer anywhere that a machine could read.

Page to fact. Which pages state a price, a plan limit, a product name. Without this, checking whether a pricing change has been applied everywhere is a manual search. With it, it is a query.

Content to source. Which support question or sales objection caused this page to exist. Almost nobody records it, and it is the field that makes a content review possible two years later, because it is the only way to know whether the reason for a page still holds.

There is a fourth that is site specific and worth looking for: whatever your sales team has to look up in two places. On most B2B sites that is the mapping between a customer segment and the proof relevant to it, which lives half in a CMS collection and half in a deck. If somebody is manually joining two sources every week, that join is a relationship your model does not have.

Permissions are part of the model

Who may edit which field is usually treated as an administrative setting, added late, at role level. That is too coarse to be useful for operations.

The useful granularity is per field. A marketer may edit the hero heading. Nobody may edit the compliance paragraph without a named approver. The price field is not editable in the CMS at all, because it is a reference to a record that finance owns.

This matters more once anything automated touches the site, because an automated editor needs a machine readable answer to what it may change, and a policy document is not one. But it matters before that too. Most of the wording that goes wrong on a site was changed by somebody who had permission and did not know the sentence was load bearing.

The lightweight version is a boolean and a note: is this field fixed, and who approved it. That takes an afternoon to add and it is the difference between a site where the important sentences are protected and one where they are protected by whoever happens to remember.

Stale data is a modelling problem

The last one is the one nobody thinks of as a modelling decision at all. What happens when a value becomes wrong.

Most CMS records have no answer. There is no last reviewed date, no owner, no review interval, and no way to distinguish a record that was correct yesterday from one that has been unexamined since it was created. So the site contains a mixture of current and stale content with no signal separating them, and the only way to find the stale part is to read everything.

Three fields fix this and they cost nothing: last reviewed, reviewed by, review interval. Once they exist, finding what nobody has looked at is a query rather than an afternoon, and the review becomes a schedule rather than an initiative.

The objection is that nobody will fill them in. That is what defaults and required fields are for, and it is also why the review interval belongs on the collection rather than on each record.

Where teams get this wrong

Modelling for the design. The layout is the most concrete thing in the room when the collection is created, so it drives the fields. Design changes and data does not, so this gets the dependency backwards.

One collection for everything similar. Case studies, customer stories and use cases end up in one collection with a type field and half the fields empty on any given record. That is three models wearing a trench coat, and every query has to know which one it is dealing with.

Over normalising. The opposite failure and it is real. Not everything needs to be a reference. Page level decisions, headings, ordering, which image to use, belong on the page, and abstracting them produces a model nobody can fill in without a diagram.

Treating migration as impossible. Most teams believe the model is fixed once there is content in it. Adding a reference field alongside an existing text field, backfilling it, and switching the template over is usually a day of work per field. It feels irreversible and mostly is not.

Changing a model that already has content

Since the model is usually wrong by the time you notice, the migration path matters more than the ideal design.

The pattern that works is additive and reversible. Add the new field alongside the old one rather than replacing it. Backfill it programmatically where you can and by hand where you cannot, which is usually a smaller job than expected because most collections have fewer records than people think. Switch the template to read the new field. Leave the old field in place, unused, for a while. Remove it only once nothing has read it for a full review cycle.

The step people skip is leaving the old field in place. It costs nothing and it means the migration can be reversed on the day somebody discovers a template you forgot about.

Do one field at a time. A model migration that changes six fields at once cannot be diagnosed when a page renders wrong.

What good looks like

A well modelled CMS is recognisable by what is easy rather than by how it looks.

Renaming a product is one edit. Finding every page that states a price is a query. A record that has not been reviewed in a year can be listed. Somebody filling in a new record cannot leave out something the page needs, and cannot invent a fifth spelling of a status. The sentences that matter are marked as fixed, and the person who approved them is named on the field rather than remembered.

None of that is visible on the site, which is why it does not get prioritised. It becomes visible on the day something changes, which is also the day it is too late to add.

Where this shows up in what we are building

Creogen reads a site's model to answer the operations questions above: which pages state a given fact, which records are stale, which values are references and which were typed. It is in private development and I would rather state that plainly.

The reason the model matters so much to us is that everything on the operations side degrades to guesswork without it. If a price is typed as text in forty places, no tool can tell you reliably which ones are wrong. It can guess with string matching and it will be confidently incorrect about the edge cases, which is the worst available outcome on a live marketing site.

This came out of building the four Webflow Designer apps, where we spent a great deal of time working against other people's collections. The ones that were modelled for the page were the ones where we had to do the least reliable work, and that experience is most of why the checklist above exists.