Model a reusable Product SKU

Modeling commerce products in Xperience by Kentico requires careful planning. As an architect, you need to balance flexibility with structure, reusability with specificity, and editorial simplicity with technical needs.

The way you structure products impacts how easily editors can manage them, whether for a simple catalog or a complex multi-channel experience.

This material focuses on modeling product SKUs in Xperience by Kentico (XbyK) specifically for commerce flows. It helps you build a Product SKU content type that aligns with business goals and is simple to maintain and scale.

After completing this material, you’ll be able to:

• Decide whether to store products in Content hub or a website channel, and understand the organizational implications of each approach.
• Design a flexible Product SKU content type using reusable field schemas and dedicated content type fields.
• Define Product SKU identifiers as reusable components that work across different product types and content items.
• Compose related content such as manufacturers, product categories, and taxonomies to support the project’s business needs.
• Choose from three different approaches to modeling product variants, understanding the trade-offs of each.

Prerequisites

o get the most out of this material, you need to understand your organization’s commerce requirements, product catalog structure, and channel strategy. You should have basic knowledge of content modeling principles. Understanding how reusable field schemas work is also beneficial.

Who should read this guide

This material is intended for solution architects and content modeling experts. It focuses on designing the content model for commerce implementations in Xperience by Kentico. While the guide includes technical considerations, it focuses on modeling decisions rather than implementation details. Developers looking for code-specific guidance can find examples in documentation, namely how to model a product catalog.

Understand commerce requirements before creating your content model

Before defining content types and fields in Xperience, ensure you understand your project’s requirements. You may need to do a content audit and business analysis to gather the exact details you’ll use for your content model.

Begin by looking at your current product data. What information do you already store? How is the product content organized? What challenges do editors face when they work with product data?

Identify the business scenarios your product catalog must support. These may include catalog listing pages, detailed product pages, cross-channel commerce experiences, mobile apps, or headless storefronts that deliver product data via APIs.

List organizational needs, including product hierarchies, multi-brand catalogs, and international requirements like multi-currency pricing or region-specific availability.

Refer to Schema.org’s Product schema for guidance on structuring your product data in ways that search engines and third-party integrations can understand.

While you don’t have to include every Schema.org property in your content types, understanding the standard helps you prioritize the fields most relevant to your business. This increases the chance that search engines display rich results, such as prices, availability, ratings, and images, directly in search listings. Many third‑party integrations, including marketplaces, comparison engines, and product feeds, expect product data in a predictable format. This format is often based on Product schema and includes fields like description, image, brand, and SKU, along with additional properties for reviews and ratings.

Validate your product content model against standards before you finalize it. This helps make sure you’ve included all the needed properties and configured them up correctly.

The use case: Pawsome Pets product catalog

We’ll use Pawsome Pets, a fictional pet store selling live animals and accessories, as our example. This will help show the modeling decisions and patterns in each section.

Also, a similar Product SKU model will be featured in the upcoming commerce training materials for developers. Stay tuned and follow documentation updates to find out when we release the materials.

Pawsome Pets’ requirements

• Sell multiple product categories: live pets, for example, dogs, cats, birds, fish, pet food, toys, accessories, and grooming supplies.
• Display products on their main commerce website (modeling website pages and widgets will be covered in other guides).
• Display product information to mobile apps and marketplace channels.
• Support product variants, such as sizes, colors, flavors.
• Show manufacturer information and warranty details.
• Manage stock across multiple store locations.
• Handle multilingual content as they are expanding into international markets.
• Ship specific products to multiple countries.

This example highlights common scenarios you may face when modeling products in Xperience. You can apply these patterns and decisions used for Pawsome Pets to various industries, including pet supplies, equipment, fashion, and manufactured products.

Pawsome Pet’s product requirements

Before creating all the required fields in Xperience, take time to understand what information your products need to capture. Pawsome Pets, we’ve identified these core requirements through discussions with stakeholders:

From the merchandising team:

• Provide a clear name and SKU for identification.
• Include short descriptions for listing pages and emails.
• Add long descriptions for detail pages.
• Upload multiple product images (primary image plus gallery).
• Specify price information.
• Tag products with taxonomy tags for filtering and search.

From the marketing team:

• Highlight promotional messaging and special offers.
• Recommend products and cross-sells.
• Indicate product availability status.

From the SEO team:

• Structured data markup for search engines (SEO) and social networks (Open Graph).
• Product metadata that works across channels.

From the development team:

• Add structured data markup for search engines (SEO) and social networks (Open Graph).
• Provide product metadata that works across channels.

Prototype the content model with Content modeling MCP server

Before we dive into the details of modeling Product SKUs, let’s start by prototyping the content type using Xperience’s Content modeling MCP server.

