• What is Content Modeling?

Content Modeling

Content Modeling is the process of defining content as structured data - naming the types of content you publish, the fields each type contains, and the relationships between them. Sits underneath every CMS and every content platform that scales beyond a couple of writers shipping random posts.

Most teams skip it and hand-craft each post in a WYSIWYG editor. That works until someone wants to reuse the same FAQ across three product pages, or syndicate articles to a partner, or change the byline format on 400 archived posts. Then content modeling becomes the thing the team should have done two years ago.

The pieces of a content model

Three things make up the model:

Content types. Article, product page, case study, glossary term, author bio. Each is a distinct shape with its own purpose. A glossary term and a blog post are not the same content type even if they both produce a URL.

Fields per type. A glossary term has: term name, slug, definition, related terms, JSON-LD. A blog post has: title, hero image, author, body, tags, published date, last updated. Defining the fields up front means the CMS can enforce them and downstream systems (search, sitemap, schema) can rely on them.

Relationships. A blog post has one author. An author has many blog posts. A glossary term links to other glossary terms. These connections turn flat content into a navigable graph.

Where teams get the model wrong

Two common patterns:

Modeling for current content instead of intended use. Writers tell you what fields they currently fill in. The model captures that. Six months later someone wants to reuse content in an email and discovers the right fields don’t exist. Model the use cases, not the legacy.

Over-modeling. The opposite mistake - defining 40 content types when 6 would do. Every type the team has to learn is a type someone gets wrong. If a “case study” and a “customer story” are functionally the same thing, they’re the same type.

An example

An SEO agency taking on a client with a 600-post WordPress blog needed to migrate everything to a headless CMS for a site relaunch. The existing posts had no consistent metadata - categories were used inconsistently, some posts had author bios in-body, some had tags doing the work of categories, schema was applied ad-hoc.

The agency spent week one defining a content model: 5 content types, average 8 fields each, 3 relationship types. Week two was migration mapping (what existing field becomes what new field). Week three was the actual migration with structured fallbacks for missing data. Result: a site where the next content audit takes 2 hours instead of 2 weeks because everything is queryable.

The painful version skips the model and ships in 2 weeks. The painful version then spends 4 weeks every year wrestling with content that doesn’t have the structure to support whatever the team now wants to do with it.

We built Penfriend to respect content models - the structured templates an organisation uses to produce consistent pieces. Penfriend generates against the model rather than inventing ad-hoc structures, which is how content teams scale without losing brand coherence.

Related terms