---
title: Select your content modeling approach
---

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

### 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](https://docs.kentico.com/modules/content-modeling-guide/design-atomic-content-model.md). 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](https://docs.kentico.com/modules/content-modeling-guide/structured-and-unstructured-content.md) within _webpage content types_ for _web-centric_, [page-driven content flows](https://docs.kentico.com/modules/content-modeling-guide/design-page-based-content-model.md). The editing UI for structured content in the [website page](https://docs.kentico.com/guides/development/developer-kickstart/define-a-page-content-type.md) 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](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder.md). 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:

| Aspect             | Atomic content model                                                        | Page-based content model                                   |
| ------------------ | --------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Best for           | Multi-channel, headless, and scalable reuse                                 | Web-centric projects                                       |
| Structure          | Channel-agnostic, reusable                                                  | Structured within the page hierarchy                       |
| Editing experience | Content-centric                                                             | Visual, page-driven                                        |
| SEO and AI         | Strong with consistent reusable data, displayed in semantic HTML structures | Editors need to focus on crafting semantic HTML structures |