Ecommerce catalogue architecture

An ecommerce catalogue needs two things to agree: what the shopper understands as the product and what staff can fulfil. Define saleable items first, then organise the descriptions, categories and attributes that help people find them. Product count alone is a poor measure of difficulty; a small range with stocked choices or frequent specification changes can be complex.

Define the product model

Take a sample with a simple item, a separately stocked choice, a personalised item and a set sold together. For each, record what the shopper selects, what staff supply and which record controls availability.

Platform names for these elements differ. What matters is preserving the distinction between a stocked item and an instruction about that item.

Classify the catalogue records

Decide whether each offer is a physical or digital product. Physical products exist in physical form, have a weight and ship to customers; digital products are non-physical and can include downloadable files or services. The distinction affects which product details the catalogue must represent.

A catalogue record can carry more than a name and sale price. Include descriptive fields such as manufacturer part number (MPN), warranty and images, plus other details. Use a field list to separate product description from the choices a shopper makes at purchase.

Separate identity from presentation

Names, images and categories help shoppers recognise products. A SKU or other item identifier helps staff and connected systems recognise what was sold. A stocked size may need its own identity; an engraving message must reach the order without becoming a separate stock item.

List fields that can differ by saleable choice, such as price, stock, image, weight and availability. Record where a blank value comes from and who may edit it. Do not assume a product-level price or stock message covers every choice. Define the expected page, basket and order result when a combination is unavailable.

For a bundle, distinguish the offer from its components. Record whether contents are fixed, how component stock affects availability and what staff must pick.

Model selectable variations consistently

For each selectable variation, record the option name separately from its value and connect each combination to its own SKU or other item identifier. This links the shopper-facing choice to an identifiable saleable item.

A configurable-product model can present variations on one product page while representing each variation as a separate product with its own SKU, enabling individual inventory tracking. In this model, the displayed price comes from an in-stock child product, and the parent’s stock status is determined by its associated variations.

Design routes through the range

Use categories for the main browsing routes and attributes for properties that help shoppers narrow a category. A dining-table category, for example, might use length, material and seating capacity as attributes.

Choose customer-facing filters from buying questions, then define consistent values. If suppliers use different terms for the same property, decide how the store will present it without erasing distinctions that matter to buyers.

Check that a filter leads to the expected products, that selected values are visible and removable, and that a shopper can recover from no results. A field useful to staff does not automatically need to appear as a filter.

Distinguish the catalogue’s organising structures

Use categories as hierarchical groups for broad browsing, tags as non-hierarchical descriptors linking related products, and attributes as properties that can support product variation, selection and filtering. Decide which role each piece of information serves before adding it to the catalogue.

A category tree can have parent and child categories; a child can have only one parent, while a parent can have multiple children. Subcategories can be nested several layers deep, but WooCommerce recommends keeping the structure as simple as possible. Map the intended browsing routes before creating a deep tree.

Attributes may be shared across many products or set up for an individual product. Use shared attributes for properties that recur across the range and product-specific attributes for details unique to one product. Attributes can support filtering and selection as well as product variations.

Assign ownership to product data

For each important field, record its source, editor, approver and destinations. If another system owns stock quantity, identify that system and the update path. When a supplier changes a material description or colour name, the owner should know which pages, filters and sales channels need review.

A useful design exercise is to add one stocked choice, retire another and correct a shared specification in the proposed data model. Record every required edit, the affected records, pages and sales channels, and any place an old value could remain visible.

Map catalogue data to its uses

Products are the primary catalogue records used to sell on the storefront and other channels. Map each required field to its intended uses, noting which record supplies it and whether it must be consistent across channels.

For each relevant channel, note whether it needs the variation’s selectable value, identifier and variation-specific data. Identify the record that supplies each.