Content Modelling for Teams That Keep Adding Page Types

Somebody asks for a webinar page. It should look like the case studies, they say, but with a date, a registration link and a speaker. Two days of work, a new template, everyone is pleased. Nine months later the site has a Case Study, a Webinar, an Event, a Workshop, a Masterclass and a Roundtable, and four of the six differ only in which words the heading uses.

Nobody decided that. It accumulated, one reasonable request at a time, because a content model has no natural resistance. Adding a type is always the fastest way to say yes, and the cost of a page type is never paid on the day it is created. It is paid every quarter afterwards, by people who did not attend the meeting.

Content model governance is the practice of making that cost visible before the type exists, rather than eighteen months later during a redesign. It is not heavy process. It is one test, one naming rule and one recurring hour. This is what we would install on a team that has started to feel the sprawl but has not yet been forced into a rebuild by it.

How a model quietly grows to forty types

The growth pattern is consistent, and worth recognising because it never feels like sprawl while it is happening. A campaign needs a page that behaves slightly differently. A new team joins and brings its own vocabulary. A design refresh introduces a layout that does not fit the existing template, so it becomes a type instead of a variant. Somebody leaves, and their successor cannot tell whether an existing type was meant for this.

That last one matters most. Duplicate types are rarely created out of laziness. They are created out of uncertainty, by an editor who cannot tell from the interface whether the type in front of them was intended for the thing they are publishing, and who reasonably concludes that a new one is safer. Duplication is a documentation failure wearing an engineering costume, and it is a close relative of why a content team keeps asking a developer for small changes: both come from a model nobody can read.

Every page type is a standing commitment

When a team weighs up a new type, they price the template. That is the smallest part of the bill and the only part that arrives in the first week.

• A template and its responsive behaviour. Which somebody has to test at every breakpoint you support, this time and every time the design system changes underneath it.
• A field set, with required and optional decisions. Every optional field is a page that might ship without it, so every optional field is also a layout state somebody has to design.
• Metadata and structured data rules. Titles, descriptions, canonical behaviour, and whether the type maps onto anything a machine can name.
• A place in navigation, listings and search. A type nobody can reach is a type that gets found by an auditor rather than by a customer.
• A line in every future migration. Forty types means forty mapping decisions the next time you move platform, made by whoever is available rather than by whoever understood them.
• A translation obligation, if you have locales. The model multiplies by the number of languages, which is the multiplication nobody performs in the meeting.

That last item deserves its own paragraph, because it is where sprawl stops being annoying and starts being expensive. Six near-identical types across four languages is twenty-four things to keep consistent, and consistency is not something a team does. It is something a model does on the team’s behalf. We have written separately about running multiple languages without building a second website, and every argument in it gets harder as the type count climbs.

The test for whether it is really a variant

Here is the rule we apply, and it settles most requests in about ten minutes. A new page type is justified only when the thing it describes has a genuinely different shape, not a different label.

1. Does it need fields the existing type does not have? Not different values in the same fields. Actually different fields. A date and a registration link are two fields, which is an argument for two fields.
2. Does it have a different lifecycle? Something that expires behaves unlike something permanent. Expiry is a real structural difference, because it changes listing, indexing and archiving.
3. Would somebody browse for it as a category of its own? If nobody would ever filter a list by this distinction, it is a label rather than a type.
4. Is it owned by different people, on a different rhythm? Ownership is the most underrated reason to split a type, and the one that best predicts whether two things stay in sync.
5. Would a stranger explain the difference the way you just did? Say the distinction out loud to somebody outside the team. If it takes more than one sentence, it is not a type.

Fewer than two clear yes answers means the request is a variant: a field on an existing type, a layout option, or in the best cases nothing at all. This is the same instinct that decides when to consolidate two pages instead of optimising both, applied one level up in the system.

Naming discipline is not pedantry

A model with bad names grows faster than a model with good ones, because a name that does not say what belongs inside it invites somebody to make a second one. This is the cheapest governance available and the first thing teams skip.

The rules we apply

Name the thing in the world, not the page in the site. "Event" is a thing. "Landing Page 2" is a filename. Use the singular, always, because a type describes one entry and the plural creeps into URLs and API responses where it causes small permanent annoyances. Never name a type after a campaign, a quarter, a team or a person, since all four expire and the type will not.

