You're on a kickoff call. The client says they need a website. You ask what kind of content they'll manage. They say "just like, pages and stuff."
And that's when you know you're about to spend three days reverse-engineering what "pages and stuff" actually means before you can write a single API call.
Content modeling is one of those skills nobody really teaches. You learn it by getting burned — by building the wrong schema, migrating data at 2am, or watching a client try to fit a press release into a "blog post" content type and wonder why nothing looks right.
Here's a practical guide to doing it right.
What Is a Content Model, Actually?
A content model is the blueprint for how your content is structured — what types of content exist, what fields they contain, and how they relate to each other.
Think of it like a database schema, but designed for editors who don't think in rows and columns.
A blog post content type might have:
- Title (short text)
- Slug (auto-generated)
- Author (reference to an Author content type)
- Body (rich text)
- Tags (list of strings)
- Published date (date/time)
- Featured image (media) Simple enough. But things get complicated fast when you add landing pages, product listings, testimonials, FAQs, pricing tables, and localized content.
Step 1: Start With the Output, Not the Input
Most developers start by asking "what data do we need to store?" That's the wrong question.
Start with: "What does the front end need to render?"
Open the design mockups. Identify every piece of text, image, or dynamic element. That's your content model. Work backwards from the UI, not forwards from assumptions about what the client will want to manage.
Step 2: Group by Editorial Intent, Not Visual Layout
A hero section and a feature section might look similar in the design but be managed very differently. Maybe the hero changes seasonally. Maybe the features are curated by the marketing team and rarely touched.
Don't create one "section" content type just because they look similar visually. Create types based on how editors will think about them.
Step 3: Decide What Gets Referenced vs. Embedded
Here's where most content models fall apart.
If an author appears on multiple blog posts, they should be a referenced content type — one Author entry linked to many posts. If you embed the author's name and bio directly in each post, you'll be updating it 40 times when they change their title.
References = reusable. Embedded fields = one-off.
The rule of thumb: if it appears in more than one place, reference it.
Step 4: Plan for Localization Now, Even If You Don't Need It Yet
If there's any chance the content will be translated, build the model with that in mind from day one.
Nothing is more painful than retrofitting a localization layer onto a content model that assumed everything is in English.
The AI Shortcut
Building a content model from scratch is still a multi-hour exercise even if you know what you're doing.
Contensa lets you describe what you're building in plain English, and it generates the content model for you — fields, types, references, all of it. It's not a replacement for understanding what you're doing, but it dramatically accelerates the scaffolding phase.
For agencies running back-to-back projects, that kind of time saving compounds fast.
Content Modeling Checklists Are Your Friend
Before you finalize any model, run through this:
- Every content type maps to a clear editorial use case
- References used wherever content is reused
- Field names are consistent (don't mix title, name, heading for the same thing)
- Required fields are actually required, not just assumed
- Localization strategy is defined
- Media fields have format/size guidance
Getting the content model right upfront is the highest-leverage thing you can do on any CMS project. The more clearly you define the structure, the less time you spend on migrations, workarounds, and client re-education later.
Top comments (0)