Store content

About this guide

Where to store your content

This material explains the options for creating, storing, categorizing, and managing reusable content available in Xperience by Kentico.

Up to this point, we’ve focused on general principles of content modeling that apply to many platforms. Now, we’ll look specifically at how Xperience stores content so you can make informed decisions for your project.

Before building your Xperience project, you should evaluate how the system stores content. The business use cases you identified during your content modeling sessions will help you choose the most suitable approach for storing and organizing the data.

Xperience delivers content through channels and doesn’t allow for tapping directly into reusable content storage and retrieving it. You need to consider your distribution strategy before you decide where and how to store your project’s content.

Digital content and marketing channels

Marketing channels refer to platforms, tools, and strategies businesses use to communicate with their end consumers, suppliers, partners, and other business entities. In Xperience, a channel represents the platform where you deliver your content to customers, such as your main website, microsites, email channel, or a headless channel.

Marketers often copy content separately to each channel, which creates extra work and potentially leads to content and message inconsistency. With Xperience, you can store your marketing content in one place and distribute it to your digital channels from the same interface. This helps editor teams keep the campaigns and other marketing communications consistent and efficient.

Keep all digital content in Xperience

From a high-level perspective, you can look at creating and managing content in Xperience in two different ways:

Understand how Xperience stores digital content

In Xperience, all content is based on content types. You already know that a content type is a blueprint that defines data structure, functionality, and behavior for all content items editors create from this type. Based on this definition, reusing content requires storing it in a presentation-independent manner, i.e., in a structured format.

Xperience uses different content types depending on the purpose. Each has its own storage options and ways of connecting to other stored content.

• Reusable content type – Stores data in the Content hub. This content isn’t tied to any specific channel. Editors can reuse it across multiple channels, such as websites, emails, or headless applications.
• Webpage content type – Used in the website channel. Web pages can store data directly or act as a container displaying reusable content from the Content hub (or a combination of these approaches).
• Email content type – Used in the email channel. Emails can store data directly or display data from webpages or reusable items stored in the Content hub.
• Headless content type – Used in the headless channel. Headless items can store data directly in the headless channel or display reusable content from the Content hub.

We’ll discuss each of the options further in this and other dedicated materials. The following diagram overviews the storage options in Xperience.

Content types from the data perspective

Content types that store data in a structured format allow editors to create items in a form-like interface where they input data. The editing forms create a unified editing experience, and adding content in the Content hub feels like filling out an online form. From a data perspective, these fields correspond to database columns. Developers define content types in the Content types application.

When developers create content types, they configure:

• Fields that define the data structure of the content type.
• Editing form layout that creates the interface editors use to create and modify the content items.
• Usage of the content type:
  • Reusable content types are building blocks of reusable content meant to be linked together to form further content.
  • Content types for pages are used in website channels to form pages.
  • Content types for email are used in email channels to form emails.

Developers use the Content types application to define the data model of the Xperience application. They create content types based on the project’s business requirements using an easy-to-use admin UI consisting of form fields or ready-made form components.

The content type is stored in a coupled database table; its fields represent database columns. For example, Kbank’s News content type can have a coupled table named Kbank_News and columns defined as NewsTitle, NewsSummary, or NewsText.

Understand how each content type stores and uses data

The diagram above shows where different storage layers and content relationships are in Xperience. In the following sections, we’ll look at each channel and the Content hub in detail and explore how editors can store their data.

Website channel content

In a website channel, editors create content using the Page Builder content that allows flexible editing of the layout and content of pages, as structured pages that store content into fields without including presentation information and support consistent reuse and delivery. They can also display reusable content from the Content hub. Pages in the website channel are displayed in a visual hierarchy called the content tree.

Page Builder content

Page Builder allows non-technical users to manage the content and layout of their pages with templates, sections, and widgets. Page Builder isn’t intended to store all website content.

• Page Builder allows editors to manage the content and layout of select pages using a WYSIWYG editor.
• Editors control page layout using widgets and sections – reusable and configurable content prepared by the developers. Editors can dynamically alter the page’s design without developer assistance.
• We recommend using Page Builder in all website pages where editors need to personalize content to help website visitors on their customer journey.
• Page Builder works well for one-off or quickly degrading content that needs adjusting. It helps when editors need WYSIWYG-style editing.
• Use it when you don’t need to reuse the same piece of content in multiple places (except for widgets that allow for presenting structured content; see below).
• Page Builder content is stored in a dedicated database column as a JSON string.

