---
title: Model commerce wrapper pages
---

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

Commerce experiences in Xperience by Kentico often require an architecture that **separates reusable product data from channel-specific presentation**. This material explains how to model **pages** that display product content using the [atomic content model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md). You'll learn how to create scalable, multi-channel architectures that maintain a single source of truth while serving websites and microsites, headless applications, and email marketing activities.

## Understanding wrapper pages in atomic content modeling

A **wrapper page** is a content type that references [reusable content](https://docs.kentico.com/guides/architecture/content-modeling/model-reusable-content.md) from the [Content hub](https://docs.kentico.com/documentation/business-users/content-hub.md) and adds **channel-specific context** like _SEO metadata_, [URLs](https://docs.kentico.com/documentation/business-users/website-content/manage-page-urls.md), and publish dates. This pattern comes from the [atomic content model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md), which separates content into two layers: **reusable core data** that stays consistent across all channels, and **channel-specific context** that varies per website, mobile application, kiosk, or email.

> **Tip:** Editors update product data in the _Content hub_ once, and the changes automatically reflect on every _product page_ and channel that references it.

We recommend using _wrapper pages_ when you:

- Need to support **multi-channel content delivery**.
- Have channel-specific metadata requirements for SEO and social sharing.
- Need to manage URLs and site structure separately from content.
- Require different presentation approaches for the same content across websites, microsites, or different pages.

> **Tip:** If you define a content model for a business that will **display product data only on one website channel**, but plan to expand across other digital channels, such as email, you might consider storing reusable product data as [structured content](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/structured-and-unstructured-content.md). You can then [design widgets and page templates](https://docs.kentico.com/guides/architecture/content-modeling/model-website-presentation-components.md) that editors will use to refer to product data.

For simple, single website-channel projects with no plans for expansion, a [page-based model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-page-based-content-model.md) may be sufficient and simpler to implement.

## The two-layer architecture for commerce content

When you apply the _wrapper page pattern_ to commerce, you split your product content into two distinct layers.

**Layer 1** stores your reusable **Product** content in the [Content hub](https://docs.kentico.com/documentation/business-users/content-hub.md). This is your single source of truth for product data, such as _title_, _description_, _summary_, _features_, _benefits_, _product images_, _specifications_, _taxonomy_, and product _categories_. This data remains consistent regardless of how or where you display the product.

**Layer 2** contains your **Product Page** in the content tree of your website channel. This page references the reusable _Product_ and adds only channel-specific metadata: _SEO fields_ (title, description, canonical URL), _Open Graph tags_ for social sharing, page _URLs_ and routing, _publish dates_ and scheduling, channel-specific _hero banners_ or promotional images, and page-specific content, such as _personalized messages_ or _calls to action_.

![Reusable product and Product wrapper page](https://docs.kentico.com/docsassets/modules/model-commerce-pages-intro/product-wrapper-page.png "Reusable product and Product wrapper page")

> **Info:** **Pattern takeaway:** Keep reusable product data in the _Content hub_ and use wrapper pages only for channel-specific metadata and routing.

This separation gives you several practical advantages for commerce. You maintain a **single source of truth** - when you update a product description or feature list, the change automatically appears on every page and channel that references it. You can deliver the **same product across multiple channels** (websites, microsites, headless applications, email) without duplicating content. Your editors can adjust core product information once, rather than having to update the number of copies across different pages and channels.

In a traditional [page-based content model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-page-based-content-model.md), all product information lives in a single page content type. This works for simple, single-channel websites, but creates duplication and maintenance overhead when you need to present the same product across multiple channels.

> **Tip:** If the content remains the same across all channels, store it in the reusable Product. If it differs by channel (website vs. mobile app vs. email), store it on the _wrapper page_.

For brevity, the rest of the material refers to _wrapper pages_ as _pages_ or _product pages_, unless noted otherwise.

## Model the reusable Product content type

Your reusable **Product** content type stores the core information that defines your product across all channels. Start with essential product fields: product _title_, product _description_, product _summary_ for listings, product _taxonomy_ for categories and tags, and key specifications, such as dimensions, technical details, and other attributes.

If you sell a variety of products that have unique attributes, you should consider creating multiple reusable _product_ content types with shared [reusable field schemas](https://docs.kentico.com/documentation/developers-and-admins/development/content-types/reusable-field-schemas.md) to hold common product data. For example, the **Product core data schema** will hold content that you want to represent this product in listings: _name_, _description_, _price_, _thumbnail image_, and _category_. This schema ensures that every product type, whether it's a book, a piece of clothing, or an article promoting these products, has the same baseline fields for consistent presentation.

### Model modular content using linked content items

In many cases, products share the same features or bring customers similar benefits. For example, a _Fast access to funds_ benefit, or a _Travel insurance_ product feature can be linked to multiple banking products.

To avoid content duplication, you can create a **Product Benefits** content type with fields like _benefit description_, _benefit icon_ or image, and _target audience_. Then, you can create a **Product Features** content type with fields for feature _name_, feature _description_, _options for specialized display cases_ (checkbox), and feature _priority_.

Editors will use [combined content selector](https://docs.kentico.com/documentation/developers-and-admins/customization/extend-the-administration-interface/ui-form-components/reference-admin-ui-form-components.md#combined-content-selector) in the _Product_ content type to link multiple _features_ and _benefits_.

![Linked product features and benefits in the Advanced account on the Kbank demo site](https://docs.kentico.com/docsassets/modules/model-commerce-pages-intro/advanced_account_product_benefits.png "Linked product features and benefits in the Advanced account on the Kbank demo site")

> **Info:** **Pattern takeaway:** You can model reusable benefits and features as linked content items to avoid duplicating product attributes across products. If your features just contain text and don't need images, consider using taxonomies.

This approach lets the team reuse components across products. When they update, for example, the benefit's description or icon in one place, all products that reference it automatically get the update.

![Content reuse locator displays image reuse](https://docs.kentico.com/docsassets/modules/model-commerce-pages-intro/kbank_shared_product_feature.png "Content reuse locator displays image reuse")

> **Info:** **Pattern takeaway:** Reused linked components allow editors to propagate their update to every product page that references the component.

Editors can display the product data, including _benefits_ and _features_, in widgets when needed, as shown in the following custom _Product comparator_ widget on the Kbank demo site.

![Product comparator widget on Kbank demo site](https://docs.kentico.com/docsassets/modules/model-commerce-pages-intro/product_comparator_feature_display.png "Product comparator widget on Kbank demo site")

> **Info:** **Pattern takeaway:** To improve governance, you can build comparison experiences from structured linked content instead of storing repeated comparison tables per individual products.

Store product images as [Media file content items](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/store-files.md) with proper _alt text_ for accessibility and SEO. Link these media files to your _Product_ using the _Combined content selector_.

Find more details about [modeling reusable product SKUs](https://docs.kentico.com/modules/commerce-content-modeling/model-reusable-sku-product-intro.md) in a dedicated material.

> **Warning:** **Fields to avoid in your reusable Product content type:**
>
> Never store _SEO metadata_, _Open Graph tags_, page _URLs_, or website publish dates in your reusable _Product_. These fields are channel-specific and belong in your _wrapper page_. Storing them in the reusable _Product_ creates confusion about which metadata applies to which channel and defeats the purpose of the two-layer architecture.