content modeling website
Content Modeling for a Website: A Practical Guide
Learn what content modeling is, how to build a content model for a website or app step by step, with examples, best practices and SEO fields.

Content modeling is the work of deciding what kinds of content your website or app needs, what pieces make up each kind, and how those kinds connect. You do it before you design pages. A good content model means you enter a product, a testimonial or a service once, and it can appear wherever it is needed. This guide explains the idea, walks through a six-step process, and shows how to apply it when an AI assistant builds your site.
TL;DR
- A content model is a plan: content types (page, product, author), the fields inside each (title, price, image), and the references that link them.
- Model meaning, not looks. Keep colors and layout out of your content types so a redesign does not break your data.
- Start by listing what you have and what you need, then define types, fields and relationships on paper before building anything.
- Add SEO fields (title, description, slug) to every page-like type from day one.
- With WebsitePublisher, your AI assistant builds the site from the model, and you edit content and design in the browser without regenerating pages.
Table of Contents
- What content modeling means
- Why it matters for a website or app
- The building blocks of a content model
- A simple content model example
- How to create a content model, step by step
- Best practices for flexible, reusable types
- SEO fields and multichannel delivery
- Where our approach fits
- Our perspective
- Build from your content model
- FAQ
- Sources
What content modeling means
Content modeling gives content structure and organization. According to the content modeling basics documentation from a headless CMS vendor, a content model is made of content types and fields. A content type is an outline for entries. Fields specify the data in each entry, such as a title, body text or media. Reference fields link one entry to another.
Other guides frame it the same way. Kentico’s content modeling guide describes it as organizing content, identifying attributes, and defining relationships between content types. Put simply, a model answers three questions:
- What kinds of things does this site talk about?
- What do we need to know about each one?
- How do those things relate to each other?
A bakery site might answer like this: it has products, locations and blog posts. A product has a name, description, price and photo. A location has an address and opening hours. A blog post can reference the products it mentions.
The idea is not limited to big enterprise projects. A five-page portfolio has a content model too, even if no one has written it down.
Why it matters for a website or app
The documentation for CrafterCMS lists the payoffs: consistency, reuse, scalability and collaboration. Structured content can be repurposed across platforms and channels, and it is easier to index and integrate.
In practice, that shows up in a few ways.
Consistency. Every service page has the same parts in the same order. Visitors learn where to look.
Reuse. A testimonial lives in one place. The home page, the pricing page and a landing page can all pull it in.
Faster edits. Change a phone number once, and it is right everywhere.
Room to grow. Adding a new product or a tenth landing page means filling in fields, not inventing a layout.
Channel flexibility. Kentico recommends including all content for your digital presence in the model: websites, applications, video portals and other marketing channels. If your site today becomes an app tomorrow, the content is already structured.
The cost of skipping this step is familiar. Pages are copied and pasted, details drift out of sync, and a redesign means touching every page by hand.
The building blocks of a content model
Content types
A content type is a category of content with a repeatable shape. Common examples from Brightspot’s guide are articles, products and landing pages. Think of a type as a form that every entry of that kind fills in.
Fields (attributes)
Fields are the blanks on the form. Titles, authors, dates, images and categories are typical. Each field should hold one kind of information. Do not put a price and a currency in the same text box if you ever want to sort or format them.
References and relationships
References connect entries. A blog post points to its author. A product points to its category. The Web Project Guide notes that relationships enable reuse and intelligent content management, and let content travel beyond the CMS through APIs or other data transfers.
Taxonomy
Categories and tags are the vocabulary that groups content. Decide them early, because they are painful to rename once hundreds of entries use them.
A simple content model example
Here is a model for a small business site with a services section, a blog and a store. It draws on the patterns in Prismic’s content modeling guide, where a landing page is composed of reusable hero, features and call-to-action sections, with the menu and footer managed globally.
| Content type | Key fields | Relates to |
|---|---|---|
| Landing page | Title, slug, SEO title, SEO description, list of sections | Hero, Features, CTA |
| Hero section | Heading, description, CTA label, CTA link, image | Used by many pages |
| Features section | Heading, list of feature items | Used by many pages |
| Menu | List of links | Global, one entry |
| Footer | Contact details, legal links | Global, one entry |
| Product | Name, description, price, images, sizes | Category, Reviews |
| Blog post | Title, author, publication date, body, categories | Author, Product |
The product and blog post rows follow Brightspot’s e-commerce example, which gives a product page its own fields (name, description, price, images, sizes, reviews) and a blog post a different set (title, author, date, body, categories).
Notice what is missing: colors, column counts, font sizes. Those belong to design.
How to create a content model, step by step
The sequence below follows the five-stage process in Prismic’s guide, with an extra documentation step (step 4) added.
1. Audit what you have and what you need
List every page on your current site, or every page you plan to build. Group them by shape. If five pages all have a headline, a short pitch, a photo and a button, they are the same type. If you are starting from nothing, list the questions visitors must be able to answer: what do you offer, what does it cost, how do I contact you, why should I trust you.
2. Choose the platform that can hold the model
Your tool needs to support the types, taxonomy, relationships, variations and reusable sections you just listed. If your plan has global elements like a menu and footer, check that the tool treats them as single entries, not copies. If you are weighing a traditional CMS against a headless one, our five-question comparison of headless and traditional CMS can help.
3. Define types, fields and taxonomy
For each type, write the field list. Give each field a name, a data type (short text, long text, number, image, link, reference) and a note on whether it is required. Then list your categories and tags.
4. Document the model for different readers
Sanity’s guide suggests three complementary formats: diagrams to show relationships, spreadsheets for field-level detail, and schemas for implementation. No single format serves everyone. An editor wants the spreadsheet. A developer wants the schema. A stakeholder wants the diagram.
5. Build it
Create the types and fill them with real content, not lorem ipsum. Real content exposes problems: the headline that never fits, the field nobody fills in.
6. Review and iterate
After launch, check which fields are empty, which are misused, and which requests the model cannot handle. Adjust. A model is a living document.
Kentico’s guidance stresses that editors, copywriters, marketers, strategists and architects should be involved before implementation. Even on a two-person team, ask the person who will edit the site every week what annoys them.
Best practices for flexible, reusable types
Model meaning, not presentation. Sanity’s developer guide recommends modeling for meaning because presentation differs across websites, apps and other channels. Keep colors and layout in the design layer. Then a redesign does not mean rewriting content.
Separate topics from assemblies. The patterns guidance from Contentful separates topic content from presentation-oriented assemblies. Topics carry no specific layout, so they can appear in many places. Assemblies, such as a landing page, gather topics and control layout and navigation.
Turn repeated structures into components. If a hero appears on twelve pages, it is one component with fields. Our guides on reusable web components and choosing a component library cover this in more detail.
Make globals single entries. One menu, one footer, one contact block.
Keep fields atomic. Split a full address into street, city and postal code if you will ever filter or map it.
Name things for editors. “Hero heading” beats “h1_text”. The people who use the model every day should understand it without a manual.
Do not over-model. Ten types you use beat forty you do not. Add a type when a third page needs the same shape.
Set ownership rules. Who can change a type, and who can only fill entries? Rules like these are part of AI content governance, which matters more when AI tools are drafting and editing on your behalf.
For a deeper look at structuring data for growth, read our article on CMS data modeling.

