Content modeling process overview

✖
Copy to clipboard

Content modeling is the process of defining the structure of your content before you build anything in a digital experience platform (DXP), like Xperience by Kentico, or in another content management system (CMS) your team uses to create, store, and publish content.

It means deciding which content types your organization needs (such as articles, products, events, or testimonials), what fields each content type contains, and how they relate to each other.

Done well, a content model describes what your content is, not how it looks. That distinction matters because content tied too closely to its presentation becomes hard to reuse the moment you need it somewhere else, whether that’s a new page layout, an email campaign, a product microsite, or a mobile app.

A well-defined content model creates a scalable structure that lets teams reuse content across channels and outlasts redesigns or technology changes.

Building such a model requires preparation, part of which is to recognize that no two teams have the same needs. Reaching for a generic, one-size-fits-all model or having an AI generate a boilerplate one can feel like a shortcut. But that shortcut usually turns into a costly mistake.

A model works best when it’s shaped around your specific situation. Take into account:

  • Your team’s size
  • The data you work with
  • The channels your content needs to reach
  • How often does your content change
  • The editorial workflows your team relies on

Mistakes in the content modeling process tend to surface later, either as inconsistent content, missed reuse opportunities, different teams managing the same content in conflicting ways, or a model so fragmented that everyday editing becomes a chore.

For example, breaking content into highly reusable fragments can backfire when that content only ever appears on your website. Editors end up piecing together a single page from many small components, turning a simple task into a needlessly complex one.

We’ll cover how to avoid pitfalls like these as we go.

The content modeling process itself is largely independent of any particular CMS. The core content types won’t change regardless of the CMS you’re using, so the generic content model should work. You can find examples of content types at Schema.org.

But once you start building the model for Xperience by Kentico, a number of platform-specific decisions and tools come into play.

Rather than treating these as two separate processes, we’ll walk through them as a single flow and mark the point in each phase where the discussion shifts from general principles to something specific to Xperience. That way, if you’re evaluating the process independent of any platform, you’ll know exactly which parts still apply. And if you’re already committed to Xperience, you’ll know where to pay closest attention.

At the end, you’ll find a practical checklist for whoever will drive the process day-to-day.

Who should be involved in the content modeling process

A content model isn’t something one person designs in isolation and hands to everyone else. Depending on the structure of your organization, you may want to involve several roles to cover different angles of the process:

  • Senior content creators and editors, who understand the day-to-day realities of producing and maintaining content.
  • Marketers, who can explain how content needs to work across campaigns and channels.
  • Business analysts, who help ensure the model fits business standards and operational needs.
  • Developers, who confirm the model is technically feasible and scalable.
  • Designers, who define how content will be laid out and presented, and make sure the model supports the brand’s design framework.
  • Project or product managers, who keep the process moving and tie it back to business goals and timelines.

Brin in the stakeholders who represent these roles early, and revisit their input as your understanding of the specific situation deepens. Content modeling rarely happens in a single meeting. More often, it’s a series of structured, collaborative sessions, and the number and topics of those sessions depend on your organization’s size and complexity.

Why this matters

A content model affects nearly everyone who touches the content. If you design it without one of these perspectives, you tend to discover the gap late. For instance, when developers find a structure that can’t be built as drawn, or when editors find the day-to-day experience painful. Involving the right people early is far cheaper than reworking the model later.

Phase 1: Content model discovery and analysis

Before you start defining content types and building them in Xperience’s UI, you need a clear picture of three things:

  • What content already exists? Take stock of everything you have today.
  • How is that content used? Is the same content reused across several channels, such as a website and email campaigns, or is it specific to one channel?
  • What does each channel require? Different channels ask for different things, such as the raw content, a specific layout, or both. We look at this in section Analyze what each channel needs.

The discovery and analysis phase is almost entirely CMS-agnostic. The work here would look much the same whether you were about to build on Xperience or any other platform.

Think of this phase as gathering the raw material for every decision that follows. The better you understand the current situation, the fewer surprises you’ll hit once building begins.

Gather stakeholder interviews and requirements

Meet with content creators, marketers, developers, and store managers to understand how content is created and used today, and where the current pain points are.

