Content modeling: collections and fields in practice

Content modeling is the design of how a CMS stores information: which content types exist, what fields they contain and how they relate to each other. It sounds technical, but every editor feels the consequences. A good content model means adding a new case study takes three minutes and a redesign doesn't require retyping a hundred entries. A poor one leads to copied pages, inconsistent layouts and calls to a developer.

Key takeaways

• A collection is a repeatable content type, such as case studies, team members or job openings, where every entry has the same fields.
• A field should hold one piece of information with a clear purpose, not an entire formatted block of text.
• Relations between collections let you link, for example, a case study to a service without copying data.
• Design the content model before the visual design, based on an inventory of existing content.
• SEO fields such as meta title and description belong in every content type that has its own URL.

Content modeling starts with an inventory

Before you open the CMS, list everything the website needs to contain. A spreadsheet works best: one column for the type of content, one for examples and one for information that repeats. After an hour you will see that a case study always has a client, an industry, a scope of work, a gallery and a short description, and that a team member always has a name, a role, a photo and a bio. Those are your future collections and fields.

Ask three questions along the way:

• Does this content repeat, and will there be more of it?
• Does it need to be filtered, sorted or shown in several places?
• Does each item need its own URL?

If the answer to any of them is yes, you have a candidate for a collection.

Page, collection or block: how to choose

The most common dilemma concerns services. If you have three services, each with its own elaborate layout, build them as pages. If you have twenty services with a similar structure that you want to list, filter and link to case studies, make them a collection.

Choosing field types

A field type is the kind of data a field accepts, such as text, a date, an image or a choice from a list. The right field type protects content from errors and makes it easier to display later. A few rules from practice:

• Plain text over rich text where possible. A client name, a job title or a city are short text fields. Save rich text for descriptions that need paragraphs, bold text and links.
• Select instead of free typing. An industry typed by hand quickly becomes "IT", "it", "Tech" and "Information technology". A select list keeps things tidy and enables filtering.
• Tags for loose labels, select for categories. If the list of values is closed and matters for navigation, use a select or multiselect. Tags work where editors add new labels themselves.
• Dates as dates. A project date typed as "spring 2025" can't be sorted.
• Booleans for switches. A yes/no "featured" field lets you show chosen entries on the home page without maintaining a separate list.

Relations: link, don't copy

A relation is a field that points to an entry in another collection or to a page. Instead of typing the service name and description into every case study, you pick the service from a list. Rename the service and the change appears everywhere. Relations also enable useful views: show related case studies on a service page, or display the author from the team collection next to an article.

Beware of too many relations, though. If editors have to pick five relations for every entry, they will start skipping them. Make only the relations required to render the page mandatory.

Example: a content model for a law firm

Here is what a model might look like for a law firm with an expert blog:

• Practice areas (URL /practice-areas/{slug}): name, short description, rich text body, icon, relations to lead lawyers.
• Team (URL /team/{slug}): full name, role, photo, bio, languages spoken (multiselect), relations to practice areas.
• Articles (URL /blog/{slug}): title, lead, body, publication date, author (relation to team), tags, meta title and description.
• Client testimonials (no URL of their own): text, attribution, relation to a practice area.

With this model, a practice area page can automatically show the lawyers who handle it and the latest articles on the topic, with nothing pasted by hand. For more examples from this sector, see LessCMS for law firms.

Content models, multilingual sites, SEO and APIs

You design a model not just for today's website but for its future uses. Three things are worth thinking through up front:

• Languages. If the site will be multilingual, decide which fields are translated (name, description, slug) and which are shared across versions (date, image, relations). Clean, separate fields make translation, including automated translation, much easier.
• SEO. Every content type with its own URL needs a meta title, a meta description and a well-considered URL pattern. Changing the pattern after launch means redirects for every entry.
• APIs. If content may one day feed an app or a separate front end, fields with a clear meaning are far easier to consume than one formatted block of HTML.

Naming and editor experience

• Name fields in the editor's language, not the developer's: "Main image" rather than "hero_img".
• Add short hints: "max. 160 characters" for a description or "16:9 format" for an image.
• Mark as required only the fields without which an entry cannot be displayed.
• Group fields with separators: content, media, SEO, settings.

Common content modeling mistakes

• One giant rich text field. Everything in a single editor means no filtering, no consistency and a painful redesign.
• A collection for everything. Three unique pages don't need a collection of their own.
• No SEO fields. Meta titles and descriptions added "later" usually never get written.
• A model tied to one design. Fields like "left column text" lose their meaning at the first redesign. Name fields by meaning, not position.

Changing the model after launch

Your content model will evolve, and that is normal. Adding a new field is usually painless, but changing a field type or splitting one collection into two means moving data. CSV export and import helps here: export the entries, tidy the data in a spreadsheet and import it into the new structure. Take a project backup before you start.

Frequently asked questions

What is content modeling in a CMS?

Content modeling in a CMS is designing content types, their fields and their relations before you start publishing. A well-designed model means editors fill in a form while the system takes care of layout, listings and URLs.

When should I use a collection instead of a page?

Use a collection for repeatable content with the same structure that will keep growing, and a page for unique content with its own layout. Case studies and team members are collections, while About and Contact are pages.

How many fields should a collection have?

A collection should have as many fields as the information you actually display or filter by, typically somewhere between a few and a dozen or so. Every field nobody fills in or displays only slows editors down.

Can I change the content model after the website launches?

Yes, you can change the content model after launch, and adding new fields is usually simple. Changing a field type or splitting a collection requires moving data, for example via CSV export and import.

Content modeling in LessCMS

• Collections in LessCMS automatically get listing pages, URLs based on a pattern (e.g. /case-studies/{slug}) and sitemap entries.
• Field types include text, rich text, image, gallery, files, select, multiselect, boolean, date, relations, tags, list and button, plus separators for grouping.
• Collections can be exported and imported as CSV, and published entries are available through a read-only API if you build your own front end.

Want to design a content model on your own project? Check LessCMS plans and sign up without a card.