By Mehdi HassanContent modeling sounds like a developer job. It isn't. It decides what your marketing team sees every time they open the CMS, which pages you can build later and how easily content moves to a new platform one day. Get it right and editing feels like filling in a clear form. This guide is part of our hub on CMS setup for marketing websites, and it gives you real models to copy.
What is content modeling?
Content modeling is the work of deciding which types of content a website has, which fields each type contains and how the types connect. The result is a content model: a blueprint the CMS is built from and the design is built around.
A content type is a kind of thing, such as a blog post or a case study. Fields are its parts: a title, a date, a summary, a logo. Relationships connect types, such as a post that references an author. Structured content means content stored in those typed fields, rather than one large block of formatted text, so it can be displayed, filtered and reused in many places.
Term | Meaning | Example |
|---|---|---|
Content type or collection | A kind of content with a shared structure | Case study |
Field | One typed piece of a content type | Industry, logo, results summary |
Reference | A link from one entry to another | Case study links to integrations used |
Global or singleton | Content that exists once | Site navigation, footer, announcement bar |
Block | A reusable page section with its own fields | Testimonial, FAQ, CTA band |
How should a SaaS site structure its CMS?
A SaaS site should structure its CMS around a small set of collections that each publish regularly, plus globals for site-wide content and a page type built from blocks. The usual collections are posts, authors, categories, case studies, integrations, changelog entries and team members.
- Pages: built from blocks, for the homepage, product pages, pricing and landing pages.
- Collections: repeating content with the same structure, listed and filtered on index pages.
- Taxonomies: categories, industries and use cases, as their own small collections you can reference.
- Globals: navigation, footer, announcement bar and default SEO settings.
- Shared library: testimonials, logos and CTAs, referenced from any page or collection.
If headless and blocks are new terms for your team, our guide to headless CMS explained for non-developers covers the basics, and page builder blocks explains how pages are assembled.
What should a blog post and author content model include?
A blog post model should include a title, slug, author reference, category reference, publish and updated dates, an excerpt, a short answer or summary, the body, an FAQ list and an SEO group. Authors and categories should be their own collections, so a change to an author bio updates every post.
Field | Type | Why it's separate |
|---|---|---|
Title and slug | Text | Slug controls the URL and should be editable but validated |
Author | Reference to Authors | One bio and photo, reused on every post |
Category | Reference to Categories | Powers category pages and filters |
Published and updated dates | Date | Freshness signals and sorting |
Excerpt | Text with a length limit | Cards, meta description fallback |
Summary | Text | An answer-first paragraph engines can quote |
Body | Rich text with allowed blocks | The article itself |
FAQ | Repeating question and answer | Visible FAQ and structured data |
SEO group | Title, description, image, canonical | Search and social previews |
The summary and FAQ fields are worth adding even if you don't use them on day one. They support the answer-first structure covered in our guide to writing pages AI engines can quote.
How do you model case studies and integrations?
Model case studies with separate fields for the customer, industry, challenge, approach and results, and integrations as their own collection with a name, logo, category and description. Linking the two lets each case study show the integrations involved and each integration page show related stories.
Case study fields: customer name, logo, industry reference, company size, a one-line headline, challenge, approach, results text, a quote with a reference to a testimonial entry, product features used and the SEO group. Keeping results as their own field lets you show them on cards and in sliders without copying text.
Integration fields: name, slug, logo, category, short description, a longer body for setup steps, a link to documentation and a list of related case studies. Integration pages often rank for searches combining your product with another tool's name, so a clean, consistent template matters more here than almost anywhere else on the site.
How should changelog and team pages be modeled?
Model changelog entries as dated records with a title, a type such as new, improved or fixed, a short summary, an optional body and references to product areas. Model team members with a name, role, photo, short bio, department and links, so the same records feed the team page and author bylines.
- Changelog entry: date, title, type, product area reference, summary, body, optional image or video, link to docs.
- Team member: name, role, photo, short bio, department, order, social links, and whether they appear on the team page.
- Author link: if team members also write, connect the author record to the team member instead of duplicating.
For example, suppose a startup launches an integrations directory
For example, suppose a SaaS startup has 30 integrations listed as plain text on one page. The team creates an Integrations collection with name, logo, category, summary and setup body fields, and a Categories collection with entries like CRM and analytics.
The design team builds one integration page template and one directory page with category filters. Case studies get a new field referencing integrations used. Now each integration has its own URL, the directory filters itself, and adding a new integration is a five-minute task for marketing instead of a developer request. When the team later adds languages, the same structure carries over, as covered in our multilingual website guide.
What are the most common content modeling mistakes?
The most common content modeling mistakes are one giant rich-text field, fields named after layout, copied text instead of references, missing SEO fields and modeling for features nobody will publish. Each one makes the CMS harder to use or harder to change later.
List what you publish
Write down every type of content you'll publish in the next six months and how often. Model only those.
Define fields by use
If you'll filter, sort, reuse or display a piece separately, give it its own field.
Find the shared pieces
Anything that appears in more than one place, such as authors or testimonials, becomes a referenced collection.
Add the SEO group everywhere
Use the same SEO fields on every public type, with sensible fallbacks.
Test with real content
Enter three real entries per type before building templates. Awkward fields show up immediately.
If you're moving platforms, don't copy the old model as-is. Our guide to content modeling for CMS migrations covers how to clean it up on the way, and CMS content migration covers the export and import itself. For a production example, see setting up Payload CMS for a marketing site.