SEO fields and multichannel delivery
Structure helps search engines too. Kentico’s overview states that semantically structured content can improve search-engine indexability and understanding. Its content modeling documentation advises including relevant SEO fields in article pages and reusing articles, products, navigation and page components across marketing channels.
A practical SEO field set for every page-like type:
- SEO title
- Meta description
- URL slug
- Primary image and its alt text
- Optional: canonical URL or a “hide from search” flag
For products, add the fields visitors compare on: name, price, availability, images. For articles, add author and publication date. Because these live in fields, you can check completeness at a glance instead of opening each page.
The same logic covers landing pages, e-commerce and apps. Kentico notes that modeling supports multichannel publishing across websites, microsites, landing pages, email, social media and mobile apps. One product entry can feed a store page, a campaign landing page and an email block.
Where our approach fits
Most content modeling advice assumes you will configure a CMS by hand, then hire a developer to wire it to a front end. At WebsitePublisher, we take a different route. You describe what you want in plain language to your AI assistant (ChatGPT, Claude, Gemini and others), and the assistant builds and publishes your websites and apps through the WebsitePublisher connector. Every change is live immediately, with no separate deploy or publish step.
The content modeling ideas above map onto what the platform offers:
- Reusable components. Repeated sections such as a hero or a footer are built once and shared, so design stays consistent across pages.
- Dynamic data management. Content that repeats, such as products or posts, can be kept as data rather than hard-coded into pages.
- A visual browser editor. You change text and design directly in the browser, and you do not have to regenerate a page through the AI to fix a typo.
- Over 100 built-in integrations. Email, payments and lead capture connect without you writing the glue code.
- No lock-in to one AI session. Your project is not trapped in a single chat. You can switch between AI tools without losing the project.
Here is how you can use that in practice:
- Write your model in a short brief: types, fields, relationships.
- Give the brief to your AI assistant and ask it to build the pages and components from it.
- Review the live result and edit content in the browser.
- Ask the assistant to extend the model when a new need appears.
If your project has many pages, our guide to a multi-page website built from one brief shows how a single brief can drive every page. For product pages specifically, see our notes on AI product page design. If you are choosing between an AI builder and a traditional CMS, we compare them in our CMS versus AI website builder article. For design consistency across several products, see design systems for the web.
Our perspective
We think the model matters more than the tool. A clear list of types and fields makes any build faster, whether a person or an AI does the building. Without it, an AI assistant will make reasonable guesses, and you will spend time correcting them.
This is why we built WebsitePublisher around reusable components and data instead of one-off generated pages. When an AI generates a page as a static blob, every later change means asking for the page again, and small details drift. When the same content lives in components and data, a change in one place reaches every page that uses it, and you can make it yourself in the browser.
Our advice for anyone starting out:
- Write the model first, even as a ten-line list.
- Keep presentation out of your types.
- Reuse before you add. Ask whether an existing component can do the job.
- Treat the model as something you revise after the first month of real use.
Build from your content model
If you have a model on paper, you are most of the way there. WebsitePublisher lets your AI assistant turn it into live websites and apps, with reusable components and a browser editor for the changes that follow.
See how the AI web platform works, or check the plans and pricing to pick the one that fits your projects.

