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 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:

MD

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

Simpler initial setup – Developers don’t need to manage a separate content type.
Faster product creation – Editors enter manufacturer info directly into product.
No dependency on other content items.

Data duplication – Same manufacturer data repeats across products.
Inconsistency risk, as editors can use slightly different names, e.g., Kentico vs Kentico Software.
No reusability – Updating the manufacturer’s information requires editing every product.
Higher difficulty to implement manufacturer-based filters.
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
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.

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 to generate the relationship diagram to see links between content types, taxonomies, and other entities for better visibility.

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