Module: Commerce content modeling
21 of 38 Pages
Design considerations for commerce wrapper pages
Consider how products will be filtered
Will you use taxonomy tags, content type fields, price ranges, or a combination? Decide whether editors need to override the automatic order or if products should always sort by date, popularity, or price. Determine whether featured products should appear first in each listing.
The following product listing allows editors to hand-pick products to display. Using widget personalization, they can easily tailor selected products to different audiences.

Plan for listing edge cases
How will you handle empty listing pages when no products match the criteria? Will you show a No products found message, display featured products as a fallback, or automatically redirect to a dedicated page?
Choose a filtering approach
When modeling a listing page, decide which filtering strategy your product listings will use. Although the visitor-facing experience may look similar, the underlying implementation differs significantly and affects your content model.
Search index-based filtering uses a search engine (such as Lucene or Azure AI Search integration) to filter products by facets included in the search index. With this approach, the search engine handles filtering logic, supports full-text search alongside faceted navigation, and performs well with large catalogs. However, you need to maintain a search index that stays synchronized with your content, and your filterable attributes must be explicitly mapped to the index. This approach is best suited for catalogs where visitors need to combine multiple filter criteria, such as price, category, rating, and availability, or when full-text search is a requirement.
Direct content filtering queries content items or pages directly based on their content type field values, taxonomy assignments, or content tree position. This approach requires no additional infrastructure beyond your Xperience instance and gives you real-time access to the latest published content without index synchronization delays. However, complex multi-facet filtering can become resource-intensive on large catalogs, and you may need to optimize carefully queries.
|
Consideration |
Search index-based |
Direct content filtering |
|
Content freshness |
Might be affected by index rebuild timing |
Immediately after publishing |
|
Performance at scale |
Optimized for large catalogs |
Best for smaller to mid-size catalogs |
|
Infrastructure |
Requires a search index |
No additional setup |
|
Multi-facet filtering |
Handles complex combinations efficiently |
Can become costly with many facets |
Your filtering strategy influences your content model. For search index-based filtering, ensure the product fields you want to filter by are structured and indexable (avoid storing filterable attributes in rich text fields). For direct content filtering, consider using taxonomy tags, dedicated classification fields in a content type, or dedicated categorization content types that support efficient querying.
Also consider whether you’ll use pagination, infinite scroll, or Load more buttons for long product lists. These decisions influence which template properties, custom Page Builder widgets, or dedicated fields on the Content tab your listing pages will require.
In the following image, you can see a location page from the Khealth demo site. Clients can filter out locations based on their preferences.

The filtering (and facets) in Khealth use the content tree structure, where individual items represent the filter options for services and locations, as shown in the following picture.