Structured pages

Editors create structured pages without the need to focus on their layout. From a developer’s perspective, structured pages are strongly typed and stored in dedicated database tables per content type. Developers can easily retrieve this data via the API and display it on the live site application according to project requirements. Alternatively, developers can retrieve and display the content in various channels, such as mobile applications or third-party services.

Structured pages can be formatted using the following approaches:

• Programmatically per page type by assigning a dedicated view file – see Set up content tree-based routing.
• By editors using page templates assignable per page – see Page templates for Page Builder.
• By editors using widgets that contain a selector functionality that editors use to pick the intended content item from the content tree. Existing selectors allow editors to select any item from the content tree, so when creating the content storage section for reusable content, make the content items easy to find and navigate. You can also consider customization to the Page selector and restrict its use to a specific content type.

This approach helps maintain consistent content design and feel across the website channels, but provides editors with less flexibility in changing the layout or format.

Reusable content in Content hub

Editors can create and manage reusable content directly from within the website channel, without leaving the page editing workflow.

• Editors can create reusable content from website channel applications by selecting the Create new button when editing any page that has a field containing linked content items.
• Selecting the Create new button automatically creates a new content item of a predefined content type. When an editor saves the changes, the new content item is linked to the edited page. If editors update the linked item, the content is automatically updated in the website page as well.

This option helps editors keep content consistent across multiple digital marketing channels, minimizes content duplication, and improves content curation experience.

The following diagram shows the options for adding content in the website channel application.

When deciding how page content gets stored in Xperience, you have two options: structured pages and Page Builder. The following table gives an overview of both approaches.

Email content

Any email editors create or adjust from within the Admin UI needs to be part of an email channel and based on a content type. You can have as many email content types as you want. Depending on the purpose of the email and how it’s implemented, editors can create structured emails in the Content view mode, Email Builder, or a combination of the two.

• Structured emails use form-based content types with email templates predefined by developers
  • Their structure and design are consistent, as each field renders exactly as defined and in order as defined by developers.
  • Editors can use AIRA to generate or refine email content in their email workflow.
  • Ideal for repeatable, fixed-layout communications such as newsletters, event reminders, or product updates, as they are easy and fast to create.
• Email Builder offers a visual drag-and-drop interface with customizable sections and widgets.
  • Editors can change the email design depending on their needs. They have control over the layout and design of their emails, but thanks to the prepared components, their designs stay within brand limits.
  • Email Builder supports personalization against contact groups.
  • Ideal for audience-targeted emails or campaigns with varied layouts, such as promotions or product showcases.

Use structured emails when editors need to create emails fast, and Email Builder when they need a flexible interface to support their message through email layouts. You’ll learn more about designing email content.

Headless content

Editors create content in headless channels when they want to deliver their digital content to external channels through a headless API (GraphQL). They can manage content for mobile apps, kiosks, web apps, and other connected devices within the Xperience ecosystem.

• Headless content stores data in a presentation-agnostic format, ready for use across multiple platforms.
• Data is served in JSON format for consumption by headless applications and services through Xperience headless API.
• Editors typically create items for presentation units, such as app screens, display windows, or navigation elements.
• Headless content is ideal for scenarios such as mobile screens, information kiosks, TV displays, or AR experiences.

Headless content isn’t meant to be the primary method for working with content. It fits into the content system as part of Xperience’s hybrid-headless approach, combining headless delivery with traditional CMS features.

Choose the right approach for storing content

The method you use to store your content in Xperience affects how easily editors can reuse, update, adapt, and maintain their digital content. We’ll explore and explain the details and impacts of choosing different storage approaches, and provide recommendations for when to use each.

Remember how Page Builder content is stored

All content added directly to a Page Builder widget is stored in a single database field (CMS_ContentItemCommonData → ContentItemCommonDataVisualBuilderWidgets), making it difficult to reuse. On the other hand, widgets that add design to structured content store only a reference to the linked content item (using the GUID value).

