Structured product data means every product fact lives in a typed attribute with a unit, a stable id…
Structured Product Data: How It Shows Up in Your Storefront
Structured product data means every product fact lives in a typed attribute with a unit, a stable identifier and a clear place in the variant hierarchy, not in a description text. Shoppers never see the data model, but they see its effects in five places: filters, comparison tables, variant selection, Schema.org markup and feeds. When the model is weak, each of those components has to guess, and shoppers notice.
What "structured" means in a product catalog
"We have a PIM" and "our product data is structured" are two different statements. Structure is the set of modeling decisions you make inside the PIM:
- Attribute model: each attribute has a type (text from a value list, number, yes/no, range) instead of free text. "White", "white " and "wht" are three filter values; one value from a list is one.
- Units: the number and the unit are stored separately. "approx. 60 cm" in a text field never becomes a range slider, 60 with the unit cm does.
- Classification: in technical B2B assortments, standards like ETIM and ECLASS define these rules for you. ETIM describes products through classes and features of four types (alphanumeric, logical, numeric, range), and numeric and range features need a unit, apart from counts such as number of poles. ECLASS gives every property a globally unique identifier (IRDI) and supports value lists and convertible units.
- Variants: a parent product carries shared information, each purchasable variant carries its own SKU, GTIN, price and stock, and the variant axes (size, color, voltage) are explicit.
- Multilingual data: identifiers stay language independent, only labels and values get translated.
- Media assignment: images are linked to the variant or option they show, not just dropped into a gallery.
Filters and facets: where gaps show first
A facet is only as good as the attribute behind it. In Laioutr, Orchestr defines one filter contract for listing pages: list filters, boolean toggles, continuous ranges and pre-bucketed intervals. Range bounds can be plain numbers, money or a measurement with a unit. The link to your data model is direct: a width stored as number plus unit becomes a slider, a width stored as text becomes a long, unsorted checkbox list at best.
Facet values and counts come from your backend or search provider; components such as the filter bar and the off-canvas filter sheet render what Orchestr returns. If you want semantic search and filters that adapt to the result set on top of that, AI Search & Discovery covers it as an add-on. The foundation of your facets is still your attribute model.
Filters also matter for crawling: Google's guidance on faceted navigation recommends preventing crawling of filter URLs if you don't need them indexed. If you want them indexed, keep the parameter order consistent and return a 404 for empty combinations. How often shoppers start with a filter rather than search is the subject of our analysis of AI search, category browse and faceted filters.
Spec sheets and comparison tables: why shared identifiers matter
In the canonical product model Laioutr uses, specifications are ordered rows: a display name, a typed value (text, number, boolean, measurement or money) and an optional section such as "dimensions" or "technical". The product specifications table formats each value per locale and groups rows into sections. A shopper in Germany sees "1,5 kg", a shopper in the US sees "1.5 kg", from the same data.
A comparison table puts these rows for several products side by side, which only works when rows share identifiers. If one product calls it "Weight" and the next one "Net weight (kg)", the table has holes, and a "differences only" view ends up comparing labels instead of values. Well-known property names exist precisely so that rows from different connectors line up.
Once the rows are consistent, placing the specifications table on a product detail page is layout work, not a data project, handled by editors in Studio, the visual editor of Laioutr. A product comparison view, if your project builds one, reads the same rows.
Variant selection: axes, availability and images
In the canonical model, a product holds its option groups (for example size with S, M, L and color with red and blue), and each variant carries its selected options, SKU, optional GTIN, availability and prices, including unit prices.
Typical failure patterns:
- Colors modeled as separate products. The selector cannot offer them, so shoppers jump between product pages.
- Availability only per value. Graying out "XL" works per axis value, but "red in XL" is a combination and needs variant-level stock.
- Images attached to the parent only. Selecting blue changes the price, but not the photo.
All three get fixed in the data model, not in the component.
Schema.org and feeds: the same structure, read by machines
Search engines and AI answer engines read the same facts as your filters. Schema.org lets a Product carry additional properties as PropertyValue pairs: propertyID holds a standard code for the characteristic, which is where an ETIM or ECLASS identifier fits, and unitCode takes a UN/CEFACT unit code. For variants, Google documents a ProductGroup with a productGroupID, the attributes it varies by, and nested variants.
In a Laioutr frontend, you can generate JSON-LD with the Nuxt Schema.org module from the entity a section renders, instead of from separately maintained SEO fields. That way markup and visible page share one source, see SEO and GEO.
Feeds follow the same rules. Google Merchant Center expects the same item group ID across all variants of a group and different values for color, size, material or pattern. Why forty channels turn into forty truths is covered in our post on product data consistency across channels. For channel exports straight from the frontend layer, Distributr is available as an add-on: zero imports because the data is already there, one direction, out. It is not a PIM.
One data model across backends with Orchestr
Product data rarely lives in one system: the PIM owns attributes and media, the ERP prices and stock, a search provider the facets. Orchestr maps these sources into one canonical model of products, variants, specifications and filters, so components receive the same shape regardless of where a field comes from. It bundles several sequential API calls into one request and uses three-tier caching. Laioutr connects to 50+ backends through 300+ integrations; other sources can be connected through an Orchestr integration. More on the architecture: Composability and Orchestration.
Where to start:
- Audit the 20 attributes your most important category filters use: type, unit, value list.
- Decide the variant axes in the PIM before the next frontend release.
- Map attribute identifiers to shared names so comparison rows line up.
- Generate structured data from the rendered entity, then check your feeds against it.
FAQ
Do we need ETIM or ECLASS?
Only if your market expects them, typically in technical wholesale, electrical and building services, or industrial procurement. For fashion or consumer goods, a clean in-house attribute model with typed values and units is usually enough.
Does Laioutr replace our PIM?
No. The PIM stays the system of record for product data. Laioutr is the frontend layer: it reads the data through Orchestr, renders it in components and keeps the storefront consistent across backends.
Who maintains filters and spec tables, developers or marketing?
Both, with a clear split. Developers define components and data bindings once. Product and marketing teams place and configure them in Studio, without a ticket for every category page.
Next steps
Want to see how your attribute model behaves in filters, spec tables and variant selectors? Book a demo and bring a sample category. We will look at it together on a Composable Headless Frontend.