---
title: Design website 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).
## 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.
## Content tree hierarchy and page structure in website channels
In website channel applications, editors and marketers manage all the content they publish to their site. The content lives in a hierarchical structure called the _content tree_.
Not every item in the content tree necessarily needs to **represent an actual page** on the website. From a presentation perspective, we recognize **three types of content** stored **in the content tree hierarchy**:
| Type of content | Content from the presentation perspective |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Content types for pages accessible under a URL** | Website pages accessible under specific URLs (e.g., _mysite.com/Home_).
Pages with URLs can have properties to define the URL slugs, categorize the content, and contain custom fields to adjust the content's SEO properties.
Media library file URLs are accessible through custom code. |
| **Content types for pages without a URL** | Not accessible directly under a specific URL.
Serve as building blocks editors can use to create strictly-ordered hierarchies.
Typical (but rare) examples include modeling different company offices or team organizations. |
| **Folders** | Folders don't store any content. They are used to create taxonomies within the content tree to make navigation easier for editors. |
> **Info:** **Content tree-based routing**
>
> Depending on the website implementation, the [content tree-based routing](https://docs.kentico.com/documentation/developers-and-admins/development/routing/content-tree-based-routing.md) feature can generate page URLs based on their position within the content tree hierarchy. Learn more about features related to pages with URLs:
>
> - [Routing](https://docs.kentico.com/documentation/developers-and-admins/development/routing.md)
> - [Manage page URLs](https://docs.kentico.com/documentation/business-users/website-content/manage-page-urls.md)
## Create and organize website channel content
Xperience allows you to treat _website channels_ as first-class citizens within your digital ecosystem. This means editors can create, manage, and design website content directly within the website channel application and they don't need to switch between different contexts during their daily work. Editors can **add or reuse content** from the [Content hub](https://docs.kentico.com/documentation/business-users/content-hub.md), **craft channel-specific structured content**, or create and adjust content **directly within the webpage** using [Page Builder](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder.md). Or, they can approach the [website channels](https://docs.kentico.com/documentation/developers-and-admins/configuration/website-channel-management.md) as one of the presentation layers that is on the same level as other [digital marketing channels](https://docs.kentico.com/guides/digital-marketing/work-with-channels/digital-marketing-channels.md), and manage all their reusable content from the _Content hub_.
Content within a website channel can **be navigable** (forming part of the site’s structure and URL hierarchy) or **non-navigable**.
Developers can create **content templates** to display structured data dynamically. This ensures that the same content looks consistent across the website, but limits editorial control over design and layout. Alternatively, developers can design **page templates** that include _Page Builder_ zones. _Page templates_ provide editors with a flexible editing experience to manage page layouts, expose custom-built [page template properties](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder/page-templates-for-page-builder/page-template-properties.md), and contain _Page Builder_ widgets and sections.
Before we dive into details you'll use in designing your content strategy, remember:
- Data in the _Content hub_ is always reusable and can support multi-channel delivery.
- Data stored in a _structured format_ within the website channel can be reused across the website and email channels where needed.
- Content added directly within widgets in _Page Builder_ is page-specific and not reusable across other pages or channels.
> **Note:** We will discuss different options for displaying content in the website channel. For further details how to structure your digital content, see the dedicated materials on the [atomic content model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md) and the [page-based model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-page-based-content-model.md).
## Design content for a website flow
You can design and present content using these Xperience features – or any combination of them:
- **Predefined content templates**
- Displays only structured content (that is stored through the [page](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-page-based-content-model.md) or [Design atomic content models](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md) )
- Define a layout for content based on the content types.
- Can be bound only to specific content types (e.g., layouts specifically for articles or blog posts, testimonials, etc.).
- Either assigned automatically or selectable by editors when creating pages.
- Created and managed by the developers.
- We recommend using content templates for content that needs to be tightly controlled.
- **Page Templates**
- Need to have _Page Builder_ enabled, but don't need to contain widgets or sections.
- Enables editors to adjust the layout of entire pages or specific sections dynamically.
- Often combined with predefined templates to allow editors to further customize options for displayed content.
- Created and enabled by developers but maintained by editors.
- This approach is suitable for most website pages.
Depending on your project's implementation, content editors can have different options to create pages and manage their content. The most common workflows are:
- Editors [use predefined templates](#design-content-using-templates) to present _structured content_. _Page template properties_ give editors limited control over the final appearance of the content they produce. Instead, the page's overall layout is determined using MVC view files assigned to each content type. This approach ensures that all pages of a specific type (e.g., articles, event, or product pages) use a layout from a predefined set of designs.
- Editors [modify the page content and its layout using Page Builder](#design-content-using-page-builder) and provided components – widgets, sections, or Page Builder templates. This approach allows you to combine structured and unstructured content using dedicated Page Builder components.
- For example, using widgets that select a collection of _Article_ pages (structured content) and enable additional formatting options such as a custom _Call to action_ widget, the number of articles displayed per line, or personalized content, such as featuring different articles based on the visitor type (unstructured, Page Builder-specific content).
## Design content using templates
Templates can combine means to display structured content with areas editable by Page Builder.
Xperience recognizes two types of templates:
1. **Page type templates**
- A _page content type_ can define a static display template for each page with or without options for editors to adjust it. We recommend using this type of template if you need to enforce a unified look and feel for all pages of a particular type (e.g., blog posts), without giving the editors additional freedom of customization.
- These templates do not require the Page Builder, which can simplify its production workflow – editors only fill in the necessary fields with their content, and the page is ready to go live. The type of the created page predetermines its design and layout.
- To learn more about how to set up these types of templates see [Set up content tree-based routing](https://docs.kentico.com/documentation/developers-and-admins/development/routing/content-tree-based-routing/set-up-content-tree-based-routing.md#implement-routing).
> **Tip:** Static content layout doesn't need to span over the whole page. We recommend that even for pages, like listing, product, or article pages, developers enable editors to work with _Page Builder_. This will allow editors, for example, to tailor the "unified content piece" with [personalized](https://docs.kentico.com/guides/digital-marketing/xperience-essentials/personalize-website-content-essentials.md) messaging. See article pages in the Kbank demo site for reference.
2. **Page Builder templates**
- _Page Builder templates_ allow content editors to choose from _predefined page layouts_ when creating new pages.
- Editors can use page templates to present _structured content_, _Page Builder_ content, or a combination of both, as described below.
- Developers prepare the templates and assign them to _webpage content types_.
- Each content type can have multiple _default page templates_ to display content. When editors create a new page, they pick the most suitable template configuration. They can also save their _custom template configurations_ into page _Presets_ and [use these presets for creating new pages](https://docs.kentico.com/documentation/business-users/website-content/page-templates.md#save-pages-as-preset-page-templates).
Both template types may optionally include [Page Builder sections](#design-content-using-page-builder) to provide editors with further customization options using available Page Builder components. This type of content composition is widespread in many Xperience projects.
> **Tip:** **Recommendations – templates**
>
> We recommend basing every [webpage content type](https://docs.kentico.com/documentation/developers-and-admins/development/content-types.md#create-content-types) on _page templates_ with [configurable page template properties](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder/page-templates-for-page-builder/page-template-properties.md) and enable them for most of the pages. This gives editors additional capabilities, like [save and reuse page template configuration](https://docs.kentico.com/guides/digital-marketing/work-with-websites/create-a-reusable-landing-page-template.md). Pages that are not based on page templates **cannot be switched to use page templates later** in the development cycle.
> **Tip:** **Recommendations – page presets**
>
> To speed up content production and publishing, we recommend creating _custom page presets for pages that work with Page Builder_.
>
> For example, a senior editor can create an empty page using the default page template, configure its layout with required sections and (empty) widgets, and save the configuration as a page _Preset_. When editors create a new page of this type, they'll start working on a preconfigured page. This helps with content production and helps keep design consistency between pages with the same underlying content type.
## Design content using Page Builder
[Page Builder](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder.md) is a user-friendly interface where non-technical users manage the content and layout of pages using configurable components.
Editors work with _Page Builder_ in [website channels](https://docs.kentico.com/documentation/developers-and-admins/configuration/website-channel-management.md). They can build entire pages (or their sections), experiment with different layouts and page designs, and immediately see the results. Equipped with widgets and sections, editors can lay out content without asking developers for help whenever they want to build a new page or adjust the design of an existing page. Given the flexibility it provides to marketers, _Page Builder_ is well-suited for frequently updated or campaign-focused pages.
[Page Builder](https://docs.kentico.com/guides/development/page-builder.md) allows content editors to design parts or whole pages wherever developers enable it (by defining [editable areas](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder/create-pages-with-editable-areas.md)). Editors can use two types of components to format content using _Page Builder_: [sections](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder/sections-for-page-builder.md) and [widgets](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder/widgets-for-page-builder.md).
**Sections** specify the visual layout for widgets. They represent reusable pieces of markup that can store an arbitrary number of **widget zones** – areas where content editors place _widgets_.
**Widgets** are reusable components that content editors and non-technical users can quickly work with. Widgets give users more power and flexibility when adjusting page content and basic editing of text and images. By working with widgets, users decide which components are placed where on the page.
### How Page Builder stores content
Developers prepare _Page Builder_ components based on project requirements.
_Page Builder_ stores widget content per instance, not as reusable structured data. Before choosing it to store specific content, ask whether this content will ever need to appear in more than one place, for example, in a listing, a search result, another page, or a different channel. If yes, _Page Builder_ is the wrong storage approach. Store the content in the _Content hub_ instead, and give editors a display widget to render this piece of content where they need. You can also provide editors with [widget properties](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder/widgets-for-page-builder/widget-properties.md) to override values retrieved from the _Content hub_.
If content reuse is not a requirement for a given page or section, the per-instance model is a reasonable fit.
When you are deciding how to use _Page Builder_ in your project, also consider the following:
- Layout vs. content control. Does this content type require editors to control the layout, or only the content? For many webpage content types, especially in enterprise-size projects, layout is a developer concern and should be defined in code to ensure consistency. Introducing _Page Builder_ widgets to store content adds flexibility that editors might not need.
- Scope of enablement. Consider webpages where editors should be able to change layout without creating formatting issues or introducing design inconsistencies. The larger the number of _Page Builder_ pages, the harder this risk becomes to manage. One approach is to enable _Page Builder_ only for specific page areas. This gives marketers control on-page engagement and guide visitors through the [customer journey](https://docs.kentico.com/guides/customer-journeys.md), while keeping the overall content design consistent.
- Content governance and longevity. Widget instances store content independently. The more instances that duplicate the same content, the more difficult content audits and bulk updates become.
### Understand how Page Builder stores content
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 (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** or the **project's upgradeability**.
### See the different types of Page Builder widgets
Developers can prepare widgets to handle content in three ways:
- [Widgets that present structured content](#widgets-that-present-structured-content)
- [Widgets that store and design the content at the same time](#widgets-that-store-and-design-the-content-at-the-same-time)
- [Widgets that combine both inline editing and structured content](#widgets-that-combine-both-inline-editing-and-structured-content)
### Widgets that present structured content
Editors add these widgets into appropriate _Page Builder_ sections and select the content to display. Xperience can store the content itself in one of the following locations:
- **As content items in the Content hub**.
The widget serves only as a design container for the content stored in the _Content hub_. For example, a _Promotion_ widget displays data stored in the _Promotion_ content type. The editor either selects an existing promotion item, or creates a new one through widget properties:
- **Elsewhere in Xperience website channel application.** The widgets serve only as design containers for the content stored (and presented) elsewhere. For example, as shown below, editors can add a widget to a page and configure its source page using the _Combined content item_ selector. The widget displays only several properties of the _Article_ content type:
🎬 [Video](https://docs.kentico.com/docsassets/guides/design-website-content/Xkb-Adding-A-Structured-Widget.mp4)
#### What does working with the reusable content look like?
For example, imagine editors are building a campaign landing page.
The page will contain a _Hero_ element. From the design perspective, editors should select only the _Hero banner_ content type from the _Content hub_ to populate a **Banner widget**. From the editor's perspective, adding reusable content to the page and displaying the structured data might look like the following video:
🎬 [Video](https://docs.kentico.com/docsassets/guides/design-website-content/xbyk-content-modeling-addding-banner-widget.mp4)
An editor adds a banner widget to the page. Instead of using the page data as source for the _Banner_ widget, editor selects a custom hero banner content item from the Content hub.
When modeling the content storage, always consider the editor's workflow. Help them understand what type of content they're supposed to select.
For example, you can use instructions next to the selectors in the widget [properties](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder/widgets-for-page-builder.md) and your project documentation to ensure editors receive enough guidance. As you can see in the image below, editor instruction explains that editor needs to select only one café from the content tree, and a note that the selected café item should include a photo for the best visual experience.
Similarly, ensure that editors will not unintentionally break the page experience by selecting content that doesn't belong.
- Developers can restrict the selection to pages of specific _webpage types_ that fulfill required conditions (e.g., have the URL feature enabled). See samples of the Xperience selectors in [Reference - Admin UI form components](https://docs.kentico.com/documentation/developers-and-admins/customization/extend-the-administration-interface/ui-form-components/reference-admin-ui-form-components.md). For example, the pages that editors cannot select are grayed out in the _Page selector_ component.
- Similarly, developers define which type editors select into the widget properties, such as the _Benefits_ widget in the Kbank demo site. First, editors use radio buttons to choose between a _Product_ benefit or a _Company_ benefit. Then, they decide whether benefits appear with a dot, a number, or an image. Finally, they select specific benefit content items from the _Content hub_.
### Widgets that store and design the content at the same time
With these _single-purpose content widgets_, editors can manage the content in a WYSIWYG manner using [inline editors](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder/widgets-for-page-builder/inline-editors-for-widget-properties.md), use the widget's properties and add content through the widget's configuration dialog, or combine both. The out-of-the-box _Rich text_ widget is an example of a widget with advanced text styling capabilities.
The _Banner_ widget on the Dancing Goat [sample site](https://devnet.kentico.com/articles/kentico-xperience-sample-sites-and-their-differences) shows both _inline editors_ and _widget configuration properties_ where all the input data is stored within one database field.
Similarly, the _Page heading_ widget on [Kbank demo site](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/what-is-a-content-type.md#best-practices-in-kbank-demo-site) allows editors to add content, such as a title, decide on the heading type, and adjust its margin using dropdown selectors in widget properties.
### Widgets that combine both inline editing and structured content
_Mixed-content widgets_ allow editors to reuse structured content, e.g., by providing a selector to pick content from the content tree. At the same time, editors can use the widget’s editable properties to overwrite some of the content pulled from the selected page or create brand-new content. Editors can also provide additional information or behavior to their content, such as ensuring that hyperlinks to external websites open in a new tab.
The image above shows _Card_ widget properties where editors can customize all content and the content to which the widget links to. Editors can also:
- Link the card to a page either by entering a URL or selecting a page from the content tree, and using the target page as the source of the data for the widget, or providing custom values to override this data.
- Add a custom title and a formatted summary using a rich‑text editor.
- Assign a different card image by selecting an existing asset or creating a new one.
- Define button label text, link text for a call‑to‑action, and an optional external link, and use a checkbox that ensures the link opens in a new tab.
> **Tip:** We recommend limiting the use of mixed-content widgets to specific pages (sections), as content stored in these widgets can be more difficult to reuse in other channels.
### Drive displaying data using taxonomy
Design dedicated widgets to consume [taxonomy terms](https://docs.kentico.com/documentation/developers-and-admins/configuration/taxonomies.md) as input and dynamically display content based on those terms to support taxonomy-driven content. For example, a _content listing widget_ should allow editors to select a [taxonomy tag](https://docs.kentico.com/guides/digital-marketing/work-with-taxonomies/taxonomies.md) or [smart folder](https://docs.kentico.com/documentation/business-users/content-hub/content-hub-folders.md#smart-folders) as a filter. The widget then queries and displays only the matching items. It should also offer options to exclude certain content, such as by listing available tags or applying an "exclude from display" tag in article itself, to give editors more control over the final output. Ideally, the widget will allow editors to wrap the listed content with additional content (e.g., text or visuals) to ensure that content remains reusable and manageable directly from the _Page Builder_.
### Recommendations – Page Builder
> **Tip:** **Combine structured content and widgets**
>
> To make the website’s content both reusable and future-proof, we recommend storing the content of the widgets using the structured content format. Developers should prepare widget properties that allow editors to format content using WYSIWYG editing capabilities.
>
> Based on the project requirements, the structured content of widgets can be stored in a dedicated section in the content tree or directly in a hierarchy under the page as child items.
> **Tip:** **Limit using widgets for single-purpose content**
>
> Xperience stores the content input directly into widgets within one database field for the whole page. We recommend storing content in widgets only when the content is not going (or doesn’t have the potential) to be reused on the website. This content can work on one-off pages, such as campaign landing pages.
> **Tip:** **Create sections with designing capabilities**
>
> We recommend creating sections with properties to let editors define how the content they add via widgets displays on the website. Some examples of section properties are a field for a URL parameter (Anchor tag) for deep linking, a property to define the number of columns within the section, a property to adjust the margin or padding of widgets, and changing the color of the section, and similar properties.
> **Tip:** **Set restrictions on editable areas**
>
> Use editable area restrictions to ensure editors can add only desired widgets or sections to specific areas. This ensures page designs do not break (e.g., in different browsers) and creates boundaries for data predictability (when considering future upgrades). Find out more in [Create pages with editable areas](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder/create-pages-with-editable-areas.md).
> **Tip:** **Create custom widgets to add markup to pages**
>
> Typically, in the early stages of a live project, editors might need to add custom HTML markup or include scripts to embed 3rd party applications. Project owners sometimes need to remember this or similar scenarios when detailing project requirements, so ensure your project gets this low-hanging fruit to make editors happy.
>
> We recommend creating custom widgets that allow editors to add scripts or HTML markup to the page's _head_ or _body_. For example, editors might use an _Anchor widget_ to enable linking to a section of the page or a _Script widget_ to add JavaScript that runs a custom-built mortgage calculator.
>
> If editors will reuse these scripts or markup on different pages, developers can prepare a custom _Script_ content type or widget.
> **Tip:** **Add instructions to selectors in Page Builder components**
>
> When building widgets that display structured content, provide editors with clear instructions describing what content items they should select. You can use the **ExplanationText** [widget property](https://docs.kentico.com/documentation/developers-and-admins/customization/extend-the-administration-interface/ui-form-components/editing-components.md) and provide contextual information specific to the selected widget. Providing additional guidance ensures that editors don't break the visual experience of the website by mistake. Also, include clear instructions about how editors should use every widget on the website in your project documentation.
> **Tip:** **Make designing content generic**
>
> Though you might want to store design-specific information, like exact color codes or sizes, inside the channel-specific or reusable content types in the _Content hub_, 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 change the specific _#F05A22_ brand color code in hundreds of different places. The following screenshot shows styling options in the Kbank demo site, allowing editors to only use predefined background styles, such as Default, Primary, Secodary, or Card using a dropdown selector.
>
> 
> **Info:** In typical Xperience projects, **these three approaches are combined together** to create an effective content management experience that supports reusing the content as necessary. Stakeholders must decide how they'll work with the content when defining the project requirements. However, to make your content future-friendly, we recommend storing it in a structured format.
## What's next?
You've learned about the different components editors can use to design Xperience pages. On the [next page](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md), you'll learn about different approaches to storing the data using two different content models - the [atomic content model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md) that supports high-content reusability. Then, we'll discuss the [page-based content model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-page-based-content-model.md).