--- title: Choose a product storage strategy --- > 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). ## 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](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md#use-wrappers-to-display-atomic-content-across-multiple-channels). 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](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-page-based-content-model.md), 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](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/structured-and-unstructured-content.md)) is displayed through a static view and [Page Builder components](https://docs.kentico.com/documentation/developers-and-admins/development/builders/page-builder.md) that editors arrange to create the optimal product detail page. **When to use each approach** | Use Content hub when: | Use Website channel when: | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Products must be displayed across multiple channels, such as websites, mobile apps, and marketplaces.
You're building headless or API-first commerce experiences.
You want centralized product management separate from presentation concerns.
Your product data needs to integrate with external e-commerce platforms or PIMs.
You have multiple websites or brands sharing the same product catalog.
Content reuse and avoiding duplication are a priority. | Your commerce implementation is focused on a single website.
Individual SEO control per product page is critical.
Editors need to customize the presentation and layout of each product page using Page Builder.
Your products don't need to appear in other channels.
You want editors to manage products in the same interface where they manage other website content.
Simpler editor workflows are prioritized over multi-channel flexibility. | 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. > **Tip:** **Customize Xperience to auto-create page wrappers or page proxies** > > Many successful commerce implementations adopt a semi-hybrid approach that uses a unifying pattern: products stored in the _Content hub_ with automatically generated product _wrapper pages_ in the website channel. Or, they store data in website pages, but [connect them with Content hub capabilities](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-page-based-content-model.md#connect-webpages-with-content-hub-reusability). > > Your developers then implement logic that automatically generates a corresponding: > > - Product page ([in atomic content model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-atomic-content-model.md) ) in the website channel for each product, pulling data from the _Content hub_ product and combining it with channel-specific SEO, _OpenGraph_ and other page-specific fields and presentation elements (e.g., in a page template). > - Page proxy [in page-based content model](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-page-based-content-model.md) in the _Content hub_ for each product page helps the page content to participate in _Content hub_ workflows, such as filtering or displaying using [smart folders](https://docs.kentico.com/guides/development/advanced-content/deliver-content-dynamically-with-smart-folders.md) across related content. > > Although this approach requires more upfront development and customization, t is ideal for projects relying on multi-channel content reuse and individual product URLs. ## 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](https://docs.kentico.com/documentation/developers-and-admins/development/content-types/reusable-field-schemas.md) to prevent duplication and optimize data queries.