Sometimes, projects require WYSIWYG editing through widgets that also store content. While specifying the project requirements, we recommend considering the implications of this design decision. Storing content directly in widgets significantly impacts content reusability and the project’s maintenance costs and upgradability.

Combine Page Builder and structured content

Page Builder and structured content are not mutually exclusive. You can combine Page Builder with structured content to leverage the full potential of both approaches.

When you define your content model, consider situations in which you can store the data in a structured format and use Page Builder widgets or sections to present or even overwrite this content in the website page. Your widgets and sections can contain properties that allow editors to add design information (size, colors, and other content behavior). Widgets can contain properties that editors can add to overwrite the structured, reusable data and tailor the data with a per-instance-specific message. Furthermore, some content types, e.g., Articles listing pages, bring editors more possibilities if you combine Page Builder and structured content.

In general, your editors will benefit when you combine both approaches:

• Use Page Builder for formatting structured content
• Add Page Builder editable areas to page templates that display structured data to help with content personalization.

The following diagram shows the benefit of storing data separately from its presentation. From a user perspective, editors can create their data once and reuse it when needed.

• News (content type).
• The editor creates a new page using the News page type and selects the page template they want. The News page type has the URL feature enabled to generate the page’s URL and make it accessible to website visitors.
• Data input via the Content tab is stored in the “News” page type, and data presentation (layout and styling) is handled via the page template.
• The Teaser image field in the News page type references a file stored in the Content hub; it doesn’t keep the file itself.
• Landing page (content type)
• The editor creates a new page using the Landing page page type and selects a page template.
• The Landing page page type has Page Builder enabled.
• Using the Featured article widget, the editor displays some data stored in the Article: the Title, Teaser image, and Publication date.
• The widget references the selected News using its GUID. If the widget has any properties that set design information for the displayed data, their configuration applies separately for each widget.
• The editor also adds a Speaker widget that displays some of the data from the Author content type stored in the Content hub.
• The widget references the selected Author using its GUID. Data about the widgets’ configuration on the Landing page is stored in the DocumentPageBuilderWidgets database field in JSON format.

Use Content hub for reusable content

Xperience comes with the Content hub application for storing reusable content. Think of the Content hub as a centralized repository where you create and keep your marketing content, and potentially reuse it across multiple communication channels.

In the Content hub, editors create items using content types with fields where they input data. The editing forms create a unified editing experience, and adding content in the Content hub feels like filling out an online form.

Because the Content hub is channel agnostic, editors do not see what the content will look like once it’s displayed, for example, on the company website. They can focus on the quality of their content rather than getting distracted by how the content will look.

Plan your content modeling approach in Xperience

Different CMS solutions allow editors to approach their content in different ways. Although using a single content type for free-form content in Xperience may seem easier, we recommend creating a structured content model with clearly defined content types and presentation layers to help editors maintain a consistent content experience across teams and channels.

Aim for semantic content types

Semantic content types organize information into conventional data types and make the data easier for both humans and machines to understand and interact with. Semantic content types go beyond just presenting a few images or texts; they provide a clear semantic context and give the data meaning. This meaning remains the same when editors adapt this content for different channels, like a website, mobile applications, or emails. At the same time, editors can enrich this content with relevant information, such as date, time, or location, or personalize the message to tailor the experience further.

Semantic content types are particularly valuable when customers integrate Xperience with third-party systems like ERPs or external product catalogs. Making the data shaped and scoped into a consistent structure in Xperience and other systems allows for efficient data synchronization. As a result, maintaining meaningful content and ensuring a seamless flow of information between systems is much easier.

Here are a few practical use cases:

