---
title: Compose related content to ProductSKUs
---

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

## Compose related content to ProductSKUs

Products are rarely a standalone entities, they often relate to other content entities. They are created by companies, categorized, related to other products, and linked to supporting content. How you model these relationships impacts content reusability, editor workflows, and system maintenance.

Aside from the component content that constitutes **ProductSKU** items, such as _Product features_, _Image_, and _Video_ items, related content that needs to include:

- Manufacturers/Brands/Suppliers – Companies that produce or supply the products.
- Product categories – Groups, such as _Dog Food_, _Cat Toys_, _Aquarium Supplies_.
- Related products – Items for cross-selling or complementary use.
- Articles – Educational content on pet care and product usage..
- Testimonials – Customer reviews and feedback.

For each relationship type, ask whether it should be modeled as a **dedicated content type**, **embedded** as a **reusable field schema** (RFS), or managed through **taxonomies**?

For _Pawsome Pets_, the content modeling MCP server structured _brands_ as a content type field and categorizing products using _taxonomies_. This is a valid approach, but it may not fit every situation or project size. Let’s explore these three patterns using **Manufacturer** as the main example, then discuss when to use each pattern for other relationship types.

### Pattern 1: Organize relationship with taxonomies

We recommend using [taxonomies](https://docs.kentico.com/documentation/developers-and-admins/configuration/taxonomies.md) to organize and categorize content, including products. _Taxonomies_ are hierarchical structures for classification and filtering. Each tag includes a title and description, and you can quickly introduce _manufacturers_ or other entities to be a _subgroup_ within a taxonomy. For example, the _ProductCategory_ taxonomy can look like the following:

```markdown title="Taxonomy tags in Products category"
Products
├── Manufacturers
│   ├── Manufacturer A
│   ├── Manufacturer B
│   └── Manufacturer C
├── Dogs
│   ├── Food
│   │   ├── Dry Food
│   │   ├── Wet Food
│   │   └── Treats
│   ├── Toys
│   └── Accessories
├── Cats
│   ├── Food
│   ├── Toys
│   └── Litter
└── Fish
    ├── Food
    └── Aquarium Supplies
```

Define the taxonomy field on the Product content type as follows:

_ProductCategories_ (Taxonomy)

- Data type: Taxonomy
- Allowed taxonomies: Product Categories
- Guidance: "Select one or more categories to help customers find products via navigation and filters."

Use taxonomy _tags_ for manufacturers when:

- You need hierarchical classification (categories with subcategories).
- The primary goal is filtering, navigation, and organization.
- The entity reqiures minimal attributes beyond name and hierarchy.
- Editors need to manage terms separately from content.
- Multiple items share the same term.
- The hierarchy structure is relatively stable.

### Pattern 2: Manufacturer as a reusable field schema (RFS)

This pattern embeds manufacturer information directly in the _Product_ content type using a [reusable field schema](https://docs.kentico.com/documentation/developers-and-admins/development/content-types/reusable-field-schemas.md). There are no separate _Manufacturer_ content items. _Manufacturer data_ is stored as fields on each product, with no separate content items.

**ManufacturerFields** RFS can contain the following fields:

- _ManufacturerName_ (Text) - _Text input_ component
- _ManufacturerCountry_ (Text) - _Text input_ or a customized dropdown selector
- ManufacturerFieldsWebsite (Text) - Text input with custom URL [validation](https://docs.kentico.com/documentation/developers-and-admins/customization/extend-the-administration-interface/ui-form-components/ui-form-component-validation-rules.md)
- _ManufacturerAddress_ (Pages and reusable content) - _Combined content selector_ scoped to relevant content types

The _Product_ content type would include this ManufacturerFields schema, and editors would fill in manufacturer information directly when creating each product.

**Trade-offs of the RFS approach**

| Advantages:                                                                                                                                                                                                   | Disadvantages:                                                                                                                                                                                                                                                                                                                                                                                                         |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Simpler initial setup – Developers don't need to manage a separate content type.<br>Faster product creation – Editors enter manufacturer info directly into product.<br>No dependency on other content items. | Data duplication – Same manufacturer data repeats across products.<br>Inconsistency risk, as editors can use slightly different names, e.g., _Kentico_ vs _Kentico Software_.<br>No reusability – Updating the manufacturer's information requires editing every product.<br>Higher difficulty to implement manufacturer-based filters.<br>Requires complex querying to create manufacturer-specific pages or queries. |

**When to use RFS for relationships**

Using the RFS pattern for related content when:

- The information is simple, such as a name or a few attributes.
- The entity is associated with only a few products (1–3 products).
- The entity is unlikely to be reused or referenced outside this context.
- You don't need to create pages or experiences for the related entity.
- The information is specific to this product context.

For the _Pawsome Pets_ scenarios, we chose not to use RFS to define manufacturers.

### Pattern 3: Manufacturer as dedicated content type

This pattern treats _Manufacturer_ as a separate content type in the _Content hub_, and _Products_ reference _manufacturers_ via _Combined content selector_. We recommend this approach when manufacturers are reused across many products or require additional data.

Your _Manufacturer_ content type can contain the following fields:

- _ManufacturerName_ (Text) - Text input component
- _ManufacturerLogo_ (Pages and reusable content) - Combined content selector scoped to appropriate content types
- _ManufacturerCountry_ (Text) - Text input or a customized dropdown selector
- _ManufacturerFieldsWebsite_ (Text) - Text input with custom URL [validation](https://docs.kentico.com/documentation/developers-and-admins/customization/extend-the-administration-interface/ui-form-components/ui-form-component-validation-rules.md)
- _ManufacturerAddress_ (Pages and reusable content) - Combined content selector scoped to appropriate content types
- _ManufacturerWarrantyPolicy_ (Text) - Rich text editor component to describe the manufacturer's standard warranty coverage and terms.

On the _Product_ content type, use _ProductManufacturer_ that stores _Pages and content items_ data scoped to _Manufacturer_ content type, allowing editors to select only one item.

> **Tip:** If addresses are common in your commerce model (e.g., store, distributor, or warehouse addresses), create a dedicated _Address_ RFS or content type. This avoids duplicating address fields across multiple content types.
>
> An _Address_ data type (represented by an RFS or content type) ensures consistent structure (street, city, state/province, postal code, country) across all use cases and makes it easier to generate address-based listings, implement geographic filtering, or integrate with shipping carrier APIs that expect standardized address formats.

#### Benefits of modeling manufacturer data in a dedicated content type

- Enhances _content reusability_ by allowing editors to create manufacturers once and reference across multiple products. When a manufacturer updates their logo or warranty policy, you update a single content item, and the change is reflected across all associated products.
- Manufacturers as content items enable _dedicated manufacturer pages_ showcasing product catalogs, brand stories, and contact details.
- Developers can query and filter products using manufacturer-based facets.
- Editors select existing manufacturers, avoiding typos and ensuring consistency.

#### When to use referenced content to store data

Use dedicated content to store data when:

- The related entity is associated with many products (typically 5+ products).
- Editors want to display substantial entity information beyond a simple name and description.
- The team wants to create dedicated pages or experiences for the related entity.
- The related entity's information changes independently of products.
- Different editors manage various aspects (for example, one team manages _manufacturers_, another _products_).

#### Composing multiple relationships

Products often involve multiple relationship types. Use the [Content modeling MCP server](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-mcp.md) to generate the relationship diagram to see links between content types, taxonomies, and other entities for better visibility.

![Diagram of content type relationships](https://docs.kentico.com/docsassets/modules/compose-related-content-to-product-skus/content_type_relationships_mermaid_diagram.png "Diagram of content type relationships")

If we wanted to expand the _Pawsome Pets_, a single dog food product can have:

- _Manufacturer_ (referenced content): (Manufacturer)
- _Categories_ (taxonomy): Dogs > Food > Dry Food
- _Related products_ (referenced content): Other (brand) dog foods, complementary treats
- _Care guide_ (referenced content): _Complete Nutrition Guide for Adult Dogs_

This composition gives editors powerful tools for creating rich product experiences while maintaining clean data architecture.

#### Make the right choice for your project

When you consider how to model relationships in your commerce implementation, ask:

- How many times is this entity reused? More reuse → _Content type_
- Does it need its own pages or experiences? Yes → _Content type_
- Is it mainly for filtering/organization? Yes → _Taxonomy_
- Is the entity's information complex? Yes, complex → _Content type_; No, simple → _Taxonomy_ or _RFS_
- Does it change independently of products? Yes → _Content type_
- Do you need to query products by this entity? Yes → _Content type_ or _Taxonomy_