---
title: Choose the right approach for storing content
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

## 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.

![Structured content reuse example](https://docs.kentico.com/docsassets/modules/choose-the-right-approach-for-storing-content/cm-guide-using-structured-content-in-content-types.png "Structured content reuse example")

The diagram explains how structured content created in the _data layer_ is reused in different parts of a website’s presentation layer using reusable “Article” content type. It contains fields such as title, lead, teaser image, body, category, author, and publication date. These fields can be stored either in the website pages or in the Content hub and can reference other content or assets.

In the lower half, you can see the _presentation layer_, where different website components use this structured content.

- On the left, you can see Page Builder with a landing page template and a widget called _Featured article_, which pulls selected structured fields like heading, publication date, and teaser image.
- On the right, you can see structured content being inserted into page templates.

This explains how a single, structured article is stored once in the data layer and reused automatically across multiple website components without duplicating data.

### 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.

![Content type editing interface](https://docs.kentico.com/docsassets/modules/choose-the-right-approach-for-storing-content/cm-guide-hero-banner-content-type.png "Content type editing interface")

You can see the admin UI for a reusable _Hero banner_ content type.

The layout is organized as a long, vertical form broken into sections. The top section provides action buttons for previewing, saving, and other content actions. Below that, you can see a Combined content selector to reference a page this banner represents or linking this hero banner to another content item.

Further down, you can see a _Core content_ section that contains the main fields used to build the hero banner. The _Core content_ [schema](https://docs.kentico.com/documentation/developers-and-admins/development/content-types/reusable-field-schemas.md) stores data that repeat across many content types. You can see a _title_ field, a _multi‑line rich text editor_ for the main headline and supporting text, and an _Asset_ selector where editors select and preview an image thumbnail that represents this hero banner. Beneath this asset section, editors can categorize content using tag selector or pick related pages to link this hero banner to other content.

The bottom contains additional related content items called _Benefits_. Each benefit appears in a table‑style list with its title, content type, source, publishing status, and action icons for editing or removing it.

Overall, the admin interface allows editors to assemble a fully reusable hero banner by combining text, media, tags, related pages, and child content items, all within a structured and repeatable admin UI.

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.