• Articles - store articles, or blog posts as structured content items with titles, summaries, body content, author references, tags, and related assets. You can dynamically display articles on listing pages, author profiles, and topic landing pages without duplicating content. This ensures consistent presentation, supports discoverability, and makes it easy to update metadata or related links across all listings when editors update the articles.
• Product – reuse product’s structure with common features and benefits across similar products. For example, if several products include fast approval or secure online banking, you store these benefits once and link them to each product. This allows product teams to update a benefit’s description or icon in one place, automatically updating all linked products without manual edits.
• Services – manage your services as reusable content items containing structured details such as the service name, description, benefits, related case studies, and CTAs. You can link these services across product pages, industry landing pages, and campaign microsites. This allows your marketing and sales teams to maintain consistent messaging about each service. The system automatically updates the service information instantly across all channels where the service appears.
• Author profiles – reuse authors or bios across blogs, webinars, and landing pages. When a team member’s role or bio changes, your content team only needs to update it once, and the change reflects across all blog posts, speaker pages, and author blocks, saving time and ensuring consistency.
• Events – share event details across event listings, landing pages, promotional emails, and a dedicated event companion mobile app. Event teams can manage the event date, time, location, and description in one place, ensuring that any updates automatically appear everywhere the event is promoted.
• Organization – store organizational profiles, such as partner companies or internal departments, as reusable content types with names, logos, descriptions, and contact details. These can be linked dynamically to press releases, case studies, or event listings, ensuring consistency and simplifying updates when contact information or branding changes.
• Place/Location – manage places or locations as structured content items with address, map coordinates, contact details, and opening hours. Editors can reference the same location across events, service area listings, or store finders. When they change the details, Xperience automatically promotes the updates across all digital channels.
• Reviews – manage customer or partner reviews as reusable content items with the reviewer’s name, role, rating, testimonial text, and related product or service references. Editors can refer to these reviews from across product pages, campaign landing pages, and industry sections to build trust and social proof. Updating a review or adding translated variants automatically updates every location where the review is displayed, maintaining consistency while reducing repetitive content management.
• Testimonials – similarly to reviews, you can use the same customer testimonial in multiple campaigns. Marketing teams can centrally store testimonials in a predictable review snippet structure and reuse them on landing pages, newsletters, and product pages while tracking where each testimonial appears, supporting consistent messaging across channels.

Similarly, your project can store data in content types that aren’t described in the schema.org. Even though their data structure isn’t rooted in conventions, you can still define a predictable one. For example, you can derive their properties from existing types and validate their structure with Google’s structured metadata markup. We have seen the following types in Kentico customers’ projects.

• Hero banners – store hero banners as reusable content items with images, headlines, and supporting text. Editors can reuse banners across landing pages, campaign pages, or microsites. This allows your design and marketing teams to update seasonal or promotional banners in one place, ensuring a unified look across channels while enabling fast swaps when campaigns change.
• FAQs – link common questions to products, services, or help articles. Support teams can update an FAQ answer once, and the new information will automatically display anywhere the FAQ is referenced, reducing customer confusion and repetitive edits.
• Case studies – manage case studies as atomic content types that contain the client name, summary, testimonial quotes, and outcomes. These can be linked dynamically to industry pages, service pages, or campaign landing pages, allowing your sales and marketing teams to showcase relevant case studies without duplicating content across your site.
• Delivered projects – store completed project descriptions, client details, project images, and outcomes as reusable content items. These can be linked to service pages, industry landing pages, or even specific blog posts highlighting your expertise, making it easier for your teams to display proof of delivery consistently while managing updates in a single location.
• Global CTAs (Calls to Action) – manage CTAs as reusable items across pages and campaigns. If your marketing team needs to update a link or button text for a seasonal campaign, they can do it once in the CTA item, instantly updating all linked locations.

This composable approach supports large teams by separating ownership and maintaining a single source of truth for reusable content. It simplifies multi-channel delivery because editors can reuse and display the same structured content in emails, websites, and apps without duplicating it. It also helps maintain consistent customer experiences, ensuring your brand speaks with one voice wherever your content appears.

Help agentic search, LLMs, and SEO

Semantic content types also help provide a better AI agentic web experience and support traditional, now almost legacy, SEO practices. It is easier for LLMs and search AI agents to extract and repurpose concise and structured content in clearly defined types. Different content elements represent conventional semantic types.

Developers can add semantic metadata to website-specific content and define a clear and concise structure that LLMs understand. This helps search engines and AI agents, including AI Overviews and NLWeb, understand, interpret, and present your content more accurately.

Preparing the content for AI-driven tools will support your client’s long-term content strategy and discoverability across search and other emerging AI-driven platforms.

Help editors with content creation and curation

Providing structured, semantically relevant editing experiences helps editors deliver high-quality content efficiently. Editors can submit their content using elaborate editing workflows to reduce mistakes during content creation, publishing, and curation throughout the content lifecycle.

