---
title: Design page-based content models
---

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

## About this guide

> **Info:** This page is a part of the **Content modeling guide** which you should follow sequentially from [beginning to end](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide.md). You can also follow this series in [Content modeling guide](https://docs.kentico.com/modules/content-modeling-guide.md), which helps you keep track of your progress as you move through this sequential material.

From a marketing perspective, not all content will be distributed across multiple marketing channels. The **page-based model** works perfectly in situations when semantically defined content is displayed under one specific URL.

In projects that embrace a _page-based content model_, editors save, structure, and manage content as **individual pages within a website channel**. They use the **Page Builder** to display content from the **Content hub** or add content directly to the page.

## Understand how editors work with page content in Xperience

Compared to other CMS solutions where website pages and their storage capabilities are used for creating one-off, non-reusable content, storing content in Xperience [webpage content types](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/store-content.md) **doesn't mean that this content is available only when a user visits a specific page**.

If the webpage content is stored in [structured format](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/structured-and-unstructured-content.md), editors can use this _page-specific data_ across the website channel where they create the page, refer to it from other website channels, or share it through emails.

Typical Xperience projects built with the page-based approach contain pages with structured fields in [Content](https://docs.kentico.com/documentation/business-users/website-content.md#view-modes) view mode and the [Page Builder](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder.md).

Editors capture data they want to reuse as _structured data_ (in the _Content_ view or as content items in the _Content hub_). They then use the _Page Builder's_ easy-to-work-with drag-n-drop interface and display this page data on the same page, across other website pages, or in emails. _Page Builder_ widgets allow them to retrieve [reusable content items or content blocks](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/store-content.md) content from the _Content hub_, for example, a [Hero banner](https://docs.kentico.com/guides/digital-marketing/work-with-reusable-content/reuse-content-with-the-hero-widget.md) or other **content fragments**, such as a collection of _questions_ and _answers_ for a QA page, in the [Content hub](https://docs.kentico.com/documentation/business-users/content-hub.md).

Editors can compose layouts in a WYSIWYG manner, giving the content clear visual meaning and hierarchy. In the backend, the _Page Builder_ components help editors communicate the content's semantics and structure in a way that is understood by search engines, screen readers, and other systems.

The following example shows a product page on the Kbank website. Though this website page is built using [atomic content model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md), this page uses _structured data_ and _Page Builder_ to display it.

![Product pages in Kbank demo site](https://docs.kentico.com/docsassets/guides/design-page-based-content-model/product-page-components.png "Product pages in Kbank demo site")

As you can see, the product detail page is composed of multiple structured sections and widgets, each representing a different part of the layout.

At the top, the _Hero banner section_ introduces the product with a large headline, supporting text, and a featured image. Below it, a _Summary_ or promo section presents a short description of the product that's followed by _Product highlights_ section. This section combines an image with a styled content block that includes key features, and a list of product details.

Further down, a _Promotion_ widget in a dedicated section displays a standalone promotional message that's accompanied with an image. The page also includes an FAQ section with collapsible items, allowing users to explore common questions.

Beneath the _FAQs_ widget, the page is split into two columns. The left side uses _Benefits_ widget to list additional product benefits in a bulleted list. The rigth side contains a _Card_ widget wiht an image and links to a news article about the product.

Lower on the page, a full‑width image section provides a visually rich break in the layout. Near the bottom, a lead‑capture form section lets users submit their contact information.

Finally, the page ends with a footer section that contains navigation and branding components. All these components together create a structured, modular product page assembled from reusable content items and page‑builder widgets.

## Learn why the page-based model works for web-first projects

The _page-based content model_ best fits projects with a dominant, single website channel, where editors plan to use this website content in emails or a few micro-channels.

When an editor thinks, _"I’m creating and publishing a page that users can navigate to using a URL,"_ their workflow can be much simpler. It feels natural, and looking at the page, the editor has all the necessary context. They have a clear picture of the content's layout, they understand its structure and purpose within the website channels, especially if they come to Xperience from traditional CMS solutions.

Consider also the following benefits:

- The _page-based content model_ supports campaign workflows well. It is easy to create, clone, and manage landing pages, and editors can reference structured content in related newsletters or campaign emails as needed. This flexibility allows teams to react quickly when campaign requirements change.
- Curating existing media and other assets becomes simpler. Editors usually update their content from within the page context and refer to assets directly from the specific pages using the _Content_ view mode or, more likely, the _Page Builder_ widgets.
- A page-based workflow makes onboarding easier. Editors see their content in context, which reduces new users' training time.

Let's discuss key aspects of defining a page-based content model.

## Always focus on the editor workflow

Data in _page-based, web-centric projects_ closely reflects the visual experience.

When you define content types for a _page-based content model_, start by examining the website designs provided by your graphic design or UX teams. Consider how editors naturally want to assemble this page and aim to support their workflow without unnecessary friction.

Ask: _If I were an editor, how would I want to put together this page? Which parts of this page do I want to use somewhere else? Which components do I need to build this page?_

Editors will create pages from the website channel. They first select the _content type_, then a _page template_ that contains _editable areas_ for _sections_ with _widget zones_ where they place _widgets_.

Looking at the design from the editor's workflow perspective will help you identify which content can editors add directly in the _Page Builder_, which should be added in the _Content_ view, and which parts of the page need to become reusable _Content hub_ items.

> **Tip:** Your goal is to minimize how often editors need to switch between the _Content_ tab and _Page Builder_ while creating related content.

Then, look at the content pieces from a higher perspective and think:

_Which pieces of content will editors create before they build this page? What they need to have ready in advance before they start working on this page? Which data will they put together at once? What content will they likely work on after they finish this page?_

This helps ensure editors won't need to switch between the _Content_ view mode and _Page Builder_ context to complete related tasks. Aim for a seamless workflow that keeps the editor in the context of one editing UI as long as possible.

> **Tip:** When you decide which content will be stored in fields, define [visibility conditions](https://docs.kentico.com/documentation/developers-and-admins/customization/extend-the-administration-interface/ui-form-components/ui-form-component-visibility-conditions.md) to improve editor workflow. This will allow hiding _advanced design_ and introducing _configuration options_ by default. Editors will work in a clean, focused editing interface that reduces potential errors and confusion.

## Identify reusable data

When an editor stores data into the page, the content becomes "owned" by the page. It is always navigable under the page-specific URL, and in case of storing data in the [Page Builder](https://docs.kentico.com/documentation/business-users/website-content/widgets-and-page-builder.md), this data is not easy to reuse.

At the same time, editors will want to share bits and pieces of their content strategically across their website, on additional microsites, or emails. They also want to ensure their website data adheres to the traditional [SEO requirements](https://developers.google.com/search/docs/appearance/structured-data/sd-policies).

Identify data that needs to be _reusable across pages or channels_. Look for content structured by nature, such as _titles_, _summaries_, _addresses_, _opening hours_, _pricing tables_, or _product feature lists_. Check the examples of [semantic content types](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/store-content.md#aim-for-semantic-content-types)  that reflect real-life use cases.

Determine what [structured data](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/structured-and-unstructured-content.md#benefits-of-structured-content) is needed to construct data for [semantic SEO](https://ahrefs.com/blog/semantic-seo/), which data will editors want to display in multiple places and make sure that this data is stored in a structured form in the _Content_ view.

Determine the [structured data](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/structured-and-unstructured-content.md#benefits-of-structured-content) needed to construct [web page's rich metadata](https://developers.google.com/custom-search/docs/structured_data):

- [JSON-LD metadata](https://developers.google.com/custom-search/docs/structured_data#jsonld) for traditional SEO,
- [OpenGraph metadata](https://ogp.me/) for social media,
- newly proposed [LLMs-txt](https://llmstxt.org/) standard,
- shared web page data editors want to display in multiple places, and ensure that this data is stored in a structured form in the [Content](https://docs.kentico.com/documentation/business-users/website-content.md#view-modes) view.

Website editors might want to overwrite the default, _core content values_ stored in the website [data field](https://docs.kentico.com/documentation/developers-and-admins/development/content-types.md). Also plan for fields to [override](https://docs.kentico.com/guides/architecture/content-modeling/model-website-content-types/model-an-article-page.md) _publishing dates_ or other system-generated values to help editors' needs. Editors can reuse this structured data across different channels or websites, so consider how it will be modeled to allow controlled reuse without disrupting the page-based workflow.

Finally, identify data that may originate from external systems, such as pricing data or product specifications, and plan how to import or reference this data within your content types while maintaining consistency and reliability for editors working in the page-based model.

> **Tip:** When deciding between reusable and channel-specific content, follow a simple rule of thumb:
>
> Can editors reuse this piece of content on a different channel in the future? If yes, make it reusable and store it either in the Content view mode or in the _Content hub_.

## Manage media assets from the Content hub

We recommend using the _Content hub_ to manage reusable images, videos, and other assets and organize them in folders and a workspace structure. In a page-based content model, editors should be able to manage all their content from their website channel. Images and other assets are no exception.

Design the editing flow with built-in components so the editor can upload any new assets they need for a page from within the edited page. Your developers configure widgets and content fields, so that editors can upload or select their assets using dedicated Content hub [folder](https://docs.kentico.com/documentation/business-users/content-hub/content-hub-folders.md) and [workspace](https://docs.kentico.com/documentation/developers-and-admins/configuration/users/role-management/workspaces.md).

To bulk-upload images, editors will use the [mass upload feature](https://docs.kentico.com/documentation/business-users/content-hub/content-item-assets.md#mass-asset-upload) in _Content hub_.

## Extract shared data to a reusable schema

Multiple pages will likely repeat the same fields across different content types that you can store into [reusable field schemas](https://docs.kentico.com/documentation/developers-and-admins/development/content-types/reusable-field-schemas.md).

This **core content** typically includes information, such as _title_, _summary_, _taxonomy_, or a _thumbnail image_.
[Reusable field schema](https://docs.kentico.com/documentation/developers-and-admins/development/content-types/reusable-field-schemas.md) reduce data duplication, simplify content type management, and improve the editor experience. Content types with reusable field schemas are transparent and predictable. The data is stored in one of the [core content item database tables](https://docs.kentico.com/documentation/developers-and-admins/api/content-item-api/content-item-database-structure.md#content-items), which helps developers optimize the performance of retrieving this data.

At the same time, [combined content selector](https://docs.kentico.com/documentation/developers-and-admins/customization/extend-the-administration-interface/ui-form-components/reference-admin-ui-form-components.md#combined-content-selector) allows editors to select items that share the same _reusable field schemas_, which simplifies content management and might require fewer widgets to display this content.

See [core content schema](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/store-content.md#store-core-content-into-reusable-field-schemas) for a deeper explanation and best practices for how to store core content into [reusable field schemas](https://docs.kentico.com/documentation/developers-and-admins/development/content-types/reusable-field-schemas.md).

## Define page-specific one-off content

Not all content needs to be reusable. Content like personalized _call-to-action button labels_ or _page headings_ will likely be specific only to the website channel, and it doesn't have to exist as [reusable content](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md) in the _Content hub_ or as structured data within pages. Editors will create these items directly for a specific website page and keep them there.

Besides adding reference to reusable _structured data_, editors can **input content into widgets** in two ways: through [widget properties](https://docs.kentico.com/documentation/business-users/website-content/widgets-and-page-builder.md#edit-widgets) that display in the side panel view or in a WYSIWYG manner using widget inline editing.

### Make widgets respect content hierarchy

Provide widgets for one-off page content that editors will can to add one-off content. Your widgets should reflect project needs and ensure that input data maintains its [structural hierarchy](https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Structuring_content/Headings_and_paragraphs#implementing_structural_hierarchy) and semantic clarity. These widgets should support content such as **tables**, **visual journeys**, or **step-by-step instructions**. These widgets should generate semantic HTML and enforce consistent formatting across all pages.

> **Tip:** Design **Page Builder** components to guide editors in creating pages that output valid, semantic HTML with clear structures like heading hierarchy or correctly identified content sections. This ensures consistent, accessible, and SEO-friendly pages without requiring editors to manage technical details manually. Learn more about how to [prepare your content for SEO and AI readiness](#optimize-for-seo-and-ai).

### Integrate rich text editing when necessary

Sometimes, projects require almost free-form WYSIWYG text editing with advanced styling options like formatting text, adding tables on the fly, or even adjusting the HTML markup. This usually happens when the editor team is upgrading to Xperience from an older [kentico Portal Engine](https://docs.kentico.com/k12sp/developing-websites.md) website where they used to work with [editable text](https://docs.kentico.com/k12sp/developing-websites/developing-websites-using-portal-engine.md#the-page-in-editing-mode) or comes to Xperience from another CMS platform.

You can use the built-in [rich text](https://docs.kentico.com/documentation/business-users/rich-text-editor.md) to create the most flexible editing experience.

At the same time, remember: the page _owns_ the content in the _Rich text_ widget. It’s hard to reuse elsewhere because it isn’t structured and can’t be easily queried or shared across channels. It exists on the [page's URL](https://docs.kentico.com/documentation/business-users/website-content/manage-page-urls.md), which makes it non-reusable across different [channels](https://docs.kentico.com/guides/digital-marketing/work-with-channels/digital-marketing-channels.md).

If editors use the HTML editing mode, the designs they introduce can be more complicated to update (e.g., the company updates its brand messaging). During the content modeling session, your team should discuss and agree on [rich text editor configuration](https://docs.kentico.com/documentation/business-users/rich-text-editor.md) to only allow desirable [HTML attributes and tags](https://docs.kentico.com/documentation/business-users/rich-text-editor.md#allowed-html-attributes-and-tags).

> **Info:** Remember, all content added directly to a Page Builder widget is stored in a single database field, which makes it difficult to reuse this content.

While editors are used to working with **rich text editors** and they will likely ask for it in project requirements, always consider its implications in the content modeling sessions. Allowing editors to input rich text data or update significantly impacts content reusability and the project’s longevity when, for example, the company changes its brand manual. There are situations where rich text is completely fine, and there are cases in which a dedicated, slightly more restrictive widget will help maintain content longevity and improve maintainability.

For example, if the editor team knows how to keep the [document structure](https://www.w3schools.com/whatis/whatis_htmldom.asp) intact to [help technical SEO](#optimize-for-seo-and-ai), they can safely use the _Rich text_ widget to add page headings. In other cases, it might be helpful to create, for example, a dedicated widget. As you can see below in the Kbank demo site's _Page heading_ widget, editors can select the heading HTML tag, but override its default visual size in a dedicated dropdown.

![Page heading sample widget with editable properties](https://docs.kentico.com/docsassets/guides/design-page-based-content-model/cm-page-heading-properties.png "Page heading sample widget with editable properties")

#### Consider creating a custom markdown widget

In general, we recommend storing content that has to stay consistent and presentation agnostic in [structured format](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/structured-and-unstructured-content.md), either in _Content_ view mode or using the _Content hub_.

If you need to create a WYSIWYG editing experience but have to withhold data structure when editors add it to the page (for example, to display it in external systems), consider creating a custom _Markdown_ widget to keep page data in a highly portable format. Editors will gain a free-from-like editing UI, and developers will have a slightly easier way to query the data in their custom API. See the [Markdown widget](https://github.com/Kentico/community-portal/tree/b7b6d98c01cb2e6eeb9cf579f7e67aed908e51f8/src/Kentico.Community.Portal.Web/Components/PageBuilder/Widgets/Markdown) in the [Kentico Community  Portal](https://community.kentico.com/).

![A custom Markdown widget in Kentico Community Portal](https://docs.kentico.com/docsassets/guides/design-page-based-content-model/cm-guide-custom-markdown-widget.png "A custom Markdown widget in Kentico Community Portal")

Editors create content in a large _Content_ area and use standard Markdown tags or WYSIWYG styling in dropdown to create the content. Below, they can configre the layout of the content and make it a _Note_, _Code_ block or a _Standard_ text.

### Restrict access to widgets in page templates

To support a page-based model, define _Page Builder_ page templates that match your intended [semantic content types](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/store-content.md#aim-for-semantic-content-types). Each template should provide clear areas aligned with your design files, with widgets and section editors that users [are allowed to use](https://community.kentico.com/blog/defining-editable-area-restrictions). You can find different examples of widgets and other recommendations for [displaying content](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-website-content.md) on a dedicated page.

## Connect webpages with Content hub reusability

Some projects may require setting up content filters to improve the editors' workflows or [deliver content dynamically](https://docs.kentico.com/guides/development/advanced-content/deliver-content-dynamically-with-smart-folders.md), based on, for example, publishing date or [taxonomy](https://docs.kentico.com/documentation/developers-and-admins/configuration/taxonomies.md). The features that enable this, such as advanced filtering and smart folders, are not yet available for the website channels.

To connect a web page with page-specific content with the reusable, channel-agnostic capabilities of the _Content hub_, we recommend creating a **Page proxy** content type. The _page proxy_ represents a specific webpage within a website channel inside the _Content hub_, containing only a single field with _Combined content selector_ to create the reference that you can see in the following image. Thus, you'll allow editors to take advantage of _Content hub_ features that are not available to Xperience website channels.

!['Blogpost Content' page proxy in Community Portal](https://docs.kentico.com/docsassets/guides/design-page-based-content-model/page_proxy_in_community_portal.png "'Blogpost Content' page proxy in Community Portal")

The _page proxy_ pattern helps in scenarios where specific page types need to participate in _Content hub_ workflows, such as using smart folders for dynamic content delivery, creating content collections using _Content hub_ folders for filtering, or reusing specific taxonomy tags across related content.

Note that _Page proxies_ are unnecessary for every page type and should be used only where the benefits of connecting with the _Content hub_ are clear.

> **Tip:** Developers can also custom-build a feature that automatically creates its _page proxy_ when an editor makes a page in a website channel. This will improve the editor workflow and ensure the _page proxy_ pattern remains in sync with the source page.
>
> You can inspect the _page proxy_ pattern and its [implementation](https://github.com/Kentico/community-portal/blob/b7b6d98c01cb2e6eeb9cf579f7e67aed908e51f8/src/Kentico.Community.Portal.Web/Features/Blog/Events/BlogPostContentAutoPopulateHandler.cs) on the [Kentico Community Portal](https://community.kentico.com/).

## Address challenges in a page-based model

When you build a _page-based content model_, you may run into challenges that limit flexibility, scalability, or content reuse. This section explores practical approaches to mitigate common issues, helping you maximize the use of Xperience’s capabilities while maintaining a clean, maintainable content structure.

| Challenge                   | How to address                                                                                                                                                                                                              |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Inconsistent structure      | Provide semantically structured widgets with enforced HTML tags and ARIA labels.                                                                                                                                            |
| Limited cross-channel reuse | Use _Content hub_ for reusable, non-navigable content.                                                                                                                                                                      |
| SEO and AI readiness        | Use structured data fields (JSON-LD), validate with accessibility and SEO tools. (Use external tools until the Xperience [ AIRA](https://docs.kentico.com/documentation/business-users/aira.md) receives related features.) |
| Content fragmentation       | Use placeholder widgets to enable referencing structured content within pages.                                                                                                                                              |
| Taxonomy underuse           | Plan taxonomy structures and enforce tagging during content creation.                                                                                                                                                       |
| Workflow friction           | Group related fields in the _Content_ view mode to reduce context switching and UI information overload.                                                                                                                    |

## Add widget properties for overriding reusable values

Making content reusable doesn't mean editors are limited to always displaying the core reusable values. They need a flexible editing experience. They need to tweak parts of the content when they display it on one page, and adjust different parts when they display it somewhere else.

When you look at the

Since you have [reusable content](#identify-reusable-data) you have in [identified](#identify-reusable-data), ask yourself:

_Which of these reusable page structured data will editors want to overwrite, for example, in personalization variants? Which of this data will they want to move or style on the page?_

Improve the editing experience and define the _Page Builder_ widget with properties that will allow editors to overwrite the core values without modifying the source data. For example, when an editor selects content to feature in a card using _Combined content selector_, they will want to overwrite the core content _description_ with a message that better fits their needs using dedicated widget property fields, such as custom _title_ or a short _description_, as the following image of _Featured content_ widget properties illustrates.

![See a proof-of-concept widget editors use to overwrite their reusable content](https://docs.kentico.com/docsassets/guides/design-page-based-content-model/cm-featured-content-properties-overwritable.PNG "See a proof-of-concept widget editors use to overwrite their reusable content")

Use [taxonomies](https://docs.kentico.com/guides/digital-marketing/work-with-taxonomies/taxonomies.md) to systematically categorize and surface related content while ensuring your content model supports filtering without additional complexity. Include structured metadata fields in the _Content tab_ to handle SEO, Open Graph, and [JSON-LD](https://json-ld.org/) requirements, maintaining consistency and machine-readability across all pages. Finally, while allowing rich text fields where flexibility is needed, consider Markdown or structured text fields for content requiring uniformity and easier reuse.

### Avoid creating channel-specific content from linked content fragments

Building pages with the _Page Builder_ is addictive which also creates a trap. You might be tempted to define one or two universal page templates with widgets and let editors assemble any content using _one-off_ or _reusable data_ from _Content hub_.

This free-form approach works well for short-lived, campaign-style pages. Editors create content quickly and iterate quickly over the page's layout and data.

But _free-form pages_ can become a liability for anything beyond a campaign page. When editors compose content from non-semantic content fragments (hero, text block, testimonial, FAQ), they’re assembling presentation but don't create meaningful content item. The combination of individual fragments lives only within the page where they were placed.

Editors create a _semantic content items_ in the website channel. The [Xperience API](https://docs.kentico.com/api/content-management.md) doesn't offer methods that allow developers to reliably query this data, so editors won't be able to reuse their content effectively.

The result is channel-locked content that’s hard to adapt to mobile apps, emails, search, or API consumers. What starts as flexibility turns into fragmentation: editors need to double down on duplicated content, and when they miss anything, their messaging might not be consistent. Instead, prefer _Page Builder_ for layout and campaign agility and introduce structured data to support consistent and reusable delivery.

## Leverage built-in taxonomies

Building your entire digital experience within the website channel using page-based data can lead to under-utilizing Xperience’s [taxonomy](https://docs.kentico.com/guides/digital-marketing/work-with-taxonomies/taxonomies.md) feature. If you’re coming from older Kentico products, you may be used to categorizing the content using the content tree hierarchy in the website content model. However, relying solely on the content tree for categorization can limit how effectively you use Xperience’s full capabilities.

Instead, consider how you can leverage built-in taxonomies effectively. Review your content taxonomy to determine which categories should be structured within the content tree—such as business areas that align with your site’s navigation—and where tagging can enhance your global taxonomy, such as image categories, article categories, persona-specific content, or campaign data.

This approach will help you integrate [taxonomies](https://docs.kentico.com/documentation/developers-and-admins/configuration/taxonomies.md) naturally into your editor workflow, and ensure that editors categorize content with identical tags during content creation. Using taxonomy tags, developers then leverage [leverage taxonomy API](https://docs.kentico.com/documentation/developers-and-admins/configuration/taxonomies.md#retrieve-taxonomies-and-tagged-content) for more flexible retrieval, filtering, and organization.

## Optimize for SEO and AI

The traditional SEO landscape is evolving fast thanks to the [AI-driven innovations](https://searchengineland.com/stay-grounded-inspired-ai-changes-search-seo-457918). Ignoring the new trends or forgetting about the traditional [technical SEO](https://www.semrush.com/blog/technical-seo/) rules and practices can significantly influence the application's discoverability.

Ensure your content is ready for AI-driven discovery and SEO. You need to deliberately architect your page-based model to adhere to existing [conventions](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Using_the_Document_Object_Model).

Make sure that every page has a way to store necessary metadata. Use [reusable field schema](https://docs.kentico.com/documentation/developers-and-admins/development/content-types/reusable-field-schemas.md) in the _Content_ view to provide fields for SEO, Open Graph, and other systems and frameworks that the project needs to support.

Front-end designers need to orchestrate the Page Builder components so that the markup they provide returns correct semantic HTML elements such as `main`, `article`, or `section` elements and that the page's content hierarchy follows [web standards](https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Structuring_content/Headings_and_paragraphs#implementing_structural_hierarchy), making the content structure ready for search engines, accessibility tools and AI agents.

Developers need to consistently apply [structured metadata](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) to maintain a transparent, machine-readable data layer across all pages.

> **Tip:** Since AIRA content capabilities [are evolving](https://roadmap.kentico.com/c/320-ai-content-auto-tagging), we recommend integrating a 3rd-party solution to validate your pages using SEO and accessibility tools as part of your publication workflow.  Also, specialists should periodically review website content and markup to ensure editors follow structured data practices. They need to align the digital content with evolving search engine requirements and ensure your content remains discoverable within AI-driven search contexts.

## What's next?

You’ve learned how to define a page-based content model to help editors understand and manage their content. They will store most of their data in website channel pages and put all reusable content, including images and other assets, in the _Content hub_. In the next section, you'll learn about creating a highly reusable content experience using [atomic content model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md). You'll learn how to build a model that makes the core content independent of any presentation layer and allows strategic reuse across different systems.