The aim of these conversations is to capture two things side by side: what your content is today, and what you want it to do in the future model. That way, you make sure the new model is built around real goals rather than just a tidier version of the present one.

What your content is today

  • Every content type currently in use, so you have a complete inventory to work from.
  • How that content is created, managed, and published today, including the steps people find slow or frustrating.
  • What each channel currently needs from your content.
  • Which content is reused across channels versus tied to a single one.

What you want to achieve

  • The experiences you want each channel to deliver.
  • The business goals and key performance indicators (KPIs) each channel should support.
  • Content you’d like to reuse, personalize, or introduce that isn’t possible today.
  • Any content migration requirements, like the existing content you’ll need to bring into the new model (covered in its own section below).

It helps to make these questions concrete. Ask, for example, which content drives the most engagement on each channel, or what data about your content you wish you had but currently don’t.

Expect to revisit these interviews with different stakeholder groups as your understanding deepens, because this step is rarely a one-and-done conversation.

Why this matters

The people who work with content every day know things no document captures, like which steps are painful, which content never gets reused, which content people are engaging with the most, or where the same information gets re-entered in three different places.

Surfacing that knowledge now is what stops you from faithfully rebuilding today’s problems inside a shiny new system.

Audit your existing content

Catalog the content you already have across every system in use, and look closely at how it’s structured, the metadata attached to it, and how it’s categorized.

Metadata is information about your content that helps people and systems find, organize, and make decisions about it. Some of it describes the content itself, such as a title, author, tags, or publication date.

But metadata also captures what a piece of content is for. It tells you:

  • Which persona is it aimed at.
  • Where it sits in the customer journey or sales funnel.
  • Which specific channels is it created for.
  • Where is it reused.
  • How well it’s doing (in its engagement or conversion rates, for example).

A useful way to think about metadata is that it represents everything you know about a piece of content other than the content itself.

The audit phase is where you’ll typically uncover content duplication and gaps, so review the full content lifecycle – the stages a piece of content moves through, from creation and approval to publishing and eventual archiving – and document which pieces of content you have and how they’re actually used.

A thorough audit often reveals content types you hadn’t accounted for, which is completely normal. You can feed everything you learn here back into your stakeholder interviews.

Why this matters

You can’t model content you haven’t taken stock of. An audit almost always turns up the same information living in several places in slightly different forms, which is exactly the inconsistency a good content model will help you eliminate. Finding inconsistencies now, on your terms, is much easier than discovering them after you’ve built your content model.

Analyze what each channel needs

For every channel you plan to support – website, email, mobile app, and any other – work out what that channel needs from your content. Some need both the data and the presentation of your content (like a website channel), while others need only the data (a headless channel).

Channels that only need data don’t display content stored in your platform. Instead, they pull raw content into a separate application, such as a mobile app or a digital display. The content is thus delivered through an API (a way for two software systems to request and exchange data).

For example, suppose you want product details to appear inside a mobile app. You first establish what the app should do – show each product’s name, price, short description, and image, and let shoppers filter products by category. Only once that’s clear can the team translate it into technical requirements, such as which fields the app requests and how filtering works. The what it should do always comes first and drives the how it’s delivered.

Here’s the key planning point of this step, and it’s one business users are well placed to lead: decide what you want the content to do on each channel before anyone works out the technical side.

This is also the point to determine your personalization and localization needs (both defined in the next step), and to map out requirements for responsive and adaptive layouts for content reformatted to fit phones, tablets, and desktops, as well as accessibility for users with disabilities.

Why this matters

Channels have genuinely different needs, and a model that quietly assumes “everything is a web page” will fight you the first time content has to go somewhere else. Detailing each channel’s needs now keeps the model flexible enough to cover different types of content delivery and management.

Plan how your editors will govern content

Describe your content guidelines and style guides, set publishing schedules and versioning strategies, and clarify your localization and content personalization needs.

Localization, or adapting content for different languages or regions. For example, publishing your homepage in English, German, and Japanese, or showing prices in the local currency.