FAQ
What is a content model?
A content model is a plan for the content on a site or app. It lists the content types, the fields inside each type, and the references between them. It acts as the shared blueprint that writers, designers and developers work from.
How is content modeling different from a sitemap?
A sitemap shows which pages exist and how they are organized in navigation. A content model shows what each kind of content is made of and how kinds relate. One product type can appear on a dozen pages, and the sitemap will not show that. You usually need both.
Do small websites need a content model?
Yes, though it can be small. Even a portfolio benefits from deciding what a project entry contains: title, description, images, link, date. It takes minutes and keeps every project page consistent as you add more.
How many content types should I start with?
Start with the fewest that cover your real content, often three to six. Add a new type when you see a third page repeating the same shape. Over-modeling early creates fields nobody fills in.
Can I change the model after the site is live?
Yes. Most models evolve as needs change. Add fields before you remove them, and update existing entries as you go. Reviewing usage a month or two after launch is a good habit.
Sources
- Content modeling basics, headless CMS help center
- Content modeling guide, Kentico documentation
- Content modeling, Kentico documentation
- What is content modeling and why should you care?, Kentico
- Content Modeling, CrafterCMS documentation
- The complete guide to content modeling, Brightspot
- Content Modeling: Best Practices and How to Get Started, Prismic
- Content Modeling Guide, Sanity
- How to use structured content for page building, Sanity docs
- Content modeling patterns, headless CMS help center
- Model Your Content, The Web Project Guide
Recommended
- CMS Data Modeling: How to Structure Content That Scales
- AI Website Architecture: How to Structure Sites for AI
- Choose, Implement, Test: Component Library for Websites, for Web Teams
Build your site the same way
Describe what you want. Your AI builds and publishes it — with the full stack behind it: data, auth, forms, payments, integrations and hosting.
See how it works →
Website