Select your content modeling approach

You’ve learned about different ways to store structured content in Xperience. From a global perspective, the approach you choose depends on the project needs, editor teams, and content delivery strategy.

You can store your data in a reusable content format in the Content hub for universal delivery, including a headless or hybrid-headless experience, and follow the pattern that we call an atomic content model, or create a page-based model that works great for web-centric, visually driven projects.

The atomic content model focuses on creating a highly composable, omnichannel experience. Editors store reusable content in the Content hub and keep this content channel-agnostic. To display this content in the presentation channel, such as a website, app, or campaign microsite, editors will use channel-specific “wrappers” around the reusable content and add channel-specific content, for example, SEO metadata in website channels. This approach works best for solutions that require scalable content reuse across many channels while maintaining a single source of truth.

The page-based model allows you to manage structured and unstructured content within webpage content types for web-centric, page-driven content flows. The editing UI for structured content in the website page is similar to Content hub, and editors can reuse content input through this interface in other website pages (on the same channel or cross website channel), for example, for listing pages, or in emails. The unstructured data is managed through the Page Builder. In Page Builder components, editors can refer to other reusable, structured content and display it. Or, they can store the content inside the Page Builder page or area. This makes the content “owned by the page” and very hard to reuse.

Using Page Builder as a primary way to store data is effective for:

• Projects where content is used primarily on one website and in one place on this website.
• Teams that require a user-friendly, WYSIWYG editing interface while maintaining semantic structure for SEO and AI readiness.

We’ll discuss both approaches later in dedicated material.

Compare the content modeling options

The following high-level comparison helps you decide which approach aligns with your project goals and highlights the most important trade-offs.

The Content hub fits best for content reuse, omnichannel consistency, and headless delivery. At the same time, page-based models align with visual-first workflows.

Page-based structured content aligns with design-driven editorial workflows, enabling structured content while maintaining flexibility for visual layout. In contrast, the Content hub enables consistent content reuse across websites, apps, and campaigns with centralized management.

The editing experience differs. Page-based model supports primarily visual, page-driven editing while the Content hub focuses on structured, presentation-agnostic, reusable data management.

Xperience also supports a combination of these approaches, allowing you to use Page Builder widgets to display data stored in a structured format from the Content hub within page layouts. However, Xperience does not support inline editing of the structured data within the Page Builder interface.

Both approaches can support strong SEO and AI search readiness if you correctly structure the individual content types.

Let’s make a short overview of both approaches:

Store core content into reusable field schemas

While creating a content model or defining the data structure for a content type, you’ll often identify that some fields or sets of fields repeat across different content types. For example, all product-related content types will have the same fields to hold title, product description, product image, and core taxonomy. Some product-specific fields are similar. Other content types used to promote these products might contain the same structure.

To manage these repetitions efficiently, we recommend using reusable field schemas that help you handle such repeated fields across different content types.

The following image shows the Kbank demo site’s content types for storing products: Account, Card, and Loan.

All three product content types share two groups of schemas – the Core content schema and Financial data schema. While the Financial data schema is relevant only to the products, the Core content schema stores the same content as other content types in the Kbank demo site. For example, we show two more content types that share the same schema: Featured content and Promotion.

Note that each content type has dedicated fields relevant only to that specific content type, such as the Minimal inflow or account type in the Product – Account type field or the External URL field in the Featured content. See how to approach modeling taxonomies to learn more.

Reusable field schemas from a data perspective

Unlike traditional fields, reusable field schemas give your team flexibility. Both support the same data types, but the reusable field schemas are stored in the ContentItemCommonData table, making them available to every content type. Any changes to a schema also immediately propagate across every content type that references it. However, developers need to ensure that these additional fields display content as intended in the code.

Compose semantic content types with reusable field schemas and dedicated fields

Reusable field schemas rarely constitute complete semantic content types independently, though they can be part of one. Rather than forcing them into semantic content types, use them to define the smallest minor reusable data structure you want to share across multiple content types and have editors input data intended for use across different channels. This will allow your team to maintain consistency in their data while avoiding redundant work.

Functional reusable field schemas

Reusable field schemas can store some core content of semantic content types and define functional data structures that different content types reuse. We’ve already mentioned the financial data schema, which editors work in any Product content type on the Kbank demo site.

