Digital experiences are driven by content - the messaging of an organization used to promote its ideas, products, and services. This content performs best when it has a consistent tone, style, and voice for an audience across experiences and channels.

A marketer's ability to author and govern content successfully is directly connected to its underlying content model and the tools used to discover, compose, and publish.

It's a connection that pays off in real terms:

“A well-structured content model directly impacts how efficiently a marketing team can create, reuse, and publish content. When content is modeled correctly, marketers spend less time hunting down inconsistencies, duplicating work, or waiting on developers to make structural changes. That time savings translates directly into ROI.”

Brian McKeiver
Brian McKeiver Co-Owner, BizStream

In this article, we build on that foundation with the expertise of Kentico's Community Leaders and MVPs, who share lessons from real-world Xperience by Kentico projects - from running a content modeling exercise with stakeholders, to balancing today's strategy against future opportunities, to features like taxonomies and reusable field schemas.

We close with a look at AI's impact on content operations, and why a well-structured content model - and the ROI it drives - will outlast any individual management experience.

Start with the people, not the content

At a high level, there are two approaches to content modeling:

  • Design-first: let the design of the experience drive the content model

  • Content-first: work out the content model and craft the design to adapt it to each experience

Design-first is more intuitive because teams immediately have something tangible to work from. It can also be faster in traditional web-centric projects.

In a multichannel world, or even one where content is adapted for reuse across a single channel, it can cause problems. Teams can end up with, at best, an awkward fitting content model and at worst, costly rework.

However, our experts agree there's work to be done even before content is modeled or a single content type is defined. The most important question isn't "what content do we have?" It's "who is going to create, manage, and live with this content every day?"

We have to consider the stakeholders and content marketing strategy first.

The goal isn't just to produce a content model. It's to produce a model that content marketers understand and feel ownership of from day one.

With stakeholders involved, teams can actually start the content modeling process. What does this look like? It often depends on two things:

  • The context surrounding the project
  • The experience level of the marketing team

It doesn't matter which tools you use, as long as they allow people to engage with the concepts and practices of content modeling. Why is stakeholder buy-in such an important requirement? As we will see, every step from here considers the marketer's experience with the content they author.

Simple or scalable: finding the balance editors will actually live with

Every content model sits somewhere on a spectrum between simple and scalable.

  • Simple models: fast to author in and easy to understand, but they don't flex well under growth, new channels, or new requirements.
  • Scalable models: handle complexity gracefully, but they ask more of the editors who work in them every day. Neither extreme serves a team well.

The practitioners we spoke with have all navigated this tradeoff, and the consensus is that the authoring experience has to be the tiebreaker: a technically elegant model that editors work around, ignore, or resent has already failed.

Mike Wills learned this the hard way on a headless implementation that looked right on paper:

The decision between design-first and content-first modeling, mentioned earlier, echoes here. Going design-first felt intuitive for Mike's team - it mapped to the independent design components of the presentation experience.

It's worth reflecting that the realization of a mismatch came from actually authoring content with this model as a marketer would. Architects and developers are often responsible for crafting the final content model. Clearly, trying the content management experience themselves is a very useful, early validation test.

The lesson isn't that scalable models are wrong. It's that scalability has to be validated by the people who will author in it, not assumed by the people who designed it.

To complicate matters further, optimizing for a great content authoring experience has its own pitfalls. We asked our experts "Do the authoring experience and long-term management experience compete with or complement each other?"

The tension between simplicity and scalability doesn't appear to have a clear answer, which might be disappointing to some. But, as we'll later see, even if we struck the perfect balance today, changes in technology and marketing strategy will require future adjustments anyway.

The evolution of a model is just as important, over the long term, as its initial design.

What belongs in the Content hub?

The guidance so far has focused on content. But, what about information that looks and feels more like data?

Navigation, error messages, form labels, rates feeds, configuration values: some of these are things customers see and interact with, others live in the background adding nuance to the experience.

Drawing a clear line between content and data early in a project keeps the Content hub from becoming a catch-all and keeps the authoring experience clean for the people who actually need it. It also ensures marketers get the content governance features they rely on when they need them.

So, how do we decide if something is content or data? The clearest test is editorial intent.

Does the author review, approve, and publish it?

Do they expect the following features to be available for managing it?

If the answer is yes to any of these, treat it as content.

Trevor Fayas offers a complementary framing that applies beyond the content/data question, extending to how individual fields and schemas are designed:

