Content Model First: Designing a CMS Schema That Survives Growth

A CMS schema is easy to design when you only have a few pages. The problem appears six months later, when marketing wants landing pages that look different, support needs a knowledge base, and your product team asks for “just one more content field.”

Most teams respond by adding fields wherever there is room. It works until it does not: templates become fragile, content becomes inconsistent, and “simple changes” turn into migrations.

This post lays out a content model first approach. Instead of starting from pages and layouts, you start from the stable concepts you publish, define clear boundaries, and make room for change without letting the CMS devolve into a junk drawer.

Why CMS schemas fail in practice

CMS projects rarely fail because the technology is weak. They fail because the schema is built around the first set of pages rather than around the underlying content. You end up with a “Homepage” type, a “Pricing Page” type, and a “Careers Page” type, each carrying a slightly different set of fields for the same idea.

That approach creates three compounding problems:

• Duplication: the same data (like a product name or support email) is stored in multiple places and drifts.
• Coupling to presentation: fields represent layout choices (“Left Column Title”) rather than meaning (“Value Proposition”).
• Unclear ownership: nobody knows which content is canonical, so changes are risky and slow.

A healthier schema treats the CMS as a system of record for content, not a page builder that happens to store text.

Start with content types and boundaries

Begin by listing the real things your organization publishes and maintains. These are nouns that stay stable as your website design changes. Typical examples include Articles, Products, Locations, Events, FAQs, Case Studies, People, Policies, and Guides.

Then define boundaries. A boundary is a rule that says where something belongs and where it does not. Boundaries prevent the “random field sprawl” that makes schemas hard to evolve.

Choose the smallest set of types that can grow

A useful rule is: if two items have different lifecycles or owners, they probably need different types. If they have the same lifecycle and differ only in formatting, use one type with optional fields.

For example, a small B2B company might start with:

• Article (owned by marketing, updated weekly)
• Case Study (owned by sales and marketing, updated quarterly)
• Person (owned by HR, updated occasionally)
• Product (owned by product marketing, updated with releases)

A concrete example: the “everything is a page” trap

Imagine a home services company that starts with a CMS where each service page has its own content type: “Plumbing Page,” “HVAC Page,” “Electrical Page.” Each has fields like “Hero Title,” “Promo Text,” and “Testimonial.”

Later, they want to show services on location pages (“Plumbing in Westfield”). Now you need to copy the “Promo Text” into dozens of location pages, or invent ad hoc fields to reference it. A content model first design would have a Service type (with meaning) and a Location type, then a way to relate them and render different page layouts without rewriting your data.

Field design rules that age well

Once content types are clear, field decisions become simpler. The goal is to store the minimum data that stays true over time, plus enough structure to support reuse and consistency.

Practical field guidelines

• Name fields for meaning, not placement: “Summary” beats “Sidebar Text.”
• Prefer structured data when it drives behavior: use separate fields for “Price,” “Currency,” and “Billing Period” if you need them for comparisons, filtering, or formatting.
• Use rich text carefully: rich text is flexible but hard to validate. Keep it for narrative content, not for data you need to query.
• Distinguish internal identifiers from public slugs: keep a stable internal ID and treat the URL slug as editable content.
• Add constraints where editors benefit: required fields, allowed values, character hints, and examples reduce rework.

If you only adopt one habit, make it this: every field should answer “what is this” without seeing the page design.

Plan relationships and reuse

Relationships are where schemas either become a superpower or a constant headache. The trick is choosing a small set of relationship patterns and using them consistently.

Here are three patterns that work well for many teams:

• Reference: one item points to another canonical item (Article references Author).
• Collection: a list of references with an order (Landing Page lists Featured Case Studies).
• Taxonomy: shared tags or categories used for grouping and discovery (Topic, Industry, Region).

To keep relationships clear, document them as simple rules: who owns the relationship, whether order matters, and whether it is curated or computed.

Content types:
- Article
  - author: Person (reference, required)
  - topics: Topic[] (taxonomy, optional)
  - relatedArticles: Article[] (collection, curated, max 4)

- Service
  - locations: Location[] (reference, optional)
  - faqs: FAQ[] (collection, curated)

