---
title: Taxonomies deep dive
---

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

## Two approaches to taxonomies in Xperience

Taxonomies can serve different purposes in Xperience, depending on how you categorize and retrieve your content. We have identified two primary use cases: **semantic** taxonomies and **functional** taxonomies.

### Semantic taxonomies

_Semantic taxonomies_ are broad, general classifications that organize content by type or theme rather than function. They include categorizing e-shop products like electronics and furniture, or content types such as news, press releases, blog posts, and guides. By grouping related content under high-level themes like “technology,” “health,” or “finance,” these taxonomies help users quickly find relevant information and provide editors with a clearer view of the content landscape. Editors can use the built-in hierarchy of the tree and further break down their topic categories. For example, the _finance_ category can include articles about bank's _Loan_ products that cover topics such as _Student loans_, _Personal loans_, or _Home equity loans_.

The following image shows the _Loans_ taxonomy from the [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).

![Example of a semantic taxonomy on Kbank demo site](https://docs.kentico.com/docsassets/modules/taxonomy-types/cm-semantic-taxonomy-finance-group.png "Example of a semantic taxonomy on Kbank demo site")

The hierarchical taxonomy structure contains a _Product type_ as the top‑level category, expanded to reveal subcategories such as _Account_ and _Loans_ tag group. The _Loans_ group stores tags for individual loan types like _Car Loan_, _Credit Builder Loan_ or _Home Equity Loan_. The hierarchy contains additional sibling categories, such as _Insurance_ and _Credit cards_ that appear at the same level as _Loans_. Together, they form a clear, multi‑level tag hierarchy for organizing financial products.

This approach is beneficial for extensive content collections, as it allows editors to present related articles together on a single page or section, making it easier for users to explore similar topics. Additionally, semantic taxonomies enable content recommendations by linking items with shared tags, which enhances user experience and increases content visibility. This can particularly helpful for categorizing media _Assets_ in the _Content hub_.

To sum up, _semantic taxonomies_ provide valuable metadata that editors can use to support content discovery, organization, and maintain a consistent content structure.

### Functional taxonomies

On the other hand, _functional taxonomies_ are designed to help with filtering and data retrieval or to drive specific UI behaviors. For example, you can use _functional taxonomies_ to filter a list of services based on their relevance to a persona or to populate dropdowns with content options in [Page Builder widgets](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder.md). Since these taxonomies are tied closely to functionality, keeping their scope specific to particular content types is essential. For instance, if you’re working on a financial website, you might create a taxonomy for financial product features or regional availability information, each tied to a specific use case.

Each functional taxonomy should have a clear, 1:1 relationship with a specific use case. This will allow content managers to keep the editing experience intuitive and reduce the risk of accidental changes that could disrupt functionality elsewhere in the system. By structuring functional taxonomies into small, clearly defined taxonomy groups, you’re adding a layer of protection that ensures editors only interact with taxonomies relevant to their tasks.

![Example fo a functional taxonomy on the Kbank demo site](https://docs.kentico.com/docsassets/modules/taxonomy-types/cm-guide-functional-taxonomy-regional-availability.png "Example fo a functional taxonomy on the Kbank demo site")

In contrast to the hierarchical taxonomy shown earlier, the image displays a flat list of selectable tags under _Regional Availability_ taxonomy, where each country, such as the Netherlands, Canada, Mexico, Czechia, Spain, France, Germany, the United States, and the United Kingdom, appears as an individual checkbox without any parent–child structure. This makes the taxonomy group and its tags an easy-to-understand, non‑hierarchical set of standalone options.

### When to use taxonomies in Xperience

Relationships defined through taxonomies (and their tag collections) in Xperience are considered “soft.” What does it mean?

There’s no built-in safeguard to prevent editors from altering or updating tag collections if they have access to the _Taxonomies_ application. This flexibility is helpful for many content scenarios, but it's important to remember that Xperience doesn't tightly control any changes in tag collections.

That's why solution architects should design the implementation to use taxonomy for content categorization and organization rather than for situations which require strict control over tag and data integrity. If you need to protect your content relationships from unintentional changes or resurfacing information in unwanted scenarios, for example, for information security reasons, we recommend using custom [content type fields](https://docs.kentico.com/documentation/developers-and-admins/development/content-types.md) on individual content or website page types and combining them with securing [access to content items](https://docs.kentico.com/documentation/developers-and-admins/configuration/content-hub-configuration.md).

Taxonomies can drive various content delivery scenarios. For example, you can use taxonomies with [Page Builder](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder.md) to list all items or pages tagged with a specific category, allowing for dynamic content display. However, avoid relying on taxonomies when you need to ensure restricted access to sensitive data. Instead, use custom fields within content types to enforce more secure access control.

The taxonomy selector is built into applications that deal directly with content, including website channels, the _Content hub_, email, and headless channels. However, it’s unavailable in areas like **Contact Management** or **Contact groups** applications or in [custom classes](https://docs.kentico.com/documentation/developers-and-admins/customization/object-types.md), though this might change [ in the future](https://roadmap.kentico.com/c/238-contacts-auto-tagging-powered-by-aira). Taxonomies are not versioned, and there are currently no plans to add versioning capabilities.

### Custom content type to replace built-in taxonomy

In Xperience, tags have predefined fields and currently offer limited customization options. If you need to add custom fields to your taxonomy tags, consider building a custom solution using dedicated content types.

For projects that require more complex content categorization, you can work with developers to build custom functionality. This approach allows you to:

- Define exactly how editors categorize content within the administration interface.
- Control how references are stored within a custom application.
- Specify the taxonomy system’s complexity, including elements like the number of parent-child levels or a tagging structure.

> **Note:** The Khealth demo referenced below is an older, retired implementation and is no longer publicly available. However, the modeling patterns it demonstrates remain valid and can still guide solution design.

The following image shows a healthcare Provider content type that uses a custom content type to define relationships using the _Combined content selector_ to define services and locations where the doctor provides practice.

![Provider content type uses dedicated content types Location and Service to indicate relationships](https://docs.kentico.com/docsassets/modules/taxonomy-types/cm-guide-custom-taxonomy-types-on-in-content-item-khealth-demo-site.png "Provider content type uses dedicated content types Location and Service to indicate relationships")

> **Info:** **Pattern takeaway:** You can model domain relationships with dedicated content types and connect them through selectors when built-in taxonomy fields need richer structure.

Developers can display references between the content types on a healthcare provider profile page. The following legacy Khealth example illustrates a card-like widget that displays a linked _location_.

![Profile page shows content displayed from linked content items](https://docs.kentico.com/docsassets/modules/taxonomy-types/cm-guide-custom-taxonomy-types-khealth-demo-site.png "Profile page shows content displayed from linked content items")

> **Info:** **Pattern takeaway:** You can resolve linked content on detail pages to surface related entities consistently and avoid duplicating relationship data across content items.

The same relationships can drive faceted filtering on a search page, for example as a _doctor's address_ in a card-like element and as an _item in a search filter_.

![Taxonomy defined through custom content types drives filtering in a legacy Khealth demo](https://docs.kentico.com/docsassets/modules/taxonomy-types/cm-guide-custom-faceted-taxonomy-types-khealth-demo-site.png "Taxonomy defined through custom content types drives filtering in a legacy Khealth demo")

> **Info:** **Pattern takeaway:** You can reuse the same relationship model for both presentation and faceted filtering so editors maintain one source of classification truth.