The MCP server provides an end-to-end guided process for gathering content type requirements, designing widgets, and creating the foundation of our Product SKU content type. We’ll refine this foundation to meet the specific needs of Pawsome Pets.

Gather project requirements

The process begins by gathering project requirements through a series of steps. Information like your industry, target markets, marketing channels, and editor experience helps the agent suggest a content model that fits your needs.

Additional details, such as the number of websites, channels, content volume, and reuse strategy, help the MCP agent design an appropriate content model.

After collecting all the details, the server summarizes the results and proceeds to the next phase.

Design content types

The MCP server uses your input and Kentico’s best practices to create content types tailored to your business and website. These include reusable content for pets, accessories, articles, FAQs, and customer testimonials. The server also suggests webpage content types, such as HomePage, PetDetailPage, anc PetListingPage to display product data.

Use your agent to analyze the prototypes

For this material, let’s look at how the Content modeling MCP server created prototypes for the Pet and Product content types.

Both content types use CoreContentSchema built with reusable field schema feature. This schema includes a title, summary, thumbnail image and category.

Unlike the ProductSKU content type, which covers all accessories Pawsome Pets sells, the Pet content type represents animals. It doesn’t include a Stock Keeping Unit.

To view the relationships between suggested content types, ask the LLM agent to summarize them in a Mermaid-style graph. This graph shows the structure of the main and supporting content types.

The diagram illustrates relationships between nine content types, including Pet, Product, ImageAsset, VideoAsset, Feature, Article, Author, Testimonial, and FAQ.

In the commerce context, both the Pet and the Product content types relate to Image asset, Video asset, and Testimonial content types. Additionally, the MPC server suggested that the Product content type relates to Feature, other related products for cross-selling, and article content type for content marketing.

You can see how these nine content types (Pet, Product, ImageAsset, VideoAsset, Feature, Article, Author, Testimonial, and FAQ) are related. Both Pet and Product content types connect to ImageAsset, VideoAsset, and Testimonial types. The MCP server also suggests that the Product content type relates to the Feature (for additional details), other related products (for cross-selling related products), and the Article type (for content marketing).

This material uses Product with SKU identification (ProductSKU) as an example to demonstrate solutions for common commerce modeling challenges.

In real projects like Pawsome Pets, you might need separate content types for different categories, such as Pet, DogFood, and DogCollar. This approach simplifies editing and tailors content types to specific data needs. We focus on universal patterns you can adapt to your catalog, rather than prescribing one “ideal” product model.

Select your product storage strategy

The most critical decision in modeling commerce products is where to store them: in the Content hub as reusable content or as pages in a website channel. This decision impacts how editors manage products and how your content scales across channels.

The Content modeling MCP server selected the content modeling approach based on the provided details, but it’s worth reviewing the pros and cons of each approach.

Atomic content model approach: Products as reusable content

Storing commerce-specific content in the* Content hub* is the recommended approach for modeling commerce solutions in Xperience. This approach ensures commerce content items are reusable and independent of any specific channels or presentation contexts. Editors create products once and then reference them across multiple channels, such as websites, mobile apps, email campaigns, or third-party marketplaces, using dedicated wrappers.

This approach treats products as pure data that editors can use to create different experiences. For example, a dog food product exists as structured data that a website, mobile app, and any other programs that consume your APIs can access and display as needed.

Page-based content model approach: Products as pages

In this model, products are treated as webpage content types within a specific website channel. Each product has its own URL and is part of the website’s content tree. Editors manage products directly within the website where they are displayed. Editors can reuse data stored in a content type’s structured fields across the website or email channels, while data stored with widgets is closely tied to the presentation layer.

This approach prioritizes a web-first mindset and focuse on product presentation within the website. For example, a dog food product page includes a URL and SEO settings. The product data (both structured and unstructured) is displayed through a static view and Page Builder components that editors arrange to create the optimal product detail page.

When to use each approach

For Pawsome Pets, we’ll use the Content hub approach because:

• The team plans to syndicate product data to mobile apps, marketplace channels and other platforms.
• Product data needs to be accessible via API for third-party integrations.
• Centralized product management supports their expanding channel strategy.
• Content reuse ensures efficient scaling as the business grows.

Review the core product data modeled by the MCP server

With Pawsome Pets products stored in the Content hub, the next step is designing the core Product SKU content type. This inovolves identifying the fields required for every product, regardless of category or type. These fields are then organized using reusable field schema to prevent duplication and optimize data queries.

Define the CoreContent reusable field schema

These fields align with those required for Article, so we’ll define a CoreContent reusable field schema (RFS). This schema contains the core information and is reusable across different content types if needed.

Here’s the structure of our CoreContent schema:

• CoreContentTitle:
  • Field caption: Title
  • Data type: Text
  • Form component: Text input
  • Maximum length: 200 characters
  • Text below the input: “Enter a clear and descriptive item name for customers.”
• CoreContentShortDescription
  • Data type: Text
  • Field caption: Short description
  • Form component: Text area
  • Maximum length: 500 characters
  • Text below the input: “Provide a brief summary for listings and search results. Focus on key benefits.”
• CoreContentThumbnailImage
  • Data type: Pages and reusable content
  • Field caption: Core taxonomy
  • UI component: Combined content selector
  • Allowed content types: Asset (Image)
  • Maximum items: 1
  • Text below the input: “Choose the main image for listings and search results.”
• CoreContentTaxonomyTags
  • Data type: Taxonomy
  • Form component: Tag selector
  • Allowed tags: Core taxonomy
  • Text below the input: “Choose tags to help customers filter and search for this item.”

Follow recommended field naming conventions

Notice that all fields in the CoreContent schema start with “CoreContent” prefix. This naming convention serves several important purposes in XbyK:

• Prevents database column name conflicts by ensuring each field name is unique. Xperience stores content type data in SQL database tables. When you add a reusable field schema to a content type, the schema’s fields become columns in ContentItemCommonData database table. If you add multiple schemas to the same content type and they have fields with identical names (like Name, Title, or Description), you’ll encounter naming conflicts. By prefixing fields with the schema name, you ensure uniqueness. Even if multiple schemas require a Title field, it becomes CoreContentTitle, ManufacturerTitle, or CategoryTitle.
• Improves code readability and maintainability by incidating the schema to which the field belongs. When developers query content items and access field values in code, the prefix makes it immediately clear which schema a field belongs to. This clarity is especially valuable in large projects with many content types and schemas.
• Appears consistently in queries and APIs. Whether developers retrieve content through the Content Query or Content Retriever API, Xperience GraphQL, or custom REST endpoints, the prefixed field names are consistent, making it easier to understand data structure across different contexts.

Reusable field schemas help editors in the admin UI

When editors create a product using a content type that includes the CoreContent schema, they’ll see these fields grouped together in the editing form. Xperience displays the schema name as a header of a collapsible section. This helps editors understand which fields belong together conceptually.

This image illustrates how reusable field schemas work together with dedicated product fields within the Product SKU model. Core fields, such as title, pricing, and product attributes, are defined as reusable schemas to ensure consistency across different product content types. SKU-specific fields store unique product data. We’ll dive into how this composition approach keeps your product data structured, maintainable, and easy to reuse.

Separate core content data from product-specific fields

Though products are, from information-architecture perspective, semantically independent entities, other content types (and independent entities or things, such as Article, Person , or Organization ) share the same data fields, including name, description, category or representing image.

In many commerce implementations, separating product-specific data from general content into a dedicated schema can be beneficial. This schema can be included in all relevant content types.

Your Product content type will then share this schema fields with other content types. This approach simplifies queries for developers, particularly in marketing-heavy stores. Campaigns, seasonal content, and editorial features can reference products without requiring product-specific data.

For example, editors can use the same Card widget to display core product data in a Summer Pet Care Guide campaign page, or alongside with core data from a Top 10 Dog Toys article.

Separating product data (e.g., SKU, price, inventory, and specifications) from repurposable marketing content creates a cleaner data structure. This simplifies queries for developers and presentation components for editors.

Model SKU details as a reusable field schema

The Content modeling MCP server initially generated a simple SKU field directly on the Product content type. This works for basic scenarios, but as commerce implementations grow, you’ll often need more sophisticated SKU management across multiple product types.

Besides SKU identification, products often also require additional identifiers for inventory management, barcode scanning, manufacturer part numbers, or integration with external systems. To avoid duplication and inconsistency, you can create a dedicated ProductSKU reusable field schema. This schema will include fields ProductSKUCode, ProductSKUBarcodeEAN, ProductSKUBarcodeUPC, ProductSKUMPN, ProductSKUExternalId, and other project-specific fields.

When a simple SKU field is enough

Not every implementation needs the full ProductSKU schema. For simple catalogs with no integration requirements, a single SKU field may suffice.

When ProductSKU should be a reusable schema

The CoreContentSchema defined above supports all content, including non-product content types, such as articles, featured content, or press releases.

A dedicated ProductSKU RFS offers several advantages:

• Cross-type consistency. Whether you’re working with a dog collar (Product) or a fish (Pet), SKU-related data is captured and structured identically. This consistency makes queries, integrations, and reporting significantly easier.
• Centralized evolution. When you need to add new identifier types, such as GTIN for Google Shopping or ISBN for pet care books, you update the ProductSKU schema once, and all content types using it automatically gain the new field.
• Integration readiness. External systems (for example, inventory management, POS, or marketplaces) expect standardized product identifiers. A reusable schema ensures your content model speaks the same language as these systems.
• Integration signal. Use the SKU schema to signal to integrations. Developers can build mechanism that determines when event handlers or scheduled tasks should propagate product updates to inventory, pricing, or other external systems.