“There is a distinction between what something IS and what it HAS, and if it's something that it HAS that may change - best to put that as a separate content item, or as a reusable field schema, so you can easily pivot. What something IS should always remain the same.”

Trevor Fayas
Trevor Fayas Owner, The Physics Classroom

Once the content/data line is drawn, the next decision is where within the platform something belongs: channel-specific content, the Content hub, or a custom object type. Most of our experts default to content types and reusable content, only choosing other options when the use-case is clear.

Navigation sits at an interesting edge of this question. It's channel-specific, it's designed by developers, but marketing teams update it regularly and expect the same governance as any other published asset. It's clearly content, but where is it managed?

There's clearly a fine line when traditional content crosses over to raw data and vice versa. If in doubt, look to the marketer's workflow and feature requirements as the best signal for the answer.

Modeling for reuse and channel readiness

Most Xperience by Kentico projects start with a single web channel. That's the reality for the majority of implementations, and there's nothing wrong with optimizing for it. The risk isn't starting single-channel; it's building in a way that makes adding a second channel unnecessarily expensive later.

The smallest multichannel preparation steps at the start of a project carry asymmetric value: low cost to implement, high cost to retrofit. Reusable content types, a clear content/data boundary, and the habit of asking 'does this content exist anywhere else?' pay forward without significantly burdening the initial build.

It's clear everyone is taking a pragmatic approach, or at least has some well refined heuristics to help decide when content should be designed as reusable.

Channel-specific (e.g. web pages) is still the default, but these Kentico experts fully understand when to model with reusable content.

So, what about the actual tactics?

  • When content needs to be adapted to a specific channel to express a message or create an engaging experience, how is this accomplished?

  • Is it better to wrap the content in channel-level configuration or allow some duplication of the content directly in the channel experience?

The answer is clear here as well:

  • Don't duplicate content to make it better fit a specific channel.

  • Design the content model to be reusable and content-focused (not presentation-centered).

  • The channel can offer a wrapper, through widgets or a channel content type, to enhance the content for that channel's unique experience.

Taxonomy as a Key Content Modeling Tool

Taxonomy is one of those features that looks essential in planning and underused in practice. Teams invest time defining tag structures during content modeling, then six months after launch find half the tags untouched, editors are ignoring the ones that remain, and several content types are missing taxonomy altogether.

The difference between taxonomy that works and taxonomy that doesn't usually comes down to one thing: whether it powers something editors and marketers actually use and can see working.

Ben Quinlan treats the use (and therefore, value) of taxonomies as an ongoing concern that can be solved with tools and audits. This investment pays off because a well functioning taxonomy strategy is so important to a usable content model.

“We've built managed reporting processes with clients to regularly review taxonomy usage, identify orphaned or underused tags, and consolidate where it makes sense. Marketers are the primary users of taxonomies on our projects, so keeping them clean and meaningful directly impacts how effectively they can discover, organise, and reuse their content. A well-maintained taxonomy isn't just a technical nicety; it's what makes the Content hub actually work as a hub.”

Ben Quinlan
Ben Quinlan Principal Consultant / Director, Zeroseven

The question of how many taxonomies to maintain, and how broadly to apply them, generates varied answers among our practitioners. The consensus leans toward multiple focused taxonomies over a single sprawling one, but with discipline about where each is applied.

Taxonomy was traditionally created for the customer experience, but in Xperience by Kentico it was designed to support two audiences: the marketers who use it to organize and discover content internally, and the end users and search engines that encounter it as structure on the site. The best content model uses taxonomy to serve both.

The dual purpose of taxonomy becomes an increasingly important discussion point as search evolves. Taxonomy aligned to real-world concepts rather than internal naming conventions is now a signal search engines (SEO) and AI models (GEO) use for entity recognition and content classification.

One of the biggest differences from legacy Kentico solutions is that taxonomy is now its own structured content - translatable, designed to serve multiple purposes, and applied to content as one or many fields.

This makes taxonomies extremely flexible and powerful. It's clear from our experts' insights that taxonomies should be a non-negotiable part of every content model no matter how you decide to implement them.

Reusable field schemas: composability over inheritance

Diving deeper into the tactical implementation of a content model brings us to reusable field schemas.

This is easily one of the most consequential structural improvements in Xperience by Kentico relative to earlier versions of the platform. In Kentico Xperience 13, content types inherited fields from a single parent type: you got everything the parent carried whether you needed it or not, and composing multiple sets of fields wasn't possible.

