Model a product detail page

Product listing pages display collections of products. You use them for category pages (like Business Banking Products or Dog Accessories), search results or filtered views, and department-level pages like All Products. Your listing pages can include Page Builder zones to let editors personalize which products appear for different audience segments.

You have two approaches for building product listings. Approach A uses query-based listings either through page template presets with preconfigured widgets (recommended for most scenarios) or list content without the Page Builder. Approach B uses manual selection (recommended for curated collections).

Query-based listings (Approach A)

In a query-based listing, your listing page does not directly reference individual products. Instead, editors configure filters and criteria, and products are dynamically retrieved based on taxonomy assignment, tags, dedicated classification content types, or smart folder criteria in the Content hub.

This approach has clear benefits. Product listings automatically update when editors add new products that match the criteria. Your model reduces editorial maintenance by eliminating the need for editors to manually add products to every relevant listing. The approach scales well for large product catalogs.

For example, a Business Banking Products page configured to filter by the Business Banking taxonomy will automatically show all current and future products tagged with that category.

Use Page Builder with page template presets

We recommend using Page Builder to present product listings. This approach provides editors with the most flexibility and the best editing experience. Create a Product Listing Page content type with minimal structural fields, then use page template presets to automatically populate preconfigured widgets when editors create new listing pages.

Your Product Listing Page content type can include:

• Core content schema (or create individual fields) for the page’s title, description, and thumbnail
• Configuration for filtering criteria, such as a taxonomy selector to specify which categories or subcategories to display, tag filters to include or exclude specific tags, and content type filters if you want to show only certain product types.
• Channel-specific metadata: SEO metadata schema, Open Graph metadata, hero or banner content specific to this listing page.

Decide where editors will control presentation settings

Editors can configure presentation options at the template level through template properties (affecting the entire page) or at the widget level through widget properties (providing more granular control per widget instance). Template-level properties work well for consistent page-wide settings, such as default sort order or the number of columns, while widget-level properties give editors the flexibility to vary presentation within the same page.

Create product listing widgets that read the filter criteria from your Product Listing Page content type and dynamically retrieve matching products. Expose key presentation options, such as display style and sort order, through your chosen properties approach. Use section properties to let editors adjust page layout elements like column count without requiring code changes if they prefer a more granular approach.

For inspiration, you can check the Articles widget on the Kbank demo site. Editors can define subpages within a specific section of the Content tree and then further filter the selected content by tags or by specifying how many articles to include. Your product listing widgets can work similarly.

When editors create a new listing page, assign an existing page template preset to automatically populate preconfigured widgets. This automation works particularly well when you create products and listing pages over API.

This approach supports widget personalization for different audience segments, allows editors to customize page layout without developer involvement, and provides the most intuitive editing experience.

Embrace developer-driven page rendering

If you decide to implement product listings programmatically with developers controlling the presentation layer directly (rendering product data without Page Builder widgets), you should still include Page Builder capabilities for content personalization.

At minimum, add a Page Builder editable area through your page template properties. This allows editors to add supplementary content sections, such as:

• Personalized Featured products widgets for different audience segments
• Promotional banners or callouts specific to certain visitor types
• Cross-sell or related product sections
• Marketing content that complements the programmatic product listing

This hybrid approach gives developers full control over the core product listing logic while preserving editorial flexibility for personalization and promotional content.

Manual selection listings (Approach B)

In a manual selection listing, the product listing page directly references specific products using widgets or a content item selector configured to allow multiple product selections. Editors manually curate which products appear and control their order by dragging items in the selector.

This approach works well when editorial curation is important, especially for featured or curated collections, seasonal promotions that highlight specific products, or any scenario where you need full control over which products appear and in what order.

You can create a Universal page (or a dedicated Product listing page) content type with the same channel-specific metadata as above: SEO metadata schema, Open Graph metadata, and page-specific hero or banner content. Then define a product listing page template with properties, allowed sections, and Product widgets that editors can use to display product data on the website.

The following image shows how you can compare products that share the same modular Featured content properties. Editors select which products to compare, and developers ensure the data is properly displayed. You can use this approach to replace traditional comparisons, which were commonly defined through product comparison tables, meaning the data and features were often stored (and duplicated) within individual products.

Optionally, you can create a product listing page with a Product selection field. Besides SEO and other fields, it will include a content item selector configured for multiple products, allowing editors to manually reorder selections on the Content tab, rather than using Page Builder widgets..

The following image shows the Dancing Goat website, where editors use the Event field to select events to be promoted on the Home page. The events can then be displayed on the website. In the Dancing Goat website’s case, only the first item is displayed. In real life, selected events (or products in your model) can be displayed through a slideshow widget, or dynamically without the editor’s intervention, based on a configuration prepared by the developers.