If you answer “yes” to any of these questions, consider using the ProductSKU schema approach:

• Do multiple product types require SKU identification?
• Will you integrate with inventory, ERP, or marketplace systems?
• Do you need barcode scanning capabilities?
• Do you sell products from multiple manufacturers with unique part numbers?
• Might you need additional identifier types in the future?

For Pawsome Pets, we chose a simple ProductSKU field on the Product content type for simplicity.

When finalizing your project’s Product fields, aim to balance simplicity with scalability. Starting too simple, you may face technical debt later. Overengineer early can slow your team. Aim for a solution that fits your current needs and allows for future growth.

Consider the above questions before defaulting to an overly simple commerce content type model.

When to use reusable field schema vs. direct content type fields

You might wonder when to use a reusable field schema versus adding fields directly to a content type. Here’s the general guidance:

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:

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

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.

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.

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

Model product variants

Modeling product variants is a key challenge in Xperience commerce content. Product variants are items that share core product attributes but differ in specific characteristics like size, color, flavor, or material.

A single product, such as a Premium Dog Collar might be available in multiple sizes and colors, creating dozens of purchasable SKUs. Contrary to Kentico Xperience 13, which handles product variants in a dedicated feature, you need to model the product variants in Xperience from scratch.

For Pawsome Pets, product variants are essential:

• Dog collars come in multiple sizes (Small, Medium, Large, X-Large) and colors (Red, Blue, Black, Pink).
• Cat food is available in different flavors (Chicken, Salmon, Tuna) and package sizes (3lb, 7lb, 15lb).
• Bird toys come in sizes appropriate for different bird species.
• Fish tanks are sold in various capacities (10-gallon, 20-gallon, 55-gallon).

How you model variants affects everything, from editor workflows to inventory management and the checkout process. The content modeling agent MCP lacked enough information when designing the model, so we need to address this now.

Xperience by Kentico supports multiple approaches, each with distinct trade-offs.

Understand approaches to modeling product variants

There are three primary approaches to modeling product variants in Xperience:

• Approach 1: Variants in as dedicted content items - Manage product option combinations as separate SKUs with price adjustments. They can exist as reusable items in Content hub or as website pages. (The latter approach is most similar to historical Kentico Xperience <13 implementations.)
• Approach 2: Variants via reusable field schemas - Represent variant attributes as reusable field schemas.

Let’s explore each approach to help you select the right pattern for your implementation.

Approach 1: Variants as dedicated content items

The recommended approach is to treat product variants as “child items” of the parent product. The parent stores shared information, while variants hold unique fields, such as size, color, or other distinguishing attributes, along with variant-specific data like SKU or stock levels.

This parent-child pattern works for both Content hub (reusable content in atomic content model ) and a website channel (page-based content model) with slight implementation differences.

The parent-child content model structure

The key principle is to avoid duplication. Shared details like material, brand, and description reside in the parent product. A variant object stores only size-specific details.

To simplify querying, you can use reusable field schemas for variant fields that repeat across content items. For example, you can use the same size description, such as small, medium, large, for products of different types.

Define ProductSize fields to simplify product data structure, such as:

ProductSize (reusable field schema): - ProductSizeValue (Text or Dropdown): The specific size (S, M, L, XL) - ProductSizeDimensions (Text or Dropdown/Taxonomy): Measurements for this size, dropdown in case of standardized sizes - ProductSizeDescription (Text): Additional explanation

The parent Product content type includes the following fields:

• ProductFields (reusable field schema): Name, descriptions, primary image, gallery, base price, tags
• ProductMaterial (Taxonomy, Text, or Dropdown): Cotton, Polyester, Blend, etc.
• ProductColor (Taxonomy, Text or Dropdown): Color of the shirt
• ProductBrand (Taxonomy or Content items): Reference to Manufacturer
• ProductCareInstructions (Rich text): Washing and care guidance
• ProductVariants (Content items): Combined content selector restricted to ShirtSizeVariant type

Note that the Product content type excludes the SKU fields, ProductStock (stock should be handled through dedicated custom module), and size, as these belong to the variant.

Variant product content type: ProductSizeVariant

This content type contains only variant-specific information:

• ProductSKU (RFS): SKUCode, barcodes, external IDs
• ProductStock (custom module reference or RFS): For example, Available, Reserved, Threshold quantities, ProductVariantDimensions (RFS or Text input): Size value and dimensions
• ProductVariantPriceAdjustment (Decimal, optional): Price modifier if XL costs more (+$2.00)
• ProductVariantImage (Content items, optional): Size-specific product image if needed

