Answer engine optimisation for a product catalogue

An answer engine — Google’s AI features, ChatGPT, Perplexity, an assistant inside a browser — resolves a question by retrieving sources and composing a reply from them. Your influence is limited to a narrow and entirely unglamorous thing: whether a machine can reach your page, find the fact on it, and lift a sentence that stands on its own.

It is worth being clear about what is *not* required, because a large amount is being sold on the premise that it is. Google’s documentation on AI features in Search states that “you don’t need to create new machine readable files, AI text files, or markup to appear in these features. There’s also no special schema.org structured data that you need to add.” The stated eligibility bar is the ordinary one — a page must be indexed and eligible to be shown in Google Search with a snippet — followed by “there are no additional technical requirements”. If a proposal in front of you is mostly a file in your root directory and a proprietary score, it is selling the easy half of a problem that does not have an easy half.

What that leaves is real work, and for a catalogue it is mostly not writing.

Most AEO advice is written for sites with fifty pages. Answer the question in the first paragraph, use tables, add an FAQ block — all correct, and all unworkable as instructions when you have four thousand products and two people in merchandising.

At catalogue scale the unit of work changes. You are not writing an answer per product; you are making sure that for every product, the attributes a buyer asks about exist in a structured field, render as text, and are described the same way everywhere. Done properly, that produces four thousand answerable pages from one piece of work. Done badly — which is the norm — the same fact appears as “100% cotton” on one product, “Cotton (100%)” on another, and as part of a photographed spec sheet on a third.

This is why catalogue AEO is a data project before it is a content project. The writing you eventually do sits on top of the data, and if the data underneath contradicts itself, the writing inherits the contradiction.

Google has said markup is not a requirement for AI features, and it is still worth doing properly — for rich results in classic search, for Merchant experiences, and because marking a fact up forces somebody to decide what the fact actually is. Be precise about what is required, though, because most Shopify stores ship a partial implementation and assume it is complete.

Google distinguishes two classes. Product snippets are for pages where the product cannot be bought directly, and support things like pros and cons on an editorial review page. Merchant listings are for purchasable products and unlock the commerce-specific detail — apparel sizing, shipping and returns.

For a merchant listing, the required properties are name, image and offers on the product, with price and priceCurrency inside the offer, where the price must be greater than zero. Recommended, and worth treating as required if you sell anything comparable: description, brand, the identifiers sku, mpn and gtin, and at the offer level availability, url, itemCondition, shippingDetails and hasMerchantReturnPolicy. Google also recommends putting shipping and return policies at organisation level rather than repeating them on every offer, overriding at offer level only where a product genuinely differs.

On reviews, the honest position: aggregateRating and review are recommended properties and they are worth having *when the reviews are real, visible on the page, and collected from actual customers*. Marking up ratings that a visitor cannot see is a policy violation dressed as an optimisation, and the downside is losing rich results across the whole site.

A store selling one coat in four colours and five sizes has twenty things a customer might ask about and usually one page describing all of them vaguely. Google publishes a specific structure for this and it is worth implementing properly.

The parent is a ProductGroup carrying the overarching product name, a productGroupID — the parent SKU — and variesBy, which names the axes of variation using schema.org URLs such as https://schema.org/color and https://schema.org/size. Individual variants are nested in hasVariant as full Product objects, or reference the parent with isVariantOf. Each variant needs its own unique identifier, its own color, size, image and offers with that variant’s price and availability.

The requirement that catches Shopify stores is the URL one. Every variant must be preselectable at a distinct, crawlable URL — on a single-page implementation that means query parameters such as ?size=small&color=green, with one canonical URL for the group itself without variant selectors. A theme that changes the displayed variant purely in JavaScript, with no addressable URL per variant, cannot satisfy this no matter what JSON-LD it emits.

Get this right and you have described your catalogue in the terms a machine asks about it — which colours exist, what each costs, which are in stock. Get it wrong and you have a beautifully marked-up product whose twenty real options are invisible.

The mechanism for catalogue-scale attributes on Shopify is metafields, and the discipline is to define the set once rather than letting it grow per product. Decide the ten or fifteen attributes that matter in your category — material, dimensions, weight, care, compatibility, certification, whatever your customers actually ask — define them as metafield definitions with proper types, and render them from the template as a specification table on every product that has them.

Two benefits fall out. The table is consistent, machine-readable text on every page for free. And your merchandising team is now filling in fields rather than writing paragraphs, which is both faster and far more likely to happen.

The same discipline pays off in your product feed. If the attributes are structured, they can be syndicated to marketplaces and comparison sites accurately, and the consistency between your site and those listings is exactly what stops a retrieval system finding two contradictory versions of your product.

Here is the uncomfortable part. A question like “which of these is best for a beginner” or “will this fit a 2019 model” is not answered by any product page, because a product page argues for one product. The pages that get retrieved and quoted are the ones that compare, select and explain — and a catalogue does not generate them.

The short list, in the order we would build them: a selection guide per category that genuinely helps someone choose, including talking them towards the cheaper option where that is right; a compatibility or sizing page that answers the fit question in a table; a comparison between your own ranges, honestly done; and a returns and delivery page that states the actual terms in plain numbers rather than legal prose.

Collection pages deserve a mention of their own, because most stores ship them as a bare grid. A collection page matching how people actually search — the category term, not the product name — with a short, genuinely useful introduction above the grid, is the highest-leverage template change available to a catalogue.

Each of these is one page, written once, serving thousands of products. That ratio is what makes them worth the editorial effort that per-product content never justifies.

Everything above is a publishing programme, and publishing programmes die on the same thing: a new page takes a developer two weeks. If answering a customer question requires a ticket, a sprint and a deploy, the questions go unanswered and somebody else in your category answers them.

This is why a composable section library tends to be the piece of infrastructure that actually moves AEO for a store. Merchandisers assembling a proper answer page — comparison table, numbered steps, FAQ, the lot — on a Tuesday afternoon is worth more across a year than any markup you could add. The tactics are cheap and widely published; the ability to execute them repeatedly is what you are actually short of.

Generated product descriptions at scale. Four thousand fluent, near-identical paragraphs add length without adding a single fact, and they make your catalogue read like everyone else’s because it was produced the same way. Spend the same effort on filling the attribute fields.

A single AI visibility score. Ask how it is derived. If the answer is a proprietary model of a system nobody has access to, you are buying a reassuring chart rather than an observation.

Markup as a substitute for content. Schema describes what is on the page. It does not create an answer that is not there, and Google has said in writing that no special markup gets you into its AI features.

What to do instead for measurement: pick the fifteen questions a real buyer in your category asks, run them across the assistants your customers use, and record the answers and the cited sources — the same fifteen, monthly, by the same method. It is crude, and it is the only instrument with real signal in it. It also catches the thing that matters most: a factual error about your products repeating across systems.

• Shopify section library
• What AI assistants say about your brand, and why
• Collection pages are your best SEO asset