Best practice for handling custom page data in Xperience by Kentico

I’m currently working with Xperience by Kentico and exploring different approaches for managing custom data used across multiple pages.

I understand there are several options available, such as custom page types, reusable content items, or custom data classes. I’d like to better understand which approach is generally recommended when the same structured data needs to be reused across multiple sections of a site without duplicating content.

Specifically, I’m interested in:

  • When to prefer content items over page types

  • How to keep content manageable for editors while maintaining flexibility

  • Any performance or maintenance considerations to be aware of

I’ve reviewed the documentation but would appreciate real-world guidance or examples from those with hands-on experience.

Thanks in advance for your help.

1

Answers

Accepted answer

In Xperience by Kentico, the clean mental model is this: Content hub items are for reusable, canonical content that may appear in multiple places (and even multiple channels), while page types are for channel-specific content that exists because a page/URL exists in the site tree.

Use Content hub (reusable) content types when the same structured data needs to be referenced across multiple pages or sections—things like people, locations, CTAs, testimonials, FAQs, or shared promos. You create it once, reuse it everywhere, and updates propagate automatically.

Use page types when the content is tied to a specific website channel, URL, navigation structure, or page-level workflow. Pages are about context and composition; reusable items are about owning the data.


For editors, the pattern that scales best is: pages compose content, reusable items supply the data. Editors build pages with Page Builder and select Content hub items where needed, keeping duplication low while staying flexible.


From a performance and maintenance standpoint, the choice is less about pages vs. reusable items and more about how you query and model relationships. Keep reusable types focused, avoid deep over-linking, batch queries, and cache where appropriate.


If the data is operational or system-owned rather than editorial (settings, integration state, logs), that’s when custom data classes make more sense.

2

To add to Mike's response, there is some content and discussions about this topic here on the Kentico Community Portal:

Discussions

Articles

Also, take a look at the discussions for these posts!

Additionally, we have some fantastic guides on content modeling to help you learn the options available and use cases for each.

2

I'll only add an answer to your last point:

"Any performance or maintenance considerations to be aware of"

Performance - The Content hub and it's API is insanely fast. I can query and build my entire interactives library (which when adding the child and grandchild items can reach tens of thousands of items) in less than a second, and it's all strongly typed models. As with anything, it's usually the round table that's the 'largest' hit, so as long as you aren't making a ton of DB calls, you should be absolutely fine.

If you really are in doubt, it's very easy to query the entire thing, cache it in a dictionary and retrieve. Set the dependency keys right and you won't ever notice anything.

Sean had the Community site un-cached for a long time and it still ran extremely fast.

1

To response this discussion, you have to login first.