Content personalization, or showing different content to different visitors based on who they are or how they behave. For example, greeting a returning customer by name, showing a first-time visitor an introductory offer, or presenting a loyal customer a loyalty reward.

Document the editor teams and groups on the stakeholders’ side, too, since governance decisions later in the process (such as who approves what) will build directly on the ground rules you lay out today.

Why this matters

Localization and personalization both place real demands on the content model. If you want content in three languages, the model needs to support language variants from the start. If you want to greet returning customers differently, the model needs a place to store those variations. Deciding this now, rather than adding it on later, saves painful restructuring down the line.

Phase 2: Content modeling and architecture

With discovery complete, you move from understanding your content to defining its structure. This is the heart of the process. The decisions you make at this stage will shape how easily editors work and how far your content can travel for years to come.

Identify your content types

Define the core content entities your organization produces, such as articles, products, or events, and identify which are shared across channels versus which are specific to one channel. Map the relationships between content types, and define the hierarchies and taxonomies they’ll exist within.

Why this matters

Your content types are the vocabulary of everything you’ll build. Naming content types clearly and deciding early which are shared versus channel-specific prevents a tangled mess of near-duplicate types that nobody can make sense of later.

Define your taxonomy and relationships

This step is conceptual design work, and it applies no matter which CMS you eventually build your content model in. You decide how your content is categorized and how the pieces connect.

A taxonomy is a structured way of categorizing content, a system of tags and categories, much like the sections and labels that organize a library.

A controlled vocabulary is an agreed, fixed set of terms that everyone uses, so one editor doesn’t tag something “Beginner” while another writes “Intro level” for the very same thing. Establishing naming conventions here keeps your content consistent and findable.

You’ll also map how your content types relate to one another. There are three basic kinds of relationships:

  • A one-to-one relationship connects a single item to exactly one other. For example, each product links to a single specification sheet that belongs only to that product.
  • A one-to-many relationship connects one item to several others. For example, one author can be credited on many articles, while each article still has a single primary author.
  • A many-to-many relationship connects items freely on both sides. For example, an article can carry several tags, and each of those tags can also appear on many other articles.

This is also where you establish parent-child hierarchies, map content dependencies, decide how content types will reference and link to each other, and identify the metadata you’ll need for search, filtering, and findability.

Why this matters

Getting these relationships right is what later lets editors reuse content instead of recreating it. If you model an author content type as properly linked and reusable, rather than retyping a name on every article, updating an author’s bio once updates it everywhere. Miss that, and you’ve signed your editors up for endless manual copying.

It’s worth calling out that the step of defining your taxonomy and relationships is distinct from building your taxonomy and metadata in Xperience as detailed below.

First, you’re deciding what your taxonomy and relationships should be, independent of any system. The next step is about building that decision into Xperience.

Build your taxonomy and metadata in Xperience

Once you know what vocabulary and relationships you need, you can create them as actual taxonomy objects and tags and define the semantic and functional taxonomies your stakeholders identified as requirements. You can represent such taxonomies and controlled vocabulary in Xperience’s Taxonomies feature, for example.

At this stage, you’ll also create or define the metadata fields on the content types themselves that support search, filtering, and findability.

If you’re modeling content that maps well to common patterns, Schema.org (a shared vocabulary of over 800 type definitions) is a useful reference point for the properties usually associated with the types you’ve identified.

Xperience’s reusable field schemas – such as a shared Core Content schema – let you apply that vocabulary consistently across multiple content types, so you define a common set of fields once and reuse it rather than rebuilding it type by type.

Choose a content structure: page-based or atomic

This is one of the most consequential decisions in the entire process, and it’s specific to how Xperience stores and delivers content. You’ll break each content type down into granular fields and components, decide on field types (text, rich text, media, references, and so on), and decide how content will be reused across channels.

Xperience gives you two broad approaches towards content modeling:

  • Page-based content, where content lives directly on website pages with their own URLs and layout. This suits straightforward, web-centric, visually driven projects well.

  • Atomic (reusable) content, where each piece of content is stored once, independent of any channel, in the Content hub, and then wrapped with channel-specific details (such as SEO information) wherever it appears. Atomic simply means the content is broken into small, reusable building blocks. For example, you store a product’s details once, and you can display that same product on its website page, in an email campaign, and in your mobile app. Change the price once, and it updates everywhere it’s used.

