Model commerce wrapper pages

When you build commerce experiences in Xperience by Kentico, you might require a content architecture that separates reusable product data from channel-specific presentation. In this guide, you’ll learn how to model pages to display product content using the atomic content model. 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 from the Content hub and adds channel-specific context like SEO metadata, URLs, and publish dates. This pattern comes from the atomic content model, 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.

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.

For simple, single website-channel projects with no plans for expansion, a page-based model 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. 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.

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

To simplify the text, we’ll refer to wrapper pages as pages or product pages in the following guide, unless it’s stated 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 consider creating multiple reusable product content types with shared reusable field schemas 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 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 in the Product content type to link multiple features and benefits.

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.

Editors can display the product data, including benefits and features, in widgets when need, as shown in the following custom Product comparator widget on the Kbank demo site.

Store product images as Media file content items 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 in a dedicated material.