DEV Community

Cover image for Kentico Xperience Design Patterns: Content Hierarchies
Sean G. Wright
Sean G. Wright

Posted on • Updated on

Kentico Xperience Design Patterns: Content Hierarchies

In a previous post we looked at how we can model πŸ—Ώ content with Page Types and learned about the value of content governance πŸ§‘πŸ½β€πŸ«.

In this post we'll continue our Content Tree Architecture exploration by learning about Content Hierarchies.

This is Part 2 of 4 in a series on Content Tree Architecture in Kentico Xperience 13. You can read Part 1, Part 3, or Part 4.

πŸ“š What Will We Learn?

Parent-Child Relationships

Content models, when combined with sitemaps, reveal a natural hierarchy of content πŸ€”.

As two examples, a Video Library landing page likely has child Video pages and a Product Line page usually has child Product pages.

A sitemap with a parent-child hierarchy

This list-detail pattern is very common in content hierarchies but it's not the only one 😯.

A site might have an Office Location page for each regional office. The Office Location pages could then have a child page for each employee at that office. The Office Location page might not show all the employees working at that location, but it can make sense to organize the employees as children of the Office Location anyway.

Multiple levels of parent-child hierarchy in a sitemap

With this parent-child relationship in mind, we might be inspired to go and create parent and child Page Types for every content model for our site. There's nothing wrong with this approach, but there is also a better alternative 😎.

Groups and Containers

As we already noted, a Video Library landing page is very likely to have child Video pages somewhere in its descendant page hierarchy. These could be direct descendants as seen in this screenshot of the Xperience Content Tree:

Content Tree with a simple parent-child relationship

As our content structure and site matures, an issue we will encounter with the direct parent-child structure is there's no good place to add other types of structured content πŸ˜”.

What if we want to create some structured Call To Action pages that are placed on the Video Library page with the Page Builder? Where would those go in this example 🀷🏻? We could add them as direct children of the Video Library next to the Videos, but then as the number of Video pages grows, the Call To Action pages will get lost in the list 😧.

Imagine another scenario where we have 5 Video pages being created every business day. By the end of the year there could be nearly 1,300 Video Pages in the Video Library - finding a specific Video could be difficult 😫, especially if we're using the Page Selector to select a Video page to feature somewhere else on the site in the Page Builder.

This rate of content growth would also result in more child pages than Xperience recommends for the Content Tree - "each item (page) in the content tree have at most 1000 direct child pages."

A better approach, which takes a little more setup, is to create organizational Page Types and insert those under the Video Library page - all child content would then be contained in the organizational Page Types πŸ€”:

Content Tree with more complex hierarchy using organizational pages

Above we can see there are several new pages in the Content Tree (Page Name - Page Type):

  • Videos - Video Container
  • 2022/2023 - Video Year
  • 01/02 - Video Month
  • CTAs - Call To Action Container
  • Try Our Coffee For the Full Experience - Call To Action

If your are interested in trying out a prescriptive approach to creating these container pages, check out fellow MVP Mike Wills' Page Asset Folder Module library πŸ‘πŸΌ.

Hierarchy and URLs

In the past, we often needed to consider the impact that the Content Tree structure would have on the URLs generated for each page. Adding too much structure could lead to overly verbose URLs and the need for aliases and URL shorteners πŸ› οΈ.

Thankfully, Kentico Xperience 13's Content Tree based routing system is more nuanced and easily customizable. It's up to us, when creating Page Types, to indicate whether a Page Type influences the generated URLs.

Organizational or container Page Types can have the URL feature disabled, which means their existence isn't reflected in the Live site URL structure - they exist purely to make content governance easier for marketers πŸ’ͺ🏻.

Visual diagram showing the impact of the Page Type URL feature on generated URLs

From the Xperience documentation

In more advanced scenarios, this added content structure can be leveraged to add Page-level access control lists (ACLs) to what content is visible to users. This applies to both visitors to the Live site and content creators in the Admin application πŸ™ŒπŸΎ.

Content Tree ACL management

From the Xperience documentation

The disconnection of Live site URLs and content structure from the Content Tree lets us tune content organization to meet content governance needs while also prioritizing visitor experiences πŸ€“.



Generally, we model content with Page Type fields but we also need to model content relationships.