Many projects use a mix of both models, depending on the content type. Atomic modeling gives you more reuse and consistency, but it asks more of your editors up front. Composing a page from several linked, smaller content items feels different from editing everything in one place, so budget time for editor training if you go this route. A page-based content model is simpler to reason about but harder to reuse once you need the same content somewhere else.

Whichever approach you land on, define your reusable content components for storage in the Content hub, their presentation components per channel, and any metadata schemas needed for SEO, analytics, or personalization. That includes meta-fields for things like custom activity logging or tag manager routines, if your organization uses them.

Why this matters

This single choice shapes how much your editors can reuse and how much duplicate work they’ll face for years to come. Choosing atomic content when you truly need multi-channel reuse saves enormous effort later. Choosing it for a simple one-website project can add complexity you don’t need.

It’s worth making a deliberate decision rather than defaulting to an unsuitable model.

Map your content across channels

Create the presentation logic and rules that connect your content types to channels, widgets, and templates, and map which fields each channel actually uses.

For example, a product’s full description might appear on its website page, while the same product in an email uses only its name, price, and image, and the description field isn’t pulled in. Mapping this behavior tells everyone exactly which fields each channel relies on.

Also note any channel-specific overrides, where one channel deliberately shows something differently from the default.

A product headline might read “Premium Wireless Headphones – Now 20% Off” on the website, but a space-limited email subject line overrides it with a shorter “Headphones – 20% off.” The stored content is the same; the channel just overrides how it’s presented.

This is also the point to validate how personalization will work across channels, including page widgets, calls to action, and individual points in the customer journey.

Why this matters

Mapping field usage per channel prevents two common problems – building fields nobody uses, and discovering too late that a channel needs a field the model never included. It’s the bridge between what content we have and how each channel actually shows it.

Phase 3: Model validation and refinement

Before your developers begin building a content model, you should validate the model with the people who will actually be using it. It’s far cheaper to fix a model on paper than it is to fix one after you’ve already built it.

Run content model review sessions

Review works best in stages: first on paper, then hands-on. Reviewing the model as a concept catches structural problems early and cheaply, while letting stakeholders interact with a working prototype surfaces the practical friction a diagram can’t reveal.

  1. Review the identified content types and workflow. Present the model to stakeholders at a level of detail that helps them engage with it, whether through detailed descriptions, sketches, wireframes, or mind maps. Walk through real use cases and content entry scenarios, validate the model against existing editorial workflows, gather feedback to identify gaps, and agree on must-have content types. Tailor the format to your audience, because each of these approaches brings useful insights in different ways.

  2. Prototype the content types in Xperience. Ask a solution architect or a developer to build the agreed content types in Xperience, and make these available in a shared environment. The technical team member will use a tool such as Xperience’s Management MCP server to put together a working prototype that every stakeholder can click through and try out.

  3. Have stakeholders click through the prototype. Ask stakeholders to create a few sample items using the prototyped content types and to walk through their everyday tasks. A quick, hands-on test like this is one of the fastest ways to catch an awkward or overly complicated content type before it’s built for real.

Why this matters

A model can look perfect on a diagram and still be painful to use in practice. Letting real editors try it, even roughly, surfaces the friction while it’s still cheap to fix.

Facilitate stakeholder sign-off

Document the agreed model and get formal sign-off from stakeholders before moving into implementation. This is a checkpoint where everyone should agree that the model covers all the content types the organization produces, the relationships between them, the data and structure each content type stores, and each content type’s lifecycle.

Why this matters

Sign-off turns a shared understanding into a shared commitment. It gives the build team a stable target and gives stakeholders a clear moment to raise concerns before, rather than after, the expensive work begins.

Phase 4: Content model implementation

Prototype and test your content model

With the model reviewed and signed off, the next step goes beyond a quick click-through prototype. Create detailed wireframes that show your content in different contexts, and break the prototyping work into trackable tasks, whether that’s Jira tickets, a Trello board, or whatever project management tool your team already uses.

