Almost everything written about LLM optimisation is about blog posts. Write clearly, use headings, answer the question early. Fine advice, and useless if your problem is 400,000 SKUs where the torque rating lives in the middle of a paragraph. Product catalogues fail machine reading for structural reasons, not stylistic ones. This is what those reasons are, and what you change in the data model to fix them.
What the model actually receives
Start with the mechanism, because most LLM optimisation advice ignores it.
A language model answering a product question does not read your website. It receives a retrieved fragment of text, or a row of feed data, alongside the question. Google describes its own approach as retrieval-augmented generation, plus query fan-out. It defines fan-out as a set of concurrent related queries the model generates to request more information. So “cordless impact driver, brushless, under 200 pounds” becomes several retrievals, each one narrower than the original question.
Two consequences follow, and they drive everything else in this article.
First, the unit of retrieval is smaller than a page. A fragment lifted from your specification section arrives without the page title, without the breadcrumb and often without the brand. If the fragment cannot identify the product on its own, it is weak evidence.
Second, the model is matching conditions, not vibes. Brushless is a condition. Under 200 pounds is a condition. In stock is a condition. Each one needs a value the system can check. Prose that gestures at a fact is worse than a field that states it. This is where catalogue applied AI work diverges from content marketing advice.
Two pipes, not one
Your product data reaches these systems through two different routes with different rules. Optimise one and ignore the other and you get half the result.
The feed pipe
Structured commercial data goes to the model through merchant feeds. Google’s Shopping Graph is fed largely from Merchant Center. Sundar Pichai put it at over 50 billion listings in January 2026, with more than 2 billion refreshed hourly. OpenAI takes feeds through the Agentic Commerce Protocol, with an initial validation feed and daily snapshots. Microsoft runs an equivalent merchant programme for Copilot.
The feed pipe is typed, validated and predictable. It is also constrained. You send what the spec allows. OpenAI’s product feed spec requires item ID, title, description, URL, brand, image URL, availability and price on every item. Google’s Merchant Center has been extending its spec in the same direction. It added conversational attributes, intended to help AI systems understand a product’s nuances. It also has a product detail attribute for technical specifications, structured as section name, attribute name and attribute value.
The page pipe
Everything else comes from the page. OpenAI describes shopping research in ChatGPT as organic and based on publicly available retail sites, reading product pages directly and citing sources. Google’s guidance is that pages need to be indexed and eligible for a snippet, with no additional technical requirements beyond that.
The page pipe carries what the feed cannot: long-tail specifications, compatibility, application guidance, certification detail. For industrial and automotive catalogues that is most of the useful content. It is also where the structural failures live.
Entity naming: one product, one name, one identifier
Retrieval is only useful after resolution. The system has to decide that the fragment it retrieved and the product the shopper named are the same object.
Identifiers first. Google recommends the most specific GTIN that applies. OpenAI’s feed spec takes GTIN as an eight to fourteen digit value with spaces and dashes stripped, and MPN up to seventy characters. In distribution catalogues the MPN often matters more, because the manufacturer part number is what a trade buyer types and says. Both should be present, unique, and never recycled onto a successor product.
Brand as an entity, not a string. The single most common resolution failure we find is a free-text brand column holding four spellings of one manufacturer. That is four entities to a machine. Fixing it is unglamorous reference data work. You need a controlled supplier or brand record, with the legal manufacturer behind the retail brand on own-label lines.
Title construction. A title has to carry product type, brand and the variant discriminator, because it is frequently the only identifying text inside a retrieved fragment. “DTD172Z” identifies nothing. “Makita DTD172Z 18V brushless impact driver, body only” resolves cleanly. Titles built from internal shorthand are a resolution failure disguised as a copywriting choice.
Attributes: the concept problem and the unit problem
Product catalogues differ from every other kind of content here. This is the part SEO tooling does not reach.
The concept problem. If a condition a buyer filters on does not exist as an attribute, it cannot be checked. Brushless, IP66, three-phase, fits a 2018 Transit, suitable for potable water. Each is either a field or a sentence. Our experience is that most mid-market catalogues carry perhaps a third to a half of the attributes their category needs. The missing ones cluster in application and compatibility, not physical dimensions.
The fix is schema work before content work. Take the top fifty queries per category from Search Console and site search. Every recurring concept becomes a candidate attribute. That is the same exercise we run in taxonomy and attribution projects. It is boring. It also returns more than anything else on this list.
The unit problem. A numeric attribute needs a number and a unit held separately. “1200mm approx” is a string. So is “1.2m” in a column where the neighbouring rows are in millimetres. Mixed units inside one attribute break every range comparison, and range comparison is exactly what a fan-out query does. One unit per attribute, enforced at the schema level, validated on import.
Ranges and tolerances. Operating temperature, torque range, pressure rating. These need minimum and maximum as separate values, not “minus 20 to 60”. Schema.org’s PropertyValue carries minValue and maxValue for precisely this. Our piece on industrial technical specifications goes further into where these break in practice.
Spec tables that survive extraction
Now the page side. The goal is a specification block that stays intelligible after it has been cut out of the page.
Three rules cover most of it.
Use a real table. An HTML table with header cells and data cells preserves the association between property and value when converted to text. A grid of styled divs frequently does not. A specification rendered as an image or trapped in a linked PDF is not read at all.
Repeat the identifier near the specs. Put the brand and the part number in the table caption or the section heading immediately above it. If the fragment is lifted alone, it still identifies its product.
Mirror the table in markup. Schema.org’s additionalProperty exists for exactly this case. It is defined as a property-value pair representing an additional characteristic of the entity, for which there is no matching schema.org property. The expected type is PropertyValue, which carries name, value, unitCode and unitText. The unitCode field takes the UN/CEFACT Common Code, three characters. Where you cannot supply a code, unitText is the documented fallback.
An illustrative fragment, values invented:
{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “Example 18V brushless impact driver, body only”,
“mpn”: “EX-DTD172Z”,
“brand”: { “@type”: “Brand”, “name”: “Example Tools” },
“additionalProperty”: [
{ “@type”: “PropertyValue”,
“name”: “Maximum fastening torque”,
“value”: 180,
“unitText”: “Nm” },
{ “@type”: “PropertyValue”,
“name”: “Motor type”,
“value”: “Brushless” },
{ “@type”: “PropertyValue”,
“name”: “Battery platform”,
“value”: “18V” }
]
}
One warning. Schema.org itself says applications built around specific properties, such as width or gtin13, will expect data in those properties rather than the generic mechanism. So use the dedicated property where one exists, and additionalProperty only for the long tail. Google’s Merchant Center, for instance, reads dimensions as QuantitativeValue objects on width, height, depth and weight.
Variants: the structure most catalogues cannot emit
Variant handling is the failure that produces the most confidently wrong answers.
Google’s variant markup uses ProductGroup. The group carries a productGroupID, sometimes called the parent SKU. Variants sit under hasVariant, or point back with inProductGroupWithID. The variesBy property names which properties distinguish the variants. Google supports six: colour, size, suggested age, suggested gender, material and pattern (schema.org spells several of those the American way).
The point for a product data team is upstream of the markup. You cannot emit ProductGroup unless the catalogue expresses a parent, its children, and the axes that vary. Plenty of PIMs hold a flat list where size and finish are free text on the record. Plenty of others hold a parent with no declared axes. In both cases the markup cannot be generated correctly, and price and availability end up attached to the wrong level. See our note on product attributes for how the variant axes fall out of schema design.
What structured data does and does not do
I part company with a lot of published LLM optimisation advice here. Let me be exact.
Google’s own documentation is direct about this. You do not need to create new machine-readable files, AI text files, markup or Markdown to appear in its generative AI features. It states there is no special schema.org structured data required. It also says structured data is not required for generative AI search. Take that at face value. Adding Product markup does not buy you a place in an AI Overview.
Structured data still earns its keep for three other reasons.
It makes you eligible for merchant listing and product snippet rich results, which have documented required properties. It feeds Merchant Center automatic feeds, where Google reads name, description, image, brand, GTIN, MPN, price, availability, condition, shipping and return policy from your markup. And writing it forces useful discipline. A typed value with a unit cannot be written in markup unless it exists in the catalogue.
The constraint to respect is Google’s structured data policy. Markup must be a true representation of the page content, and you must not mark up content that is not visible to readers. Emitting a fuller spec set in JSON-LD than you show on the page is a policy breach, not a clever tactic.
Rendering and access
Two technical checks that override everything above, because a fact that is never fetched cannot be optimised.
Rendering. Vercel and MERJ published server-log analysis in December 2024 across the major AI crawlers. They found those crawlers fetch JavaScript files but do not execute them, so client-side rendered content is not readable to them. Googlebot renders, and Gemini uses Googlebot’s infrastructure. The others largely do not. If your spec table populates on tab click, or stock comes from a client-side API call, assume it is invisible.
Access. OpenAI runs separate agents for separate jobs. GPTBot is for model training. ChatGPT-User handles user-initiated fetches. OAI-SearchBot powers search, and OpenAI states that sites opting out of it will not be shown in ChatGPT search answers. Google added a Search Console control in June 2026, starting with a subset of UK site owners. It lets you decide whether your content appears in and grounds generative AI Search features. Opting out means no traffic or impressions from those features. Check what your robots.txt and your Search Console settings actually say.
The file you do not need
llms.txt comes up in every LLM optimisation conversation, so here is the evidence.
Ahrefs analysed 137,210 domains in May 2026 and found that 97 per cent of llms.txt files received zero requests that month. Where files were fetched, most traffic came from SEO auditing tools, and AI retrieval bots accounted for about 1.1 per cent of requests. Ahrefs also reported zero requests from AI bots for llms.txt files that did not exist, meaning nothing goes looking for the file. Google’s John Mueller said in June 2025 that no AI system currently uses llms.txt. Google’s own optimisation guidance states that Google Search ignores the files.
Publishing one is cheap and harmless. Treating it as an LLM optimisation strategy is not. The hours belong in your attribute schema.
What is genuinely unsettled
Three things nobody outside these companies actually knows, and you should be suspicious of anyone who claims otherwise.
Ranking weights. OpenAI says merchants are ranked on factors including availability, price, quality and whether they are the maker or primary seller. It says the list is expected to evolve. Google publishes no weighting at all. There is no formula.
Chunking behaviour. How a given system splits a product page, and how much surrounding context travels with a fragment, is not published by any of them. The advice above (identifiers near specs, real tables, self-contained blocks) is a hedge against every plausible implementation, not knowledge of a specific one.
Measurement. Search Console now has a generative AI performance report and Merchant Center has AI performance insights in pilot. Both are partial. Attribution from an AI answer to a sale is thin and will stay thin for a while. Plan the data work on the basis that it also improves search, feeds and marketplaces, because it does.
Where to start on a real catalogue
Pick one category. Not the whole estate.
- Fix identifiers and brand entities for that category. Nothing else works until resolution works.
- Extend the attribute schema against the top fifty real queries. Type everything, one unit per attribute.
- Enrich against the extended schema, which is the expensive part and the one worth doing properly.
- Emit a server-rendered spec table with the identifier adjacent to it.
- Add Product and, where variants exist, ProductGroup markup that mirrors the visible content exactly.
- Reconcile the feed against the page so price, stock and specification agree.
Then measure the category against a control category and give it a quarter. That sequence is the one we use on product content enrichment programmes. The ordering is what keeps the cost sane.
Key takeaways
- LLM optimisation for catalogues is a data model problem. Style advice written for blog posts does not transfer.
- Retrieval works on fragments, so every specification block needs to identify its own product.
- Identifiers and brand entities come first. Resolution failure makes everything downstream irrelevant.
- If a filterable concept is not an attribute with a typed value and a unit, it cannot be checked.
- Structured data is not required for Google’s AI features, but it is required for merchant listings and it enforces useful discipline.
- Most AI crawlers do not execute JavaScript, on the published evidence.
- llms.txt is not doing anything. The measured request volume is close to zero.
If you want this done against a live catalogue rather than a theory, we scope it as a single-category pilot. You get a measurable before and after. A thirty minute call is enough to work out whether your constraint is the schema, the enrichment or the platform. Get in touch, or read where applied AI tends to pay back first on a large catalogue.