Similarly, you can define and use an SEO schema across every page content type.

To allow editors to add reusable parameters to URLs, developers can define a UTM parameters schema and assign it to different call-to-action buttons, links, or email content types to store data they want to track into analytics tools.

Find out which data types Xperience comes with in Data type management. You will also learn about customizing the out-of-the-box set to support different data types.

Semantic data in reusable field schemas

You’ll identify data that repeats across different content types during a content audit. This might be a heading, some summary text, a reference to an asset, or tags from a specific taxonomy collection.

These schemas represent the Core content that many of your content types contain. Using a reusable field schema avoids the redundancy of defining similar fields across multiple content types. You can define the Core content schema and integrate this schema into other content types. Semantically, they don’t specify a content type that you can find in the schema.org. At the same time, they gather crucial information about the content the company produces, meaning they might be considered semantic.

See the Core content schema shared across the products and articles on the Kbank demo site.

Build a flexible model with content blocks

A content block is a piece of content that is not a full page but still carries semantic or functional meaning within your digital content. Content blocks are typically reusable across multiple pages or app screens; they can repeatedly appear in emails or can be shared externally through a headless API. Storing this content in a structured format in Content hub helps your content stay consistent and accurate and reduces unnecessary duplication if editors need to share this data across channels.

Content blocks:

• Have semantic meaning (they represent a specific type of information, like an FAQ section or a call to action).
• Can be composed of multiple other structured content items (e.g., an FAQ block contains individual FAQ items).
• Are usually reused across your website or other channels (like email or apps).
• Live in the Content hub (in dedicated folders), in a structured format to support reuse, filtering, and consistent presentation.
• Allow editors to insert dynamic, reusable content without duplicating work.

You can see some examples of content blocks that we’ve seen in Kentico projects.

• Collection of FAQs for product or support pages.
• Hero banners with global links and promotional messages.
• Accordion sections for structured expandable content on landing pages.
• Speaker or author profiles (when you don’t need to build full author pages).
• Office addresses with office hours for multiple location listings.
• Testimonial sliders used across product and marketing pages.
• Feature highlights that display key benefits in a reusable component.
• Call-to-action sections encouraging sign-ups, demos, or contact requests.
• Event highlights showcasing upcoming events on various landing pages.
• Teaser or Featured content cards for articles, products, or services that help editors overwrite the default content in product or service content items.
• Image galleries reused across different campaign pages.
• Pricing lists displayed consistently on product or service pages.
• Contact information blocks that maintain consistent formatting across regions.

Use the built-in admin UI form components

Xperience provides different form components for content types that editors will use to input their data. Other form components may also have additional configuration options.

For example, the Long text data type comes with different text-based form components, such as the Text input, Password, URL, or Text area. You can use the Rich text (HTML) data type with the Rich text editor form component for rich text.

Form components also come with various configuration options that provide different editing experiences. Developers can, for example, configure the Rich text form component as Structured content, Email content, or Contact notes. Developers can also customize their configuration. The following image shows Kbank’s Rich text editor configuration options; the last News page editor configuration is custom.

Find out more about available Admin UI form components and the React input type components in the documentation.

Simplify structured content with custom data types

The out-of-the-box data types and UI form components that you use to define editing experience represent the most common types that fit most projects. During content modeling sessions, you may realize you might need to standardize some complex content object, like multiple addresses or office hours, into a predictable structure to improve the editing experience and help with data format predictability to match the unique project’s needs.

Instead of forcing every piece of structured content to live as its own content item (or even a granular content item composed of other, smaller content items) in the Content hub, you can use custom data types to model content that should belong to a parent item without cluttering your reusable content library. This is especially useful for structured content critical for presentation and governance, but it doesn’t make sense to manage it as standalone, reusable content items.

Custom data types mean your content can remain structured, semantically meaningful, and repeatable while avoiding the limitations of hard-coded field sets in your content type. Editors can add, remove, and reorder structured entries (like multiple addresses for a business) without leaving empty fields or copy-pasting data they need to rearrange the content. This provides a smoother, frustration-free editing experience and enables developers to control presentation and validation for each piece of structured content.

See an example of an address custom data type or UTM parameters in the Kentico Community Portal.