Ask your solution architect or developers to build a proof-of-concept directly in Xperience in the form of real content types with skeleton widgets and templates using the Management MCP server. This is the most reliable way to validate a model, so make sure you don’t skip this step, if possible.

Test your content workflows with real users and real content. Work with content creators to ensure that editors can add, update, and publish their content smoothly. Use sample content from each of your digital channels and verify that your data assembles correctly.

For example, make sure that Related articles block automatically pulls the three most recent articles sharing the same tag, or a listing page that gathers every product in the Sale category displays the required products as you expect.

You also need to ensure that editors can easily find the content that they need to update. And if your business goals require it, validate that your content is deliverable properly through your headless and email channels.

Why this matters

If the model doesn’t store the right information – a category tag, or fields for the content item asset types – the system has no way to find and assemble that content correctly. Testing these retrieval patterns during prototyping is far cheaper than discovering the gap after launch, when fixing it may mean re-editing every affected item. Expect to iterate based on what you learn.

Build your content types in Xperience

Developers implement the content types exactly as defined in the model and orchestrate content migration, while content editors – often on the partner or client team – begin working on content, or content migration in parallel. Stakeholders should stay involved here, reviewing real content as it’s added into Xperience rather than waiting until the content modeling process has finished.

Why this matters

The first real content entered into a new model is the ultimate test of it. Keep stakeholders focused on real content as it lands, and ensure small problems are caught and corrected while they’re still small.

Define governance and workflows

Define your content approval workflows in Xperience. A workflow describes the lifecycle a content item moves through, often starting with a Draft step and ending when the content item or page is Published, with as many custom review steps in between as your process needs.

Define the roles and permissions that control who can work with which content at each step, and set up the users. Validate your setup by creating sample content types and moving content items through the workflow.

Keep the final workflows as lightweight as possible while still functioning as intended. A simple three-step draft, review, and publish process is often more effective than an elaborate, multiple-step approval chain.

Why this matters

Workflows are how quality and accountability get built into everyday work rather than left to memory. A brief, straightforward workflow prevents both the chaos of no review and the gridlock of too much.

Document your content model’s technical specifications

This might be a technical part of the process, but it still hinges on business decisions. At this stage, a solution architect or a project manager of the implementation team documents how different channels will consume your content and any requirements that affect how quickly and reliably that content needs to be delivered. You or a business owner will provide sign-offs on how the model should be implemented in Xperience by Kentico.

Document channel content needs

For each channel, the solution architect documents which content types it uses and which fields it needs. For example, a website product page might display the full product description, while a mobile app displays only the product’s name, price, image, and availability.

The goal isn’t to define the technical implementation, but to give developers a clear picture of which content each channel depends on and how that content will be used.

Why this matters

Different channels rarely need exactly the same information. Documenting these requirements helps ensure the content model provides everything each channel needs, without creating unnecessary fields that nobody uses.

Agree on performance expectations

Not all content has the same delivery requirements. Some content changes frequently and needs to be updated quickly, while other content can remain unchanged for long periods.

For example, a homepage promotion may need to reflect updates within minutes, while a legal disclaimer might remain unchanged for months. Likewise, stakeholders may expect product pages to load quickly even during periods of unusually high traffic.

Why this matters

Documenting and agreeing on these expectations beforehand helps developers choose the right performance and caching strategies when implementing the solution.

If this is a multi-phase project, you’d also outline the migration approach for later phases here.

Migrate content

Migration doesn’t always fit neatly into a single phase. Depending on your project, it can run in parallel with implementation or form its own distinct stream of work, especially for larger projects that are delivered in phases. Wherever it sits on your timeline, the core tasks remain the same:

  • Map your legacy content to the new model.
  • Define the data transformation rules that will get it there.
  • Build the migration scripts and processes to carry it out.

Plan a phased rollout rather than a single cutover where the project allows. A migration split into several steps gives you room to validate as you go, rather than discovering problems after you’ve moved everything.

