cms data modeling

CMS Data Modeling: How to Structure Content That Scales

Learn CMS data modeling step by step: content types, fields and relationships, four content model examples you can copy, and best practices that scale.

CMS data modeling, also called content modeling, is the work of deciding what kinds of content your site or app holds, which fields each kind has, and how the kinds connect. Do it before you build. A clear model lets you change a price, add a team member or launch a new page type without rebuilding anything. A weak model gives you pages that are hard to update and content you can’t reuse.

This guide is for freelancers, small business owners, marketers and agencies who build websites and apps. It covers the building blocks, four content model examples you can copy, the rules that keep a model healthy, and how the model maps to what you build with WebsitePublisher.

TL;DR

A content model has three parts: content types (what things exist), fields (what you store about each), and relationships (how the things link).
Model meaning, not looks. Decide what a testimonial is before you decide how it looks on a page.
Model small, reusable pieces instead of whole pages, and keep nesting shallow.
With WebsitePublisher, your AI assistant builds websites and apps from a described model, and every change is live immediately.
To build one: list your screens, pull out the nouns, add fields, draw the links, then test with real content.

What is CMS data modeling?
The three building blocks of a content model
Four content model examples
Content modeling best practices
How to create a content model in five steps
Our perspective: a model is a contract between you and your AI assistant
From model to live site with WebsitePublisher
Headless, traditional or something simpler
Mistakes to avoid
FAQ
Sources

What is CMS data modeling?

In web development, CMS means content management system, and data modeling is usually called content modeling. Contentful describes it as structuring information into content types, their attributes and their relationships, so the same content works across websites, apps and APIs. That is the meaning this guide uses.

The term has a second meaning. In US government work, CMS is the Centers for Medicare & Medicaid Services. Its data teams follow formal procedures for logical and physical data models. The agency’s own data model procedure calls for IDEF1X notation. If you need claims data or payment model data, start at cms.gov, not here.

The three building blocks of a content model

Content types

A content type is a kind of thing your site talks about. Common ones: article, product, service, team member, testimonial, event, location. If you would describe it with a noun and could have more than one of it, it is probably a type.

Fields

Fields are the facts you store about each item. An article might have a title, a slug, a summary, a body, a publish date and an image. A product might have a name, a description, a price, a stock status and photos.

Pick the narrowest field that fits. A date should be a date, not free text. A price should be a number, not a sentence. Narrow fields let you sort, filter and format consistently.

Relationships

Relationships say how items point to each other. One author writes many articles. One category groups many products. One testimonial belongs to one service. Store the link once and every page that needs it can follow it, instead of you retyping the same name in ten places.

Examples of content items and their relationships

Four content model examples

The tables below are starting points. Trim fields you will not use. Add fields only when a real page needs them.

Example 1: Freelancer portfolio

Content type	Key fields	Relationships
Project	Title, slug, summary, year, role, cover image, gallery, project URL	Belongs to one or more Skills; has zero or more Testimonials
Skill	Name, short description	Used by many Projects
Testimonial	Quote, person name, person role, company	Belongs to one Project
Profile	Name, headline, bio, photo, contact email	None

Why it works: the home page shows three featured projects, the work page shows all of them, and a skill page lists every project that used that skill. Same data, three views.

Example 2: Local service business

Content type	Key fields	Relationships
Service	Name, slug, description, duration, image	Has many FAQs; has many Testimonials
Location	Name, address, opening hours, phone, map link	Offers many Services
Team member	Name, role, bio, photo	Works at one or more Locations
FAQ	Question, answer	Belongs to one Service
Lead	Name, email, message, requested service	References one Service

Why it works: change opening hours once on the Location and every page showing them stays correct. The Lead type reminds you the site also collects data, not just displays it.

Example 3: Small online store

Content type	Key fields	Relationships
Product	Name, slug, description, price, images, stock status	Belongs to one Category; has many Reviews
Category	Name, slug, intro text	Contains many Products
Review	Rating, text, reviewer name, date	Belongs to one Product
Order	Customer, items, total, status	References many Products

Why it works: category pages, search results and the cart all read the same Product records. Payments are handled through an integration, so you model the order record, not the payment mechanics.

Example 4: Blog or content hub

Content type	Key fields	Relationships
Article	Title, slug, summary, body, cover image, publish date, SEO title, meta description	Written by one Author; tagged with many Topics
Author	Name, bio, photo	Writes many Articles
Topic	Name, slug, description	Applies to many Articles
Call to action	Heading, text, button label, link	Reused across many Articles

Why it works: the call to action is its own type. Update it once and every article that uses it changes. If you are starting a blog, our guide to launching a blog in one session with AI walks through the workflow.

Content modeling best practices

Model meaning, not appearance

It is tempting to create a type called “Homepage hero with blue background.” Resist it. Deane Barker’s chapter on content modeling makes the case that a CMS has to know what your content is, much like you cannot build a box without knowing the size of the thing going in it. Name the type for what it is (a headline and a supporting image), then let the front end decide how it looks. Design changes then never force a content migration.

Model pieces, not pages

A common mistake is making every page a type of its own, which makes content hard to reuse. Contentstack’s guidance advises modeling components that repeat across pages, such as headers, footers and calls to action, separately so you can reuse them. Amplience makes the same point: content modeling means turning the types of content on your site or app into structured components you can manage and retrieve through APIs.