Note that the variant does not include:

• ProductFields schema (composed, inherited from parent)
• Material, color, care instructions (all on the parent)
• Brand or manufacturer (on the parent)

Implement product variants in the Content hub

n the Content hub, variants and parent products are stored as reusable content itemsin a flat content list. The Product Variant field in the parent Product establishes the relationship. In a flat structure, editors should use strict naming conventions (e.g., [ParentProductName - Distinguishing Attribute]) to simplify curation.

Content structure in Content hub:

Content Hub:
├── Premium Dog Collar (Parent in Content hub)
├── Premium Dog Collar - Small - Red (variant)
├── Premium Dog Collar - Small - Blue (variant)
├── Premium Dog Collar - Medium - Black (variant)
└── (etc.)

Editor workflow for creating products

Editors create a parent product, such as Premium Dog Collar, and provide shared information. Next, they create product variants, such as Premium Dog Collar - Small - Red, etc.

If they create the variant separately (away from the Product), the need to return to the parent product. They then select all variants in the ProductVariant field using the Combined content selector to establish the relationships. Creating variants directly from the parent via the Create new in the Combined content selector button establishes the relationship automatically. Simplify navigation by grouping products and variants in dedicated Content hub folders.

Implementing variants in the content tree structure

If you have decided to build a page-based content model for the website, you can store product variants in the content tree. A tree structure naturally represents the parent-child relationship between products and variants.

Variants live under their parent product in the tree hierarchy.

Website Channel
└── Products
    └── Dogs
        └── Collars
            ├── Premium Dog Collar (Parent)
            ├── Premium Dog Collar - Small - Red (variant)
            ├── Premium Dog Collar - Small - Blue (variant)
            ├── Premium Dog Collar - Medium - Black (variant)
            └── (etc.)

Depending on your project requirements, you can ensure consistency of your data by disabling routing for the ProductSizeVariant content type to prevent variants from being navigable through their own URLs.

Without routing, variants are automatically excluded from sitemaps, meaning editors don’t need to manually disable each and every one of them. Editors can manage variants in the admin interface, but these variants rely on the parent product page for live site access and do not have individual URLs.

Benefits of the parent-child pattern

• Shared information exists once. Update the shirt’s material on the parent, and it applies to all variants automatically.
• The relationship between parent and variants is explicit and easy to understand.
• Developers can retrieve a single parent product and its variants, rather than running separate queries for each size.
• Editors understand they’re creating variants of an existing product, not entirely new products.

Considerations and limitations of parent-child variants

• Editor workflow can be daunting as editors must create the parent, then add child items for variants, and then ensure they are linked together. This requires more steps than single-item creation but ensures proper structure. Consider implementing a mechanism to import products from an ERP system using API.
• Editors need to consistently name variants, especially when creating them in the Content hub, to ensure efficient management and organization of variant content.
• With the base price stored on the parent product and only adjustments defined on variants, it becomes harder for editors to clearly see, for example, that an XL collar costs $2 more without duplicating the entire product in the Content hub.
• Managing variants becomes increasingly complex if you have multiple varying attributes (size & color & material). For instance, if a product has 5 sizes, 8 colors, and 3 materials, resulting in 120 combinations, evaluate whether all combinations require individual content items. In such cases, you might find the following reusable-field schema-based approach more suitable.

When to use this parent-child pattern

This parent-child pattern for creating product variants works best when:

• You have moderate variant counts per product (typically 2-20 variants).
• Variants differ in only one or two attributes (size, color).
• You want clear, visible variant management in the admin UI.
• Your implementation is website-first (though it works for Content hub, too).
• Editors prefer creating explicit content items for variants.
• You need simple stock tracking per variant.

Approach 2: Dynamic variants via reusable field schemas

You can define variant attributes (Size, Color, Flavor, etc.) as reusable field schemas on the Product content type. Instead of creating a separate content type to store each product variant combination, you store the available options in product-specific fields. Then, you have two options: either create a dedicated content item per variant and allow editors access in the UI, or let the application logic materialize the specific variants. In this approach, developers are responsible for creating the querying logic to dynamically display specific variants based on the defined attributes. If they decide not to provide access to editors in the UI to variant content items, they need to ensure the variant data is properly represented in the product inventory. (The product inventory relies on variants existing as dedicated content items, using the ContentItemId fields to maintain relationship between the variant and its stock. If you decide to build variants dynamically, your developers will need to customize the recommended approach and store the reference between the variant and its in-stock represenation differently.)

To implement this approach, you can create two RFS to define size and color options for products.

ProductSizeOptions RFS:

• ProductSizeAvailableSizes (Multiple choice): Small, Medium, Large, X-Large
• ProductSizeDimensions (Text or Dropdown/Taxonomy): Measurements for this size, dropdown in case of standardized sizes
• ProductSizeDescription (Text): Additional explanation

ProductColorOptions RFS:

• ProductColorAvailableColors (Multiple choice): Red, Blue, Black, Pink, Green
• ProductColorHexCodes (Text): Color values for display (RGB, HEX or other convenient format)

Your custom application code or helper methods generate purchasable variants dynamically, including SKU identifiers. For example, a dog collar with size and color variants can combine taxonomy tags for size and color to produce SKUs.

Dogs
└── Collars
        ├── Premium Dog Collar - Small - Red (SKU: PDC-SM-RED)
        ├── Premium Dog Collar - Small - Blue (SKU: PDC-SM-BLU)
        ├── Premium Dog Collar - Medium - Red (SKU: PDC-MD-RED)
        ├── Premium Dog Collar - Medium - Blue (SKU: PDC-MD-BLU)
        ├── (etc.)

Benefits of the RFS approach

• Ideal for API-driven commerce channels where clients build their own variant selectors on the storefront.
• Variant data is pure structured content, making it reusable across any channel, such as websites, mobile apps, or third-party platforms.
• This approach eliminates the need to create hundreds of content items for every variant combination. Variant options are stored only in the parent, and developers generate combinations as needed.
• Improved variant management where editors can simply change available variant configuration in one place, for example, color, and affect all applicable variants.

Trade-offs of RFS

• More complex implementation requires developers to build variant materialization logic.
• Editors don’t see individual variants as separate content items in the admin UI.
• Stock tracking require a custom implementation that ensures SKU codes are generated into inventory.
• Variants don’t have dedicated pages or URLs (unless you customize how XbyK generates web page routes).

When to use this approach

• You’re building an API-first commerce experience.
• You need to display products across multiple channels, but don’t need their representation in the admin UI.
• You have products with many variant combinations (10+ variants per product).
• Your developers can build variant materialization logic.
• Flexible cross-channel reuse is more important than individual variant pages on the storefront.

Modeling price options for variants

One of the most common challenges in product variant modeling is handling pricing. While some products cost the same across all variants (a dog collar might be $15.99 in any color), many products have variant-specific pricing. Understanding how to model price variations is crucial for your content structure.

Let’s explore different pricing scenarios and how to model them in Xperience by Kentico.

Pricing options 1: Price Adjustments (price-modifier pattern)

In this pattern, the parent product has a base price, and variants store price adjustments that are added to the base price.

Example: Premium Dog Collar

• Base price (parent): $15.99
• Small, Medium: No adjustment ($15.99)
• Large: +$3.00 ($18.99)
• X-Large: +$5.00 ($20.99)

To implement the price-modifier pattern, create a dedicated field on the parent Product content type:

• ProductPrice (Decimal): 15.99 (base price)

On the ProductSizeVariant content type, define an adjustment field, provide editors a dropdown selector or a decimal input field:

• ProductSizeVariantPriceAdjustment (Decimal): 0.00, 0.00, 3.00, 5.00

Developers need to implement logic that dynamically calculates the final price by adding the base price and the adjustment. For example, a large collar costs $15.99 + $3.00 = $18.99.

Benefits of price-modifier pattern

• Data entry is straightforward: “Large costs $3 more than base price”.
• Simplifies pricing updates; editors can change the base price once, and adjustments remain valid.
• Editors see price differences relative to the base, making the prices clear to understand.
• Highlights the relationship between variants and the parent product.

When to use price modifier pattern

• Most variants in your store have the same price, with occasional exceptions.
• Price differences are predictable and consistent (larger sizes cost more).
• You want to emphasize that variants are closely related.
• Your pricing logic is straightforward and doesn’t require per-variant adjustments.

Pricing options 2: Independent variant pricing

In this pattern, each variant has its own complete price. The parent product may or may not store a price.

Example: Premium Dog Food

Parent: No price stored (or “starting at $12.99” for display purposes)

• Small (3lb): $12.99
• Medium (7lb): $24.99
• Large (15lb): $44.99
• X-Large (30lb): $79.99

Note that prices don’t increase uniformly due to volume discounting. The 30lb bag doesn’t cost 10 times what the 3lb bag costs because bulk sizes are discounted.

How to model independent variant pricing

You can omit the price field on the parent Product content type, or include an optional starting price field for display purposes, e.g., in product listings on storefront.

DTo support independent pricing, define the following fields on the ProductSizeVariant content type:

• DogFoodVariantPrice (Decimal, required): The exact price for this variant
• ProductSizeFieldsValue (Text): 3lb, 7lb, 15lb, 30lb

Benefits of independent variant pricing

