Product Data for AI Search: Structuring a Catalogue to Be Cited

When a shopper asks an assistant for "a waterproof hiking boot under £150 with a wide toe box," the system must determine which products satisfy three constraints. Products whose data does not express waterproofing, price, and fit as retrievable attributes are not compared and rejected — they are never considered.

This is the practical shift in product data for AI search. Ranking positions matter less than whether your catalogue can answer structured questions about itself.

Attribute completeness is the constraint

Most product catalogues describe products in prose written for humans. "Crafted from premium full-grain leather with a weatherproof membrane, these boots are built for the trail." A person understands this. A retrieval system matching on waterproof: true does not, unless something maps that claim to that field.

The requirement is that constraint-relevant attributes exist as structured data, not only in description text.

For each category, enumerate the attributes buyers actually filter on and verify every product has them populated:

Footwear:     size range, width fitting, material, waterproof rating,
              sole type, intended terrain, weight, closure type
Electronics:  dimensions, weight, power draw, connectivity standards,
              compatibility, warranty duration, included accessories
Apparel:      fabric composition, care instructions, fit descriptor,
              size chart mapping, country of manufacture

The common gap is not missing products but sparse attributes. A catalogue where 30% of products lack a populated material field will see those products systematically excluded from any material-constrained query, without any error appearing anywhere.

Audit for sparseness. For every attribute, calculate the fill rate across the catalogue. Anything below 90% on a filterable attribute is costing you consideration.

Schema that carries real information

Product structured data is well-supported and usually implemented shallowly — name, image, price, availability, and nothing else.

The fields that affect retrieval:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Ridgeline GTX Hiking Boot",
  "sku": "RDG-GTX-001",
  "gtin13": "5012345678900",
  "brand": { "@type": "Brand", "name": "Ridgeline" },
  "material": "Full-grain leather, GORE-TEX membrane",
  "weight": { "@type": "QuantitativeValue", "value": 480, "unitCode": "GRM" },
  "color": "Dark Brown",
  "audience": { "@type": "PeopleAudience", "suggestedGender": "unisex" },
  "additionalProperty": [
    { "@type": "PropertyValue", "name": "Waterproof", "value": "Yes" },
    { "@type": "PropertyValue", "name": "Width Fitting", "value": "Wide" },
    { "@type": "PropertyValue", "name": "Terrain", "value": "Mixed trail" }
  ],
  "offers": {
    "@type": "Offer",
    "price": "145.00",
    "priceCurrency": "GBP",
    "availability": "https://schema.org/InStock",
    "priceValidUntil": "2026-12-31",
    "shippingDetails": { "@type": "OfferShippingDetails" },
    "hasMerchantReturnPolicy": { "@type": "MerchantReturnPolicy" }
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "218"
  }
}

Three points that matter more than the rest:

`additionalProperty` is where category-specific attributes belong. Schema.org cannot enumerate every attribute for every category. This is the escape hatch and it is heavily underused.

GTIN is the identity anchor. It lets systems reconcile your product with the same product elsewhere — reviews, specifications, price comparisons. Products without GTIN exist in isolation and are harder to verify, which reduces the confidence a system has in citing them.

Returns and shipping affect selection. Assistants increasingly surface total cost and return terms. Products without this data are compared unfavourably against products that state it explicitly.

Consistency across surfaces

Your product data appears on your site, in your merchant feed, in marketplace listings, and in aggregator databases. Where these disagree, confidence in all of them drops.

The recurring inconsistencies:

• Price mismatch between page, feed, and structured data — usually caused by promotional pricing updating on different schedules.

• Availability drift where the feed refreshes daily but stock changes hourly.

• Title variation across channels, breaking entity matching.

• Attribute contradiction — "waterproof" in the description, water_resistant: false in the feed.

Treat one system as canonical, generate everything else from it, and monitor for divergence. Manually maintained parallel data always diverges.

What causes omission

Products fail to appear in assistant answers for identifiable reasons:

No structured data, or invalid structured data. Validate with Google's Rich Results Test and the Schema Markup Validator. A single syntax error can invalidate the whole block.

Client-side rendering without server-side output. If product data is injected by JavaScript after load, crawlers that do not execute JavaScript see nothing. Server-render structured data.

Blocked crawlers. Check robots.txt for GPTBot, ClaudeBot, PerplexityBot, Google-Extended. Blocking removes you from those systems entirely.

Thin variant pages. Twenty near-identical colour variants as separate indexed URLs dilutes rather than multiplies. Use a canonical product page with variants expressed through structured data.

Unverifiable claims. "Best-selling" and "premium quality" carry no retrievable meaning. Specific, checkable claims are what get cited.

Description text that survives extraction

Prose still matters, because assistants quote it. What extracts well is different from what reads well as marketing.

Put specifics in self-contained sentences. "The membrane is rated to 10,000mm hydrostatic head" survives being quoted alone. "It'll keep you dry no matter what the weather throws at you" does not.

Answer the questions buyers ask. Sizing relative to standard, compatibility, what is included, care requirements. Product pages that answer these directly get cited on those queries.

Use plain attribute language somewhere on the page, even if headline copy is stylish. "Waterproof" should appear as a word, not only as an implication.

Measurement

Attribution is limited, so measure inputs alongside outputs:

• Structured data coverage — percentage of catalogue with valid, complete markup.

• Attribute fill rates per category, tracked over time.

• Crawler access in server logs by user agent. The most direct available signal and the most ignored.

• Referral traffic from AI assistants, undercounted but directionally useful.

• Manual citation sampling — a fixed set of representative buying queries, checked periodically across assistants.

Frequently asked questions

What matters most for AI shopping visibility? Attribute completeness. Products missing the attributes a query constrains on are never considered. Audit fill rates before anything else.

Is Product schema enough? Basic implementation is not. Use additionalProperty for category-specific attributes, include GTIN for identity reconciliation, and add shipping and returns data — assistants increasingly surface total cost and return terms in comparisons.

Should variants have separate pages? Generally no. Twenty near-identical variant URLs dilute signals. Use a canonical product page expressing variants through structured data.

How do I know if AI systems can access my catalogue? Check server logs for AI crawler user agents, and verify robots.txt does not block them. This is directly observable and frequently misconfigured by inherited defaults.

Does description copy still matter? Yes — assistants quote it. Write specifics in self-contained sentences that survive extraction without surrounding context, and state attributes in plain language somewhere on the page.

Further reading

• Schema.org Product specification

• Google merchant product data specification

Related

• Web development

• Selected work

• Talk to us