Notice what is not in that sketch: “Section 1 Title” or “Blue Banner Text.” Those are layout decisions that change frequently and should not be the backbone of your data model.

Workflow and governance for editors

A schema can look elegant and still fail if it does not match how people work. Editors need guardrails that reduce cognitive load and prevent silent inconsistency.

Design your model with these operational questions in mind:

• Who can create each type? For example, only marketing creates Articles, but support creates FAQs.
• What is the review path? Draft, in review, scheduled, published, archived. Even if your CMS does not enforce states, you can standardize labels and roles.
• What is the “source of truth”? If a phone number appears in five places, your model should be adjusted until it appears once.
• What changes require coordination? For example, renaming a Topic might affect navigation, SEO, and internal search.

A copyable checklist for schema reviews

Use this checklist any time you add a type or field. It keeps the schema intentional instead of accidental:

1. Purpose: What decision or page does this enable?
2. Owner: Who maintains this content long term?
3. Canonical source: Does this duplicate data that exists elsewhere?
4. Structure: Should this be a reference or taxonomy instead of copy-paste text?
5. Validation: What should be required, and what hints will reduce mistakes?
6. Lifecycle: What happens when this becomes outdated? Archive, redirect, or update?
7. Reporting: Will you ever need to filter, sort, or segment by this field?
8. Migration cost: If you are wrong, how hard is it to change later?

Keeping a short “schema decision log” in your internal docs helps future teammates understand why certain choices were made. If you need a starting point, your About page can link to internal standards, but the standards should live where your team actually works.

Common mistakes to avoid

• Modeling pages instead of content: Page-specific types multiply quickly and make reuse painful.
• Letting rich text carry data: If editors keep writing “Price: $99/mo” in a body field, you cannot reliably show comparisons or apply formatting.
• Overusing “generic” modules: A flexible “Content Block” type can help, but if every block is different, you lose semantics and validation.
• Creating a taxonomy without governance: Uncontrolled tags lead to near-duplicates (“HR”, “Human Resources”, “People Ops”). Decide who can create terms and how they are named.
• Ignoring deletion and redirects: Content gets removed. Your schema and workflow should account for unpublishing, archiving, and what replaces it.

A good litmus test: if two editors can fill out the same content type in two different ways and both “seem fine,” you likely need stronger constraints, examples, or field naming.

When not to do this (yet)

Content modeling is worth doing, but it can be overkill in a few scenarios:

• You are still discovering what you publish: If your offering is changing weekly, keep the model simple and avoid premature taxonomies.
• You only have one maintainer and low volume: A lightweight schema can be fine if the same person keeps it consistent and the site is small.
• You are mid-migration with limited runway: In that case, focus on the minimum model needed to ship, then iterate in a second pass.

The compromise approach is to define core types (the stuff you know will remain) and allow temporary fields or modules that you expect to clean up. The key is labeling them as temporary so they do not become permanent by accident.

Conclusion

A CMS schema that survives growth is less about predicting the future and more about protecting meaning. When content types represent real concepts, fields represent intent, and relationships are explicit, redesigns become safer and new channels become easier to support.

If you want a simple next step: pick one high-impact area (like Services, Products, or Knowledge Base articles) and refactor that model first. Success in one area creates a template for the rest.

FAQ

How many content types should we start with?

Start with the smallest set that matches distinct ownership or lifecycle differences. Many small teams do well with 4 to 8 core types and a few taxonomies. If you are creating a new type for every page, you are probably too granular.

When should we use rich text versus structured fields?

Use rich text for narrative content where formatting varies and you are not going to query it. Use structured fields when the value drives behavior, filtering, comparisons, or consistent rendering (prices, addresses, CTAs, dates, product attributes).

How do we keep tags and categories from getting messy?

Treat taxonomies like shared infrastructure. Define naming rules, limit who can create new terms, and schedule periodic cleanup. If you need both “Topics” and “Industries,” make their scope clear and avoid overlapping meanings.

What if we already have a messy schema?

Pick one domain where duplication hurts most, define the canonical type, and migrate gradually. Often you can introduce a new type (like “Service”) and update templates to prefer it, while leaving legacy fields in place until you can clean them up safely.