How retailers can make product catalogues easier for shopping assistants to understand

Shopping journeys are starting somewhere other than your search box

A growing share of product research begins in an assistant, a comparison tool or a generative search result rather than on a retailer’s own site. In that pattern, something else reads your product page and decides how to describe your product — whether it is comparable to a competitor’s, whether it meets the shopper’s stated constraint, and whether it is worth surfacing at all.

That shifts where the commercial risk sits. Historically, a thin product page cost you conversion on your own site. Now it also costs you accurate representation somewhere you do not control. If your specification is a paragraph of marketing prose and your competitor’s is a clean attribute list, the comparison will not favour you — not because the product is worse, but because it could not be compared.

The catalogue fields assistants depend on

Here is the shape of a product record after a page has been read and structured — this is the abridged simlir product object, and it is a fair proxy for what any competent product data layer is trying to extract from your pages:

Read that as a checklist against your own product detail pages. Every field there had to come from somewhere visible. Where your page is silent, the record is null, and a null field cannot help you win a comparison.

Stable identifiers and variant handling

Identity is the single highest-leverage thing on this list, because it determines whether your product can be recognised as the same product a shopper saw elsewhere.

Variants are where most catalogues quietly break. Colour, size, capacity and pack quantity are often meaningful product differences that carry different prices and different GTINs, yet they are frequently collapsed onto a single URL with the distinguishing attribute buried in a dropdown. When that happens, whatever reads the page sees one product with an ambiguous price.

• Give each purchasable variant its own stable, canonical, crawlable URL where the commercial terms differ.
• State the distinguishing attributes as data, not only as selector labels.
• Keep a variant’s identifier stable across restocks and page redesigns. A SKU that changes when the page template changes is not an identifier.
• Do not reuse a retired identifier for a different product. It corrupts every downstream record built from it.

Specifications that can actually be compared

A comparison needs two products measured on the same axis. Prose does not provide one.

Practical rules that survive contact with a real catalogue:

• Use one attribute name per concept across the category. If half your televisions use screen_size and half use display_size, your own filters are already suffering.
• Always attach the unit, and keep it consistent. Mixing centimetres and inches inside one category makes numeric comparison meaningless.
• Separate the number from the marketing. Keep the persuasive sentence — it does real work for shoppers. Just do not make it the only place the fact appears.
• Prioritise the two or three attributes that decide purchases in each category. Nobody needs forty fields. They need the ones people actually compare.

Price and availability with source and checked time

Price is the field most likely to be wrong by the time anyone reads it, which is exactly why it needs context around it rather than more precision.

• Publish the price with its currency, unambiguously, near the product name.
• Make promotional and recommended retail prices structurally distinguishable, so a discount is not misread as a base price.
• State availability plainly — in stock, out of stock, pre-order, discontinued — rather than implying it through the presence or absence of a button.
• Where you publish structured product markup, make sure it matches the visible price. A mismatch between markup and page is worse than no markup: it is the fastest way to lose eligibility for rich results.

Any responsible data layer downstream will treat what it read as a snapshot — a value with a date attached, not a live quote. simlir returns price.as_of alongside the amount, currency and retailer for exactly this reason. That is in your interest: it means the assistant that surfaces your product can tell a shopper “£29.99, seen on 7 April — check the retailer page” rather than asserting a stale number as current and generating a disappointed click.

Images, descriptions and canonical retailer links

• Hero image. One durable, retailer-hosted HTTPS image that is not an expiring thumbnail. Expiring or signed CDN URLs break every downstream reference within days.
• Gallery. Additional angles and the specification or nutrition label where relevant. Label imagery is unusually valuable because it carries facts in a form a visual system can read. All HTTPS.
• Description. Two registers are useful: a short factual summary of what the product is and who it is for, and the longer persuasive copy. The short version is what tends to get quoted.
• Canonical link. One canonical URL per purchasable product that does not change between site releases. Every downstream reference to your product depends on it.

What a missing field actually costs you

The abstract case for data quality is unconvincing. The concrete case is that each missing field removes a specific opportunity to be chosen.

A readiness checklist you can run this week

Take one live category — not the whole catalogue — and work through it. A single category is enough to reveal every systemic gap you have.

• Every purchasable variant has a stable, crawlable URLAnd its distinguishing attributes are stated as data.
• GTIN or MPN is published wherever one existsVisible on the page, not only in an internal system.
• The category uses one attribute name per conceptNo screen_size and display_size living side by side.
• Every numeric specification carries a unitConsistent across the whole category.
• The two or three deciding attributes are present on every productThe ones shoppers in that category actually compare.
• Price and currency are unambiguousPromotional and reference prices are structurally distinct.
• Availability is stated, not impliedIn stock, out of stock, pre-order, discontinued.
• Structured markup matches the visible pageSame price, same availability, same product.
• A durable HTTPS hero image existsNot an expiring thumbnail or a signed URL.
• Product pages are crawlableIndexable, not blocked, reachable through internal links.
• Canonical URLs survive site releasesRedirects in place where they do not.
• Someone owns the refresh cadencePrice and availability changes reach the page promptly.

Partnership options for broader discovery

Improving your own pages is the foundation, and it benefits every channel you have. Beyond that, retailers who want their catalogue represented accurately inside assistant and comparison surfaces generally have two routes: publish clean, crawlable public product pages and let structured product data layers read them, or work directly with a product data partner on catalogue listing so that identity, specifications and freshness are handled deliberately rather than inferred.

simlir structures products from public UK retailer pages today. If you would like to review how your catalogue is being represented, or discuss a listing partnership, email hello@simlir.com.

Frequently asked questions