Every Drupal site eventually forces the same conversation: what kinds of content does this site actually contain, what does each kind carry with it, and how do the kinds relate to each other. Content modeling is the discipline of answering those three questions on paper before they get answered accidentally in code. Sites that model first are cheaper to build, cheaper to extend, and kinder to their editors; sites that skip it spend their second year paying interest on decisions nobody remembers making.
This introduction stays deliberately practical. It defines the four building blocks, walks one worked example from an everyday domain, and ends with the questions a client or developer should ask before any modeling session. If your goal is presenting a model inside a portfolio case study, continue afterwards with our content model storytelling and the Drupal case study template; the modeling here is the substrate both of those build on.
The Four Building Blocks
Content types are the kinds of things a site publishes — an event, a news article, a staff profile, a product. Naming them is a strategy act, not a technical one: “Event” versus “Things happening” versus “Posts (we use for everything)” are three different content philosophies with three different futures. Fields are the pieces each type carries: an event has a title, a date, a venue, a description, maybe a registration link. Field choices shape editing screens for years, so they deserve the same care as visual design. Taxonomies are shared vocabularies that cut across types — topics, audiences, regions — and they answer the browse-by questions the site will actually face. References are the relationships: the event that names its venue, the article that names its author, the product that names its series. References are where models earn their keep, because they turn “pages with similar content pasted in” into a structure the site can query, filter, and reuse.
Two rules keep the vocabulary honest. Model the content, not the page: a content type that exists because a mockup had a slot in it will haunt the editing experience forever. And model fewer types than feels necessary: three well-designed types outperform nine overlapping ones almost every time, because editors can hold three in their heads and cannot hold nine.
A Worked Event-Site Model
Take a community organization’s site that lists events, profiles organizers, and publishes recaps. The naive version makes one “Page” type and pastes everything in. The modeled version looks like this.
| Type | Fields | References |
|---|---|---|
| Event | Title, date, venue name, description, registration link | Venue, Organizer, related Recap |
| Venue | Name, address, capacity, access notes | — |
| Organizer | Name, role, short bio, photo | — |
| Recap | Title, event date covered, body, photos | Event |
The payoff compounds quietly. A venue’s address changes once, in one record, and every event at that venue updates. An organizer page assembles itself from the events they organize. A year of recaps filters by topic without anyone tagging pastes. None of this required a module, a budget line, or a developer after launch — it required the model to exist before the build. The recaps-to-event reference is the kind of decision that takes ninety seconds on a whiteboard and ninety hours to retrofit.
Where Models Go Wrong
Three failure patterns account for most painful Drupal content models, and all three are avoidable at design time. The page-driven type is the most common: a mockup shows a layout with a hero, a sidebar, and a strip of cards, and the model becomes Hero, Sidebar, and Cards — types that mean nothing to the organization and everything to one expired design. The mega-type is the second: one Event type that tries to serve concerts, conferences, and workshops by accumulating forty optional fields, so every editor faces a form where thirty-five fields do not apply and the five that do are scattered among them. The ghost relationship is the third: venues, organizers, or topics that exist as free-text fields in a dozen places instead of one referenced record, so the site cannot answer the browse-by questions its visitors actually ask.
Each pattern has the same root cause: the model was derived from presentation or convenience instead of from the content itself. The worked example above avoids all three — types named for organizational reality, fields limited to what items genuinely carry, and venues as records rather than strings — and the six questions below are designed to surface each pattern before it hardens into structure.
Questions To Ask Before Modeling Anything
Six questions surface most of what a model needs to know. What are the five kinds of content this site publishes most? For each, what pieces does it genuinely carry — and which of those repeat across items? Who edits each kind, and what will they tolerate? What does a visitor want to browse by — and is that a taxonomy or a reference? Which content must appear in more than one place, and in what relationship? And the honesty question: which of these types are actually the same thing wearing different labels?
Answered together, usually in one facilitated hour, these six produce a model solid enough to build on and light enough to change. That facilitation skill — designing the model with a client rather than presenting one to them — is also exactly what belongs in a portfolio case study, which is why the editor experience case study pairs the practice with the proof. For builders who arrive from the maintenance side, our sibling site’s guide to content model cleanup before a redesign applies the same vocabulary to sites whose models were never designed at all. And for canonical definitions, the official Drupal documentation remains the reference the whole ecosystem’s vocabulary descends from.