Name the fields with the same care. A field called "Description" ends up holding an excerpt on one type, a meta description on another and a paragraph of body copy on a third, at which point nothing can be reused and no organic content programme can run across the model without a spreadsheet of exceptions. Say what the field is for: summary, meta description, intro. The extra word costs nothing and closes a category of confusion permanently.

One further discipline: where a type maps cleanly onto something with a public definition, borrow the vocabulary. If your article type carries a headline, an author reference and a published date because those are the properties a machine already understands, your model and your structured data stop being two separate pieces of work maintained by two different people who each assume the other one did it.

A model review that takes an hour a quarter

Governance fails when it is a document. It works when it is a recurring meeting with a short agenda and one person allowed to say no. An hour, once a quarter, with whoever owns the CMS and whoever publishes most.

1. Count the entries per type. Any type with fewer than a handful of entries is a candidate for merging. A type with one entry is a page that got promoted above its station.
2. Find the fields nobody fills. An optional field left empty on most records is either badly named or genuinely unnecessary. Both conclusions end in a deletion.
3. Read the newest three types aloud. If two of them cannot be told apart in one sentence each, they were variants, and the merge should be scheduled now while it is still small.
4. Check what changed without a decision. Fields added between reviews, by whom and why. Not to assign blame, but because the reason is usually a real need somebody solved locally and quietly.
5. Write down one deletion. A review that never removes anything is an audit, and audits do not shrink models.

The review is far easier when the model itself is versioned alongside the site, because then "what changed" is a diff rather than a memory. That is one of the practical arguments for version control over marketing content, and it sits close in spirit to the review discipline our parent company describes in the reviewer’s pass.

Whatever tool you use has to make the model an editable artefact rather than hidden configuration. A structured content workspace such as Acrosite works this way: editors fill structured fields, and the files that result are generated, committed and deployed, so the shape of the content and the history of that shape live in the same place.

Fields that survive a redesign

The real test of a model is not whether it renders today. It is whether the content can be re-rendered into a design nobody has drawn yet. Content stored as typed fields passes that test. Content stored as one large rich-text field with layout pasted inside it does not, and no migration script rescues it, because the information was never separated from its presentation in the first place.

The practical rule: a field holds a fact, not a decoration. A price is a number, not a formatted string with a symbol baked into it. A publication date is a date, not the words somebody typed. An author is a reference to a person, not a name repeated across two hundred entries where it will be spelled two ways within a year.

Blocks are the honest middle ground for pages that genuinely need flexible composition. A block library is a set of components an editor can arrange, and it absorbs most "we need a different layout" requests without another type appearing. It is also where discipline goes to die if nobody prunes it, so give blocks the same quarterly attention, and route real interface changes through product improvement rather than through the content model.

When a new type genuinely is the answer

The concession, because a piece arguing only for restraint would be dishonest. Sometimes the new type is correct, and refusing it produces a worse outcome than the sprawl you avoided.

Overloading one type with fifteen optional fields to serve six purposes creates a form no editor can use and a template full of conditional branches nobody dares touch. That is not a small model. It is a large model hidden inside a single record, and it is worse than the split would have been, because at least separate types can be reasoned about separately.

Split when the fields diverge more than they overlap, when two teams own the two halves, or when the lifecycles genuinely differ. Split deliberately, name it properly, and write down what it is for in a sentence the next person will actually find. Those criteria are worth carrying into a shortlist too, alongside the twelve questions that separate one CMS from another, because a system that makes modelling awkward will produce a worse model no matter who is running it.

A content model is a promise about what you will keep consistent. Every type you add is a promise you have to keep again.

Where we would start on Monday

Do not begin by redesigning the model. Begin with a count, because the count makes the argument for you and it takes about twenty minutes.

List every type, the number of entries in each, and the date the most recent entry was published. Three columns. That table has ended more modelling arguments than any diagram we have ever drawn, because it exposes the types with two entries and nothing published since last spring, and nobody defends those once they are written down next to each other.

Then merge the obvious pairs, install the variant test as the standing answer to the next request, and put an hour in the calendar for the quarter after next. If a platform move is already on the horizon, do this before it rather than after, because a model tidied in advance is the difference between a mechanical migration and a rebuild that quietly re-decides everything under time pressure. The same holds for the build itself: the model should be settled before the templates are written, not discovered while they are.

And if the count comes back at forty and nobody can face it, that is a normal place to be rather than a failure. It is also the point at which an outside reading helps, because the person who added type thirty-one is rarely the person who can argue for its removal. Bring us the list and tell us what keeps getting requested. The pattern inside the requests is usually the model you should have had.