Reusable field schemas replace that hierarchy with composition: you define schemas around domain concepts and apply them to content types as needed.

So, are they just a different way of thinking about designing content types or are they genuinely better than the inheritance model of the past?

The composition available to architects designing content models is the most exciting aspect of reusable field schemas. But, they also bring quality of life benefits to both developers and marketers.

For marketers and content authors, the benefit is consistency: fields behave the same way across content types, which reduces training overhead and builds familiarity with the system over time.

The benefits of reusable field schemas are clear. So, what about implementations?

  • How many schemas is the right number for a project?

  • Should schemas include many fields or just a few?

  • What are real-world examples for reusable field schemas?

Mike's team has taken schema composability one step further, building a custom module that allows field labels within a reusable schema to be overridden per content type: the same underlying schema field can be called "page title" on one type and "event name" on another, giving editors context-appropriate language without forking the schema.

“Additionally, we created a custom module that allows us to customize field labels and explanation texts for reusable field schema fields. So, for example, if we have a reusable field schema that provides a page title and page description field, that page title can be called something else in the marketer's content form when it's used on an event page. The page title could be called event name. It's helping us get the best of both worlds and optimize sites for performance.”

Mike Wills
Mike Wills Vice President of Technology, BlueModus

Reusable field schemas are a novel type of content modeling tool in Xperience by Kentico. They represent semantic concepts which can be composed, improving both developer and marketer experience.

Some use cases are obvious - SEO and web page metadata - but others surface only as the content patterns emerge when you map out your model.

The model that works today will need to evolve

Zooming out from tactics and back into planning, here's one of the most liberating things a team can internalize early in a project:

The content model you build today will not be the content model you run in three years. Business goals shift. Marketing strategy changes. New channels arrive. AI reshapes how content is consumed. A model that accounts for this isn't a compromise; it's a realistic foundation.

This is especially visible in migration and upgrade projects, where the temptation is to carry everything forward. The more productive instinct is to treat the migration as an opportunity to rethink what actually needs to come with you, and to set expectations with clients early about what that means for scope and cost.

The same expectation-setting applies to greenfield projects, though the risk runs in the opposite direction: over-engineering for futures that may never arrive. The right approach brainstorms for the future without being held hostage by it, and revisits the model regularly once the site is live.

Everyone in the digital marketing space has seen the demands of web content evolve before our eyes over the past year with the expansion of traditional SEO into GEO for AI-powered search.

We already touched on this topic in the context of taxonomy, but we didn't consider all the existing content models created before this technology shift.

Can a web page-centric content model designed 10 years ago accommodate the needs of marketers trying to optimize for GEO? Unlikely. But, it would also have been impossible to plan for this scenario back in 2015. Change is inevitable in everything - content models included. We can't throw out our content model and rebuild it from scratch each time the landscape shifts.

Gradual evolution is the only solution that balances the demands of today against the needs of tomorrow.

Safely evolving a content model with Expand and Contract

Modern DXP solutions are ever evolving, and Xperience by Kentico is no different. How can teams manage changes in content models that require breaking changes without impacting business continuity and manage growing system complexity?

Looking to the Future: Structure outlasts the UI

Across every section, one theme holds: the marketer's ability to craft and govern content is a function of the underlying content model. A model built around people, kept evolvable, and grounded in reusable structure isn't just cleaner architecture—it's what lets a marketing team move quickly and confidently.

We opened with Brian McKeiver's point that a well-structured model translates directly into ROI. That connection only deepens with AI in the picture.

What happens when it's no longer the marketer typing every message, selecting each linked content item, or applying individual taxonomy tags? We've all seen how AI is transforming the workflows of every knowledge worker, content management included.

  • If AI can instantly author, iterate, and improve content for us, do we still need to invest in an underlying structure?

  • Will the content model lose its importance?

  • Can all content just collapse back into presentation-centered web pages and email messaging?

If anything, the opposite is true. Because of AI's strengths (speed) and weaknesses (reasoning within deep context), the content model matters more, not less. A well-structured model becomes the context AI agents work from, aligning their output with business goals.

Investing in a well-designed content model today builds the foundation for AI agents to have a greater impact tomorrow - at lower cost and higher reliability. Structure outlasts the UI, and as Brian put it at the outset, that structure is where the ROI lives.