• Each variant item stores its own price, which offers complete pricing flexibility.
• Simplifies data entry by making it clear: “This variant costs exactly $24.99”.
• Allows stores to cover complex pricing models, including volume discounts, promotional pricing, or market-specific pricing.
• Developers don’t need to prepare price calculation logic, as prices are directly stored in the product variant items..

Trade-offs of independent variant pricing

• Updating prices can be time-consuming, as each variant must be updated individually.
• Editors don’t see at a glance in the Content hub/content tree that larger sizes have volume discounts.

When to use this pattern

• Your prices don’t follow a predictable pattern.
• You have volume discounting or bulk pricing.
• Different variants have fundamentally different costs.
• You need market-specific or promotional pricing per variant.
• You want complete pricing control without constraints.

Other approaches to modeling pricing

We have covered the two most common patterns for modeling prices, but the reality of digital commerce is much more complex. Understanding the project requirements and the business model will also determine whether you need to model price variations.

You might want to introduce complex pricing calculations based on customer type, geographical location, or order values. Your project might require independent variant pricing for products with volume discounts. Alternatively, you may need price list references for B2B customer-specific pricing.

Xperience by Kentico includes built-in catalog discount and order discount features that handle common pricing scenarios like percentage discounts, fixed amount reductions, and promotional campaigns. These features work well for straightforward pricing needs and integrate directly with the commerce functionality. For many implementations, these built-in capabilities provide everything you need without custom development.

However, complex commerce implementations often require sophisticated pricing models beyond these standard discounts. You might need price adjustments where larger sizes cost incrementally more.

Your project might require independent variant pricing for products with volume discounts or price list references for B2B customer-specific pricing. You might need to introduce complex tiered pricing for product- or product-combination-specific quantity breaks, or promotional pricing with time-based sales.

In these cases, you can model pricing fields directly in your content types to support your specific business logic. This enables editors to tailor prices and gives developers the structured data they need to implement complex pricing (and price calculation) rules. It works well when pricing logic is primarily managed within XbyK and follows patterns that are relatively stable and transparent to content editors.

Alternatively, pricing can be managed through external integrations. XbyK can send product ID, quantity, channel, or customer group data to a third-party system for price calculation. This approach is useful when you manage pricing by systems like an ERP or when rules, such as dynamic discounts, contracts, or regional pricing are too complex to model directly in content. In this setup, XbyK provides the product data and context, while the external service returns the calculated price for display or further processing.

Modeling shipping data fields

Shipping-related data is essential for calculating costs, determining delivery options, and ensuring compliance with carrier requirements.

Where you store this data depends on whether shipping attributes are the same across all variants or differ per variant.

Shipping data on Product vs. Product Variant content types

• Store shipping data in the parent Product content type when all variants share the same shipping characteristics, for example, all sizes of a dog collar ship in the same box type.
• Store shipping data in variants when shipping characteristics differ between variants. For example, a small dog crate ships in a compact box, but an X-Large crate requires freight shipping.

Common shipping fields

Depending on your product catalog and target markets, you can define a ProductShipping RFS with these common fields:

• ProductShippingWeight (Decimal, Taxomomy or Dropdown in case your products are standardized) - Weight in pounds or kilograms.
• ProductShippingDimensions (Text or separate fields) - To store dimensions (length × width × height), as either a single text field (“24 × 18 × 12 inches), or as separate fields (ShippingLength, ShippingWidth, ShippingHeight).
• ProductShippingClass (Dropdown) - Standard, Oversized, Hazardous, Fragile, Refrigerated, Live Animal - To determine available shipping methods.
• ProductShippingOriginLocation (Text or Content Item reference) - Warehouse or fulfillment center code (optional if all products ship from one location).
• ProductShippingHandlingDays (Integer) - Depending on the products your store sells, include processing time before shipment.
• ProductShippingRestrictions (Text area, Taxonomy collection, or Multiple choice) - Geographic restrictions (state, country, international) to include where you can or cannot ship the product.

Integration Considerations

If you are integrating with shipping carriers or e-commerce platforms, consider adding the following optional fields:

• ProductShippingHSCode (Text) - Harmonized System code for international shipping that’s required for customs clearance.
• ProductShippingCountryOfOrigin (Text or Dropdown) - Manufacturing country, often required in customs documentation.
• ProductShippingCarrierRestrictions (Multiple choice) - Store which carriers cannot handle this product.

Keep your content model simple unless business requirements demand complexity. The rule of thumb for shipping data: store it where it naturally belongs - on parent products when consistent across variants, on individual variants when it differs.

Verify your product model with stakeholders

If your content modeling team includes specialist outsiders, you might want to create visual documentation that communicates your design decisions to all stakeholders. Use the content modeling MCP server to generate diagrams that visually represent your content model, making it easier for stakeholders to understand.

