Content Modeling 101: How to Structure Your CMS Before You Publish a Single Page

The rebuild nobody wants to do

Eighteen months after a municipal website launched, the web team discovered a problem that had been quietly growing since day one. Their news posts, service announcements, public notices, and staff updates were all stored in a single "post" content type, distinguished only by a freeform "category" text field that 11 different editors had filled in however they felt: "News," "news," "news post," "City News," "Corporate Update," "staff," and about 40 other variations on the same four or five concepts.

Filtering the homepage to show only public service announcements meant manually reviewing every post in the database. Building a news archive that separated by type was impossible without a data cleanup project that would take weeks. And because all these posts had been published under a single URL pattern, any restructuring would require a redirect map and a crawl to find every page that linked to them.

The team wasn't incompetent. They'd made a common first-timer decision: launch first, structure later. The structure never came, and 18 months of content accumulated on top of a foundation that couldn't support what they needed it to do.

Content modeling is the work you do before any of that content gets created. It is the set of decisions that define what kinds of content your site will contain, what information each kind carries, how content types relate to each other, and how editors will navigate and filter them. Done well, it makes your CMS feel like a tool built for your specific organization. Done poorly, or skipped entirely, it makes your CMS feel like a place where content goes to get lost.

Here is how to do it properly before you publish a single page.

What content modeling actually is

A content model is a structured description of your content. It answers four questions:

What kinds of things does this site publish? (Content types)

What information does each kind of thing carry? (Fields)

How are those things categorized and organized? (Taxonomies)

How do those things relate to each other? (Relationships)

Content modeling is not the same as designing page templates. A page template is how content looks. A content model is what content is. The distinction matters because the same content often needs to appear in multiple contexts: a staff member's bio might appear on a team page, in the author field of a blog post, in a contact directory, and in a search result. If that bio is modeled as a field inside a page template rather than as its own content type with defined fields, it lives in one place only and has to be manually duplicated everywhere else.

Content modeling is also not the same as information architecture (IA). IA defines how users navigate the site: what's in the menu, how pages are organized, how users find things. A content model defines the underlying data structure that the IA navigates. Both are necessary. They inform each other. Content modeling comes first, because the IA should reflect what content you actually have, not guess at it.

Step 1: Inventory your content before you model it

Before you can define your content types, you need to know what content you're actually going to publish. This is not an abstract exercise. Pull together every category of content the site will need:

Every type of page (service pages, event listings, staff profiles, news articles, policy documents, FAQs, location pages, forms)

Every type of recurring content that will be created and updated over time (not just the launch content)

Every type of content that needs to be reused across multiple pages or contexts

For each item on your inventory, ask: what information does a human reader need from this content? What information does the site need to display, filter, or link it correctly? What information do editors need to create and maintain it?