Leverage linked content items

Xperience allows editors to compose their content items by combining data stored in several other content items.

Let’s examine the Product content type discussed on the previous page. Highlighted fields store the actual data inputs, while the light violet fields reference other content types that hold the values.

You can see that the Product type contains fields like Product features, Product benefits, or Product image. Sure, you can create two more fields and store the values of product benefits and their icons within the Product. At the same time, why would you?

In real life, if we take the Kbank demo site example, more than one product will offer the same benefits, such as included internet banking, getting a quick decision, or fast access to funds.

Storing the information about benefits within the individual product content item restricts access to this data only within the context of this one (and only one) product item itself. If another product allows for fast access to funds, editors need to duplicate the same wording and decorate it with the same icon in another product item. Duplicating the same content often leads to content management nightmares.

When defining the content model, discuss which types can be reused and create them accordingly. Editors will use the Content item data type with the Combined content selector form component to refer to the relevant data. At the same time, developers will retrieve the linked items and display them accordingly.

Developers also limit which content types editors can select when creating their content. The Combined content selector allows developers to specify which content types editors select.

When an editor selects content items they want to use, rather than copying the values from the original item to the new item, Xperience creates a reference between these records.

Reusing content items improves content maintenance. When an editor updates the referenced item, the content changes are automatically promoted to every other item that uses this content, making content management a breeze. From the developer’s perspective, developers query the linked items in their custom code and return a collection of references to content items they can further process. For example, they can retrieve URLs of web pages to which editors want to guide their audience.

One of the most typical examples of reusable content types is a content item assets that users store in the Content hub. See further examples mentioned in this material on the Kbank demo site.

Avoid creating channel-specific content from linked content fragments

Customers who are used to displaying their content (stored in a CMS) on the website love using visual builders to create website content. Xperience offers Page Builder, which allows editors to assemble web pages using components like hero banners, text and image blocks, reviews, testimonials, and FAQs. For simplicity, we’ll call these components “content fragments.” These fragments aren’t semantic; they hold specific pieces of data that represent only a part of the overall information needed to convey the complete meaning of the content.

While this approach makes it easy for editors to craft entire web pages quickly in Xperience, it has limitations. The most significant advantage is speed and simplicity, but only when you’re only concerned with presenting content on a single website channel. However, this method ties the content exclusively to the specific web page, meaning the fragments can’t be easily queried or reused across different channels in Xperience. By composing their content type using widgets, editors lock their content only within the context of that specific web page.

To build a more flexible, multi-channel solution, we recommend creating semantically defined reusable content types that are made up (composed or linked) from other reusable components. This approach ensures that the content isn’t just relevant to one specific channel but can be used and adapted across different platforms. It also makes the content queryable, structured, and easier to manage in the long term, giving developers more control over its use. We’ll discuss the Page Builder in detail in a dedicated material.

Storing reusable content in Content hub vs. custom module classes

Both options offer unique advantages when storing reusable content in Content hub or custom module classes. From a user perspective, we recommend considering the Content hub before choosing custom module classes.

The Content hub provides default Kentico functionality, including editing workflows, multilingual support, usage reports for improving content curation, and a built-in user interface. Additionally, the Content hub allows editors to easily manage and reuse content across various channels, making it highly flexible for developers and editors. Using Content hub often means developers don’t have to create custom UI components, saving time and effort.

A key benefit of the Content hub is its ability to integrate with APIs, enabling content creation from third-party sources. Upcoming features are expected to enhance this functionality further, making it an even more powerful tool. Using the Content hub, developers can focus on supporting content management through out-of-the-box components rather than building custom solutions, leading to quicker deployment and easier maintenance.

Make designing content generic

Though you might want to store design-specific information, like exact color codes or sizes, inside the channel-specific content types, we do not recommend doing this. From a content longevity perspective, you want to have your design information as agnostic to the visual design as possible. When you decide to, for example, redesign your brand, it’s easier to remap the generic class name to new colors than to change the specific #F05A22 brand color code in hundreds of different places. The following screenshot shows styling options in the Kbank demo site.

What’s next?

You have learned about the options for storing non-file data in Xperience. In the Store files section, you’ll learn the recommended practices for storing different types of files in Xperience.