A well thought out (and understood) content hierarchy will help our sites scale both in the amount of content (thousands of videos, as an example) and future content usability. What features or new types of content will we need to add that haven't even been imagined yet 🧐!?

The Xperience documentation has specific guidance for sites with a large number of pages in the Content Tree and it aligns with what has been presented in this post.

Ok, so we have some guidelines... but how do those apply to our site's content and requirements? It might not be clear what the best approach is - for developers or content managers πŸ€·β€β™€οΈ.

I recommend planning a few different content structures. Talk with stakeholders about this plan and then demo the Content Tree variations in the Xperience Admin so they can see πŸ‘€ an implementation of the abstract concepts.

Don't get too caught up generating all the Page Type fields or code. We don't even need the Live site running at this point, because the goal is to have a visible Content Tree and identify any areas where scalability, requirements, or complexity haven't been resolved πŸ“.


We should try to define a naming convention for Page Types to better represent how a Page Type is being used, because with dozens of landing, structured content, and organizational Page Types, things can get confusing πŸ₯΄ if we aren't intentional.

Not only are the names of Page Types reflected in the Administration application (primarily in the Content Tree), but also in the application code.

Our goal should be to align the names of Page Types with how stakeholders (content managers and marketers) would name them so we have a ubiquitous language 🧠 across teams. We also want to help developers be able to make safe assumptions about their use when they see them referenced in code πŸ€“.

Personally, I like using the conventions below, but yours don't have to be identical:

  • Suffixing Page Types with the URL feature enabled with Page (ex: HomePage).
  • Suffixing Page Types that is reusable structured content with Content (ex: NavigationContent).
  • Suffixing Page Types that are organizational or are less important than their children with Group (ex: CTAGroup).

You can read more about Page Type naming conventions in the Kentico Xperience 13 Style Guide.


It's worth pointing out again that the robust content organization we've been reviewing doesn't have to affect our URLs since Xperience allows us to enable or disable the URL feature for each Page Type πŸ™‚.

Disabling it for an organizational Page Type means it won't participate in URL generation for any child pages that do have the URL feature enabled. This lets us organize content as needed while also ensuring our URLs and content structure match the project planning sitemap βœ”οΈ.

This is a feature that's new to Kentico Xperience 13 and can free content managers from the tyranny of the "Content Tree is Sitemap" mentality πŸ˜’ (we'll touch on this idea again in a later post).

Try exploring it to see how you can improve content governance without negatively affecting the live site experience for visitors.

More Page Types, not Fewer

It's extremely important to note that in the Video Library example we reviewed earlier, each of the organizational Page Types is a different Page Type. Although we could create a generic "Container" or "Folder" Page Type that can organize anything, this approach would lose 😬 one of the most important benefits of these organizational Page Types.

As we will see in a later post, the Allowed Page Types feature in Xperience is extremely powerful and can lead to amazing content governance, but it requires a broader set of Page Types to leverage fully πŸ€”.

In general, we shouldn't feel discouraged from creating more Page Types. We should create as many as we need to help ensure a well structured and easily governable content tree πŸ‘πŸ½.


Modeling content is an extremely important step in implementing an effective and maintainable website. But content in Xperience isn't only the individual structured fields of a page - it's also the relationships between those pages. This relationship modeling can be achieved through the organization of content hierarchies in the Content Tree 🧐.

There's also an aspect of content governance that benefits πŸ˜‡from a well structured Content Tree in a Kentico Xperience site.

Adding layers of abstraction to the Content Tree can lead to a more manageable site, long term. It can make it easier to find content and result in a more intuitive experience for content managers πŸ€—. Thanks to Xperience's flexible URL feature, we don't have to sacrifice live site URLs or visitor experience for these administration improvements.

These benefits don't come for free. We will need to spend time planning the Content Tree structure after identifying our content models and pages in the visual sitemap. Creating a sample Content Tree structure can help in this planning process πŸ—ΊοΈ by turning the abstract into something more concrete for stakeholders without too much work.

In the end, content organization is one of the tools we can invest in to help content managers and marketers with the work they do customizing a site's experiences, every day.

As always, thanks for reading πŸ™!


Photo by Jordan Madrid on Unsplash

We've put together a list over on Kentico's GitHub account of developer resources. Go check it out!

If you are looking for additional Kentico content, checkout the Kentico or Xperience tags here on DEV.



Or my Kentico Xperience blog series, like:

Top comments (0)