Make a plan first. Go through whatever you have at the start of the project – designs, wireframes, an existing site – and identify every content type. Break those types down into fields and layouts, then map them to entry types in Craft. Most complex-site problems come from skipping this classification step and jumping straight into the control panel. Craft 5’s global entry types make this planning step even more powerful because a single content type can now be reused across sections and Matrix fields without duplication.
Every Craft CMS guide I have read explains what Singles, Channels, and Structures are. But none of them tell you how to decide between them when your site has 15 content types, 3 languages, and an editorial team that needs to publish independently. Describing the toolbox is not the same as teaching an architecture strategy.
The standard advice is “plan early, iterate, keep it simple.” That advice is not wrong, but it fails for complex sites because simplicity is a result, not a starting instruction. You do not arrive at a clean content model by trying to be simple. You arrive at one by making specific structural decisions early and getting them right.
The stakes are real. A bad content model creates cascading problems: templates get complicated, queries multiply, and content authors fight the interface instead of using it. The content model is the foundation everything else sits on. If the model is wrong, no amount of template logic can fix it.
Before you touch the Craft control panel, write the content model out. I do this by hand – literally in a notebook or typed up in a document. The goal is to understand the content and then figure out how I would build it.
Go through the designs or wireframes slowly. Look at each page, each section, and ask: what kind of content is this? What pieces does it have? Here is what that process looks like in practice.
You might look at a design and think: “This looks like a news section, so it’s going to be a section called News. It has these different pieces of content. I need fields to house those.” Then you spot something else: “It looks like this also has a callout, like a pull quote. Okay, I need to make sure I can support that.”
Then you hit a landing page. And now the question gets bigger: “Are there other landing pages I need? Well, I better look and see, because maybe I need to create a page builder for a section called Landing Pages and it’s going to have all these different content types – video, images, carousel, pull quotes, pricing chart – all these things that the content editors need to build these pages.”
Inventory all of it. Then build your sections up from that inventory in your content model. This is not glamorous work. But it is the work that separates a content model that holds up from one that falls apart three months after launch.
As Zaengle advocates, building the content model before any frontend work lets content authors begin entering real content in parallel with development. That is not just a workflow efficiency – it is a quality check on the model itself.
Once you have your inventory, every piece of content needs to pass through this filter before you create a single section in the control panel.
Stream (Channels): Content that is time-ordered, date-stamped, and grows indefinitely. Blog posts, news articles, events, podcast episodes. The test: does this content have a publish date that matters? If yes, it is a stream.
Tree (Structures): Content that has a parent-child hierarchy and a defined navigational order. Service pages, documentation sections, location directories. The test: does the position of this entry relative to other entries matter? If yes, it is a tree.
Block (Matrix / nested entry types): Content that exists as a composable piece within another entry – not as a standalone item. Hero sections, call-to-action modules, testimonial cards. The test: would this content ever need its own URL? If no, it is a block.
Singles have a legitimate but narrow role: true one-of-a-kind pages like the homepage, a global settings entry, or a 404 page. If you have more than 5-8 Singles, some of them likely belong in a Channel with a single entry. As MadeByShape notes, Singles are one of the most overused section types in Craft projects.
The Craft 5 shift changes this significantly. Entry types are now a global resource, meaning you define a content type once and deploy it wherever needed – across Channels, Structures, and Matrix fields. This eliminates the Craft 3/4 problem of recreating identical field layouts in multiple places. If you are still duplicating field layouts across sections, Craft 5’s architecture gives you a way out.
This is the single most consequential modeling decision on a complex site. Take that landing page builder example. You have video, images, carousels, pull quotes, pricing charts – all living as blocks inside the entry. But should a testimonial live inside the page entry as a Matrix block, or should it live as its own entry in a Channel with a relationship field pulling it in?
Use relationships when: - The same content appears on multiple pages (reuse) - The content needs its own URL or detail page - The content is managed by a different person or team - You need to query it independently (e.g., “show all testimonials tagged with X”)
Use nesting when: - The content is unique to that page - It has no independent identity outside the parent entry - The editorial workflow is simpler when everything lives in one editing screen
Watch for the warning signs. The HackerNoon Craft CMS principles guide recommends no more than six Matrix block types per field. When you exceed that, the authoring experience degrades and you should split content into related entries instead. That number is the canary in the coal mine for an over-nested model.
The performance implications are direct. Without eager loading, 150 related entries can generate 937 database queries versus 156 with eager loading – an 83% reduction (nystudio107 benchmark). The way you model relationships determines whether this problem even exists. ## How Do You Make Sure Content Authors Can Actually Use the Model?
Almost every content modeling article is written from the developer’s perspective. But the content model is also the editorial interface. A model that is architecturally elegant but confusing to authors is a failed model.
Run the editor test. Before finalizing a content model, have a non-developer create five real entries using it. If they need to ask questions, the model is too complex. Field labels, instructions, and entry type names are as much a part of the content model as the schema itself.
Name entry types in content language (“Featured Story”), not developer language (“hero_block_v2”). Use field instructions to explain what each field does and why it exists. Limit visible fields per entry type by using tabs and field layouts strategically – do not dump 20 fields on one screen.
The most common mistake I see is treating Craft like a page builder – stuffing everything into deeply nested Matrix structures to give authors layout control, rather than defining structured content types and handling presentation in templates. When your landing page builder has 20 block types and three levels of nesting, and content authors dread opening the control panel, the model has become the problem.
“I just do it all by hand to understand the content and then how I would build it.”
– Ryan Irelan, CraftQuest
At CraftQuest, we teach content modeling before template development deliberately. If the model is right, templates are straightforward. If the model is wrong, templates become a maze of conditionals trying to compensate.
One more thing worth noting: Craft 5’s native nesting and global entry types have eliminated many of the workarounds that older projects relied on. If your content model uses Super Table or deeply nested plugin structures to achieve what Craft 5 does natively, it may be time to refactor.
You can also bring AI into this process. Use a tool like Claude Code and ask it to look at a site and build a document – in planning mode – that converts the site into a content model for Craft. That might be a good starting point. Then you take that output and customize it using your own judgment on how the model needs to look.
This works especially well when you are working with an existing site and need to reverse-engineer the content model. The AI can inventory the content types faster than you can manually, but your experience is what tells you whether a Channel or a Structure is the right call. The AI gives you the raw material. You make the architectural decisions.
If you are starting a new project, do what I do: go through the designs slowly, write the content model by hand, and inventory every content type before you create a single section in the Craft control panel. If you are refactoring an existing model, use Craft’s Debug Toolbar to identify pages with high query counts as your starting diagnostic.
Content modeling is the foundation of everything in The Craft Mindset course at CraftQuest – it is where I spend the most time because getting the model right makes every other decision easier. If you are new to Craft entirely, start with the free Craft CMS Quick-Start Guide or our Getting Started Quest to build a working project from scratch.
There is no fixed limit, but classify each content type as a stream (Channel), tree (Structure), or standalone page (Single) before creating sections. Most complex sites land at 8-15 sections. If you have more than 20, some types likely share enough structure to be consolidated using Craft 5’s global entry types.
Use Matrix (nested entry types) for content that is unique to a single page and has no independent identity. Use entry relationships when content is reused across multiple pages, needs its own URL, or is managed by a different team. The dividing line is reusability. If a Matrix field exceeds six block types, that is a signal to split content into related entries instead.
Craft 5 made entry types a global resource, meaning you define a content type once and reuse it across sections and Matrix fields. It also introduced native Matrix nesting and began the “entrification” of categories and tags. These changes reduce duplication and simplify complex models significantly.
Check three indicators: (1) your Matrix fields have more than six block types, (2) content authors need training to create basic entries, and (3) your page query count exceeds 50 (check with the Debug Toolbar). Any of these signals a model that needs simplification.
Yes, but it requires careful migration planning. Craft’s migration system lets you restructure sections, move entries between types, and reorganize fields. The content data is preserved – you are reorganizing how it is stored and accessed, not deleting it. Plan refactors in a staging environment and test thoroughly before deploying to production.