Develop content type diagrams that show the structure of your product content type, including fields, data types, and reusable field schemas used. Your team will need to see relationship diagrams that illustrate how products connect to manufacturers, categories, variants, and other related content types. These visual maps help non-technical stakeholders understand the content architecture. Include diagrams that document content creation flow, explaining how editors will use the content model to build product pages, especially in complex scenarios, such as variant selection or multi-step product configuration.

The diagrams serve as essential references and help ensure everyone shares a common understanding of how the product catalog will function.

Collaborate with key teams across your organization to review the product model documentation, gather feedback, and validate that it aligns with business requirements.

• Developers need to verify technical feasibility, understand integration points with e-commerce platforms or inventory systems, and confirm they can build the necessary functionality.
• Commerce managers should validate that the model supports their merchandising strategies, pricing flexibility, and promotional capabilities.
• Marketing teams must ensure the model captures all content they need for campaigns, SEO, and customer engagement across channels.
• SEO/AEO/GEO specialists need to confirm that the required metadata, structured data, and content organization support search visibility and rich snippets.

Early reviews help identify potential issues before development begins and help reduce cost and effort of making changes later.

Validate your content model and data fields

After designing your product content model, validate that it produces correctly structured data that search engines and external systems can understand.

Tools like Google’s Rich Results Test help ensure your product data is correctly structured for optimal search engine display. Schema.org’s validator checks whether your structured data follows the correct format and includes required properties, helping you catch errors before implementation.

Review Schema.org’s JSON examples for products and test your system’s output using the JSON-LD playground to understand how properties combine in real-world scenarios.

Test your product content type with real product data

Once you’ve finalized the content type design and gathered stakeholder approval, have your editors test it with real product data before full-scale implementation.

You can either use the admin UI to define the product-related content types necessary for testing, or you can use the content management API and build the content types in the XbyK database programmatically. The following image shows how a user provides a JSON definition from the contemt modeling server mcp , and the agent uses the Content Type Management API tools to analyze XbyK instance, including existing admin form components and data types, before constructing the new content type in the admin interface.

Ask editors to create sample products using real catalog data instead of placeholder text or simplified examples. Have them build complete product pages in the website channel, including selecting manufacturers, assigning categories, uploading images, and configuring all relevant fields. Have editors test variant-creation workflows by creating products with multiple sizes, colors, or attributes to ensure the process is intuitive and efficient.

The following screenshot of Product SKU in admin UI and shows how editors add products to the system using collapsible reusable field schemas that keep the form organized and easier to navigate. Product taxonomies, such as categories or materials, also stored as reusable field schemas, which simplifies querying and ensures consistent structure across the catalog. Product manufacturer references a separate content type, while product variants are defined via a dedicated content type.

Hands-on testing uncovers workflow issues, such as confusing field labels, missing guidance text, or illogical field ordering that that may not be evident in diagrams or documentation, but slow down data entry.

Use this testing phase to validate that your product content type truly supports all identified business scenarios and doesn’t introduce unexpected friction. Identify workflow pain points where editors get confused, make mistakes, or require excessive clicks to complete simple tasks. Ask developers to verify that reusable schema fields appear correctly in content queries and that relationships between content types work as expected when retrieving data for display.

Address any issues discovered during testing. Refine field configurations, enhance editor guidance, adjust content structures, and even programmatically simplify complex workflows as needed.

Testing with real editors helps prevent costly rework, particularly after the product catalog is populated with hundreds or thousands of products. You can adjust the content model programmatically after the fact, but it creates additional work and costs that could have been easily prevented.

Summary: Design scalable product model

Modeling product SKUs in Xperience by Kentico requires careful planning of how products are stored and structured. The decisions of where to store products, how to model variants, which pricing patterns to implement, and how to organize related content (such as manufacturers and categories) will directly impact editor efficiency and the ability to scale.

Begin by understanding your commerce requirements and consulting standards like Schema.org. Model fields that repeat across different content types using reusable field schemas to prevent duplication. This will help you create a flexible foundation that supports both current needs and future growth. Keep in mind that content modeling is an ongoing process that gets better with testing, validation, and regular feedback.

Xperience’s Content modeling MCP server will help you prototype the content model and define output in machine-readable format. You can use it to create product model diagrams, validate them with key teams including developers, commerce managers, and SEO specialists, then test with real product data before full implementation. Focus on building a solid foundation with the core ProductFields and ProductSKU schemas, rather than striving for perfection initially. Implement variant approach that aligns with your store strategy, and choose pricing patterns that fit your current business model. As your commerce needs evolve, Xperience’s flexible content modeling lets you expand and refine your product structure without requiring a complete rebuild, ensuring your product catalog grows alongside your business.