If budget or timeline pressure forces a conservative first pass – such as a lift-and-shift migration, meaning you move your existing content into the new system largely as-is, without restructuring it to take full advantage of the new model – you don’t have to treat that as a permanent state. An expand-and-contract approach lets you progressively convert content into the new structure after the fact, without disrupting editors while you do it.

Why this matters

Rushing everything across as-is can carry your old problems into the new system, so it helps to treat migration as a real design task, not just a copy-and-paste.

Post-launch: Keeping the model alive

A content model is never really finished. Your content strategy will keep evolving as your team learns what works, and the model will have to evolve with it.

Evaluate your model and iterate

After the project’s launch, review how the model is performing, gather feedback from the content creators who use it daily, and analyze content usage patterns to identify optimization opportunities.

Why this matters

The assumptions you made during design are tested in the real world once the content is live. Checking in deliberately, rather than only when something breaks, lets you improve the model on your own schedule.

Grow your model without breaking it

Resist the temptation to let editors work around a model’s limitations by adding styling directly to the shared content. That styling would inevitably follow your content wherever it was reused.

Instead, give editors room to do that in a contained manner. On a specific page, they can fine-tune how content looks within a rich text widget, for example. That allows editors to style content just as they need it, without such tweaks affecting the shared content model behind it. It’s a healthy compromise that keeps editors happy and the model clean.

What to avoid is letting those page-level workarounds creep into the model’s global definitions. When editors keep using the same tweak, that’s a sign the model itself needs to evolve.

The recommended approach for evolving an Xperience content model safely is expand and contract, which follows three key steps:

  • Add the new structure alongside the old.
  • Migrate your content across.
  • Remove what’s deprecated, only after you finish the first two steps.

By following this strategy, you avoid changing a content type all at once while people are actively using it, which prevents disruption. Agree with stakeholders up front on how you’ll handle requests to change content types once the project has launched, so this doesn’t become an ad hoc decision made under pressure.

Why this matters

The risky moment in any change is the switchover. Expanding first and contracting last means there’s never a point where editors are left with a half-changed, broken content type in their hands.

Document your content model

Teams document content models in all sorts of text-based tools (like spreadsheets, or Word and Google documents), or diagramming tools (Miro, FigJam, and others). There’s no single right answer. The best tool for your specific case depends on your team’s size, the complexity of your content, your collaboration needs, and how well the tool fits your existing workflows.

Whatever tool you choose, using a shared vocabulary helps standardize your content types, both for the people managing content and for the systems that consume it (such as AI agents or search engines). Schema.org is the most common source of inspiration for such a vocabulary, since it already defines widely recognized properties for common content patterns.

Practical checklist of a content modeling process

The following checklist provides a quick reference for owners driving the content modeling process, roughly in the order of use.

Before you start:

  • Confirm which roles are represented on the content modeling task force, including at least one voice from the content, marketing, business analysis, development, and design teams.
  • Schedule stakeholder interviews and block time for a full content audit.
  • Confirm which channels are in scope, and note any that will need headless delivery.

During discovery:

  • Document every content type currently in use, along with known pain points.
  • Capture business goals and KPIs per channel.
  • Note migration requirements as they come up, even if migration itself is a later-phase concern.
  • Record governance basics: style guides, publishing schedules, versioning, and localization needs.

While defining the model:

  • Define core content entities and their relationships before deciding on field-level detail.
  • Decide, per content type, whether page-based or atomic (reusable) content is the better fit.
  • Build out taxonomies and metadata fields in Xperience once the conceptual taxonomy is agreed upon.
  • Map how each content type behaves across every channel it needs to appear on.

Before building anything:

  • Run at least one content model review session with stakeholders, using sketches or wireframes.
  • Have a few stakeholders create sample content items against the proposed model.
  • Get documented sign-off before implementation begins.

During implementation:

  • Break prototyping work into trackable tasks.
  • Build a proof-of-concept in Xperience where the timeline allows.
  • Define workflows, roles, and permissions before content editors start working at scale.
  • Document API schemas, caching strategy, and delivery requirements for developers.

After launch:

  • Schedule a review of model performance, ideally within the first few months.
  • Set up a lightweight process for handling change requests, using an expand-and-contract approach rather than one-off fixes.

Further resources