A service page, for example, needs content for the human reader (what the service is, who it's for, how to access it). It also needs structured data for the site (which department owns it, what its status is, whether it has seasonal availability, what related services exist). And it needs editorial metadata (when it was last reviewed, who is responsible for keeping it current).

Write these down in a simple table. They become your field list in the next step.

Step 2: Define your content types

A content type is a category of content with a consistent structure. "News article" is a content type. "Staff profile" is a content type. "Service page" is a content type. A generic "page" with a title and a big text editor box is not a content type — it is the absence of a content model.

How to identify distinct content types

Two pieces of content should be separate content types if they:

Have meaningfully different fields (a staff profile needs job title and department; a news article needs a publication date and author; an event needs start/end times and a location; none of these overlap enough to share a single type)

Serve different user purposes (someone searching for an event has different needs than someone looking for a staff contact)

Need to be displayed differently in different contexts (events appear in a calendar view, news appears in a chronological feed, services appear in a directory filtered by category)

Are created and maintained by different people or processes (communications creates news articles, HR maintains staff profiles, each department maintains their own service pages)

The goal is the minimum number of content types that fully describes your content without collapsing genuinely different things into one type or splitting similar things into needlessly separate ones.

Common content types for organizational websites

For a municipal website or similarly structured organizational site, the core content type set typically looks like this:

Service: The core unit of an organizational website. Fields: title, description (plain text summary), body (full detail), department (relationship to Department type), status (active / seasonal / archived), related services (relationship to other Service entries), contact (relationship to Staff Profile or Contact type), last reviewed date, responsible editor.

News / announcement: Time-bound published content. Fields: headline, summary (for feeds and search), body, publish date, expiry date (after which the post is archived automatically), category (controlled taxonomy — see Step 3), author (relationship to Staff Profile), related services (relationship).

Event: Date-specific content. Fields: title, description, start date/time, end date/time, location (relationship to Location type or free text), registration link, category, department, status (upcoming / cancelled / past).

Staff profile: Reusable contact reference. Fields: name, title, department (relationship), phone, email, photo, bio (optional). The key property: this is a content type, not a field inside other content types. When a staff member's phone number changes, you update it once.

Location / facility: Physical addresses and associated details. Fields: name, address, phone, hours of operation (structured, not free text), accessibility features, map coordinates, associated services (relationship).

Document / resource: Downloadable files with associated metadata. Fields: title, description, file (upload), file type, publish date, expiry date, department, related service (relationship). Never just a PDF upload widget — the metadata is what makes documents findable and maintainable.

FAQ item: A discrete question-and-answer unit. Fields: question, answer, category (taxonomy), related service (relationship). Modeled separately so FAQ items can be pulled into service pages, grouped into dedicated FAQ sections, or surfaced in search results individually.

The temptation to under-model

The most common modeling mistake is creating a single flexible "page" type with a rich text editor and then using it for everything. This feels flexible. It is actually the opposite of flexible, because you can't do anything structural with content you can't distinguish from other content. You can't filter news by date if the date isn't a structured field. You can't build a staff directory if employee names are embedded in paragraph text. You can't relate services to the departments that own them if department is free text in a WYSIWYG editor.

Every piece of information that has a structural purpose (filtering, sorting, displaying in a specific way, relating to other content) needs to be a field, not embedded in body text.

Step 3: Define your fields carefully

Once you have your content types, define the fields for each one. For every field, decide:

Field type: What kind of data is this? Plain text, rich text, date, number, boolean (yes/no), file upload, image, URL, relationship to another content type, or a controlled vocabulary (taxonomy)?

Required or optional: Will this content be incomplete or unfindable without this field? If yes, make it required.

Single or multiple: Can this field hold one value or many? A news article has one publication date. A service page might have multiple related services.

Validation rules: Does a date field need to reject dates in the past? Does a text field have a character limit for display purposes? Does a URL field need to reject internal links (because those should be relationships, not strings)?

Choosing between rich text and structured fields

Rich text (a WYSIWYG editor) is appropriate for content that genuinely needs formatting freedom: the main body of a long-form article, detailed instructions, content with embedded lists and subheadings. It is not appropriate for content that has structural significance: dates, names, phone numbers, status values, categories, or any information the site needs to display selectively or filter by.

A common mistake: using rich text for a "description" or "summary" field on a content type that will be displayed in feeds, lists, and search results. Rich text descriptions are unpredictable in length, may contain formatting that breaks outside the context of a full page, and can't be truncated cleanly by the CMS. Use a plain text field with a character limit for short descriptions. Reserve rich text for body content.

Field naming conventions

Name fields for what they contain, not where they appear. "Summary" is better than "homepage-excerpt." "Publish date" is better than "date-appears-in-feed." If a field name assumes where the content will appear, it will cause confusion when the content appears somewhere new.

Step 4: Build your taxonomies

A taxonomy is a controlled set of terms used to categorize content. "Controlled" is the important word: editors choose from a predefined list, rather than typing whatever they like. This is what prevents the 40-variation category field problem described at the start of this post.

Taxonomies vs. free text vs. relationships

Use a taxonomy when: content needs to be grouped by a category that applies across content types, the number of valid terms is finite and stable, and editors should not be able to create new terms without a deliberate decision to expand the taxonomy.

Use a free text field when: the information is unique to each piece of content and doesn't need to be used for filtering or grouping.

Use a relationship (to another content type) when: the categorization entity itself has its own attributes that may appear in the content. Department isn't just a label — it has a contact, a mandate, a set of associated services. Model it as a content type and relate other content types to it. Don't make it a taxonomy term.

Core taxonomies for organizational websites

Content categories: High-level thematic groupings that apply across content types. Keep this list short (5-10 terms) and meaningful to users, not to the organization's internal structure. "Public safety," "permits and licensing," "parks and recreation," "planning and development" are user-oriented. "Corporate services," "Office of the CAO," "Strategic initiatives" are org-chart-oriented and rarely meaningful to external users.

Audience: Who the content is primarily for. "Residents," "businesses," "visitors," "staff." Useful for filtering and for surfacing relevant content in audience-specific entry points.

Content status: Editorial lifecycle stage. "Draft," "in review," "published," "needs review," "archived." This is distinct from a published/unpublished boolean. A page may be technically published but flagged as "needs review" because it hasn't been reviewed in 18 months. That status drives the editorial workflow, not the visibility workflow.

Geographic area: For organizations serving multiple areas, wards, or districts. Only add this taxonomy if it's genuinely meaningful for filtering. Don't add it speculatively.

Taxonomy governance

Every taxonomy needs an owner and a change process. When an editor needs a term that doesn't exist, who has the authority to add it? What's the process? Undisciplined taxonomy expansion recreates the free-text problem in a slightly more structured form.

Document your taxonomies, their terms, and the definitions of each term before the CMS is configured. Definitions matter: "public notice" and "public announcement" sound similar but may mean different things in your organization's publishing practice. Write the definition down so editors can use terms consistently.

Step 5: Map your relationships

Relationships connect content types to each other. They are one of the highest-value structural decisions you make in content modeling, and one of the most commonly skipped.

A relationship field on a Service content type that points to a Department content type means:

You can display the department name, contact, and mandate on a service page without duplicating that information

You can list all services belonging to a department on the department's own page, automatically

When a department's contact information changes, you update it in one place and it updates everywhere

Without the relationship, you have a department field that is free text, manually maintained in each service entry, with no guarantee of consistency or any way to query "which services does Department X own?" without reading every service entry manually.

Relationship types to define

For each relationship, decide:

One-to-one: Each service has one responsible department. Each news article has one author.

One-to-many: A department has many services. An author has written many news articles.

Many-to-many: A service can appear in multiple categories. A category can contain multiple services.

Also decide: is the relationship bidirectional? If a service relates to a department, does the department automatically display a list of its services? Or is that a separate query? Some CMS platforms handle this automatically; others require you to configure it explicitly on both ends.

Step 6: Document the model before you build it

Once you've worked through your content types, fields, taxonomies, and relationships, document the model before anyone touches the CMS. The documentation doesn't need to be elaborate. A spreadsheet with one sheet per content type, showing field names, field types, required/optional status, and notes about validation or display, is sufficient.

This documentation serves three purposes:

CMS configuration reference: The person building the CMS (whether that's you, a developer, or a platform admin) can implement the model accurately without having to make interpretation calls.

Editorial training resource: When editors join the team, the content model documentation tells them what each content type is for, what fields are required, and what the taxonomy terms mean. Without it, editors learn the CMS by trial and error and often arrive at different interpretations.

Governance record: When someone wants to add a new field or a new content type in six months, the documentation is the baseline for the conversation. "We already have X for that purpose" or "this is distinct enough from X that it warrants its own type" are conversations you can only have rationally if the original model is written down.

The signs your content model needs a rethink

Even a well-designed content model will need revision as the site matures. These are the signals that revision is overdue, not optional:

Editors regularly work around the model (pasting content into rich text fields because the structured fields don't accommodate what they need)

The same information appears in multiple places and gets out of sync (a phone number in a staff profile, copied into four service pages, updated in one place but not the others)

New content types are being created to handle edge cases that the original types should cover with one additional field

Filtering and search are returning unhelpful results because taxonomy terms have proliferated without governance

A major new content need (a new service area, a new publication type, a new audience segment) can't be accommodated without touching the URL structure of existing content

The cost of reworking a content model after significant content has been published is high. The cost of doing it right before content is published is a few days of structured thinking and documentation. That math makes a compelling case for doing it first.

If you're about to launch a new site or migrate to a new CMS and haven't mapped your content model yet, get in touch for a content modeling session that produces a documented type library and field specification your development team can build from immediately.