A quick test: if the same piece appears on two pages, it should be one item referenced twice.

Keep nesting shallow

Deep hierarchies can mirror your business accurately and still be miserable to edit. Prepr’s best practices point out that over-nesting forces editors to click through many layers for a simple update, which slows work and invites mistakes. Aim for two levels where you can: a parent and its direct children.

Start from the experience

List the pages, screens and flows first. Then ask what content each one needs. This keeps you from modeling data nobody will ever display.

Name things plainly

Use the words your team and clients already use. “Testimonial” beats “SocialProofEntry.” Plain names matter more when a client edits the content later.

How to create a content model in five steps

List the screens. Write down every page type and every repeated section: home, service, product list, contact.
Pull out the nouns. Each distinct thing becomes a candidate content type. Merge duplicates (“client quote” and “testimonial” are one type).
Add fields. For each type, list what you must show and what you must filter or sort by. Choose the narrowest field kind for each.
Draw the links. For every pair of types, ask: does one belong to the other? One-to-many or many-to-many? Write it in a sentence, such as “One author writes many articles.”
Test with real content. Enter five real items per type. If any field is empty or awkward, fix the model now, before you have 500 items.

Our perspective: a model is a contract between you and your AI assistant

At WebsitePublisher, your AI assistant (ChatGPT, Claude, Gemini and others) builds and publishes websites and apps through the WebsitePublisher connector (MCP). That changes what a content model is for.

When a person builds in a visual tool, a vague model gets patched by hand. When you describe a site to an assistant in plain language, the model is the instruction. “A portfolio with projects, skills and testimonials, where each project lists its skills” is a better prompt than “make me a portfolio,” because it names the types and the links. Clear structure in, clear site out.

We built WebsitePublisher around that idea. It uses a data-driven approach with reusable components, so you can update content and keep a consistent design across a project instead of regenerating pages. A visual editor in the browser lets you change text and visuals yourself, so you are not locked into one AI session. And because you can switch between AI tools without losing project context, the model you describe stays yours, not the property of one assistant.

Our advice is simple: write the model down in a short note before you prompt. Types, fields, links. Five minutes of planning replaces an afternoon of rework. For the reuse side, see our guides on reusable web components and versioning and choosing a component library.

From model to live site with WebsitePublisher

Once you have a model, here is how it plays out on WebsitePublisher:

Connect your AI assistant to WebsitePublisher.
Paste your model note and describe the pages, for example: “Build a service business site with Service, Location, Team member and FAQ types, and a contact form that saves leads.” Your assistant stores each content type as structured data (entities) with your fields and links, so every page reads from the same records.
Review the result. Every change is live immediately, so there is no separate deploy or publish step.
Fix text and visuals in the browser editor, or ask your assistant for structural changes.
Add what the site needs from the 100+ built-in integrations, such as email, payments and lead capture.

WebsitePublisher builds websites and apps, so the same model can drive a marketing site today and a web app later. If you want to see what is possible, browse the portfolio of sites built with AI. When you are ready to start, the plans, including a free one, are listed on our pricing page.

Headless, traditional or something simpler

Some teams model content in a headless CMS and build a separate front end. Others use a traditional CMS where content and templates live together. Both work, and both ask you to run a CMS and often a developer workflow too. If you are weighing them, our five questions for choosing headless or traditional help you decide. If you mainly need to ship quickly, our comparison of a CMS versus an AI website builder for small businesses covers the trade-offs. Whichever route you pick, the modeling steps above stay the same.

Headless, traditional or something simpler — overview diagram

Static or dynamic is a related choice. A brochure site with five pages needs little structure. A catalog, a blog or an app needs a real model. Our piece on static versus dynamic websites gives three clear calls.

Mistakes to avoid

One giant “Page” type with fifty optional fields. Split it into pieces that can be reused.
Storing formatted text where data belongs. A price typed as “from about $20” cannot be sorted or filtered. Use a number field and show the wording in the design.
Duplicating the same fact. Phone numbers, opening hours and team bios belong in one record, referenced everywhere.
Modeling for a design you may redo. Design changes often. Meaning changes rarely.
Skipping real content. A model that looks neat on paper often breaks the moment you paste in your real copy.
Forgetting future channels. If the content may feed an app, a newsletter or another site later, keep fields free of layout assumptions.

FAQ

What is the difference between a data model and a content model?

A data model describes any stored information, including orders, users and logs. A content model is the part that covers what your audience reads and sees: articles, products, pages and media. On most small sites the two overlap, so one note covering both is fine.

How many content types does a small site need?

Usually four to eight. A portfolio often needs only project, skill, testimonial and profile. If you pass ten types on a small site, check whether some are the same thing under different names.

Can I change my content model after launch?

Yes, but it is easier early. Adding a field is simple. Splitting or merging types means moving existing content, which grows more tedious with every item. Test with real content before you publish widely.

Does CMS data modeling relate to Medicare and Medicaid data?

Only by name. The federal agency CMS publishes datasets and maintains its own formal modeling procedures, which you can find on cms.gov. The web practice described here is about structuring content for websites and apps.