Answer engine optimization for a product catalog

What AEO is once you remove the sales pitch

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.

Be clear about what is *not* required, because a lot 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 catalog it is mostly not writing.

A catalog is not a blog, and the tactics do not transfer

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 catalog 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 catalog 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.

Structured data, done for the reasons that hold up

Google has said markup is not a requirement for AI features, and you should still do it properly: for rich results in classic search, for Merchant experiences, and because marking a fact up forces somebody to decide what the fact 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 provide the commerce-specific detail, such as 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 effectively 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 organization level rather than repeating them on every offer, overriding at offer level only where a product differs.

On reviews, the position is simple: 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 optimization, and the downside is losing rich results across the whole site.

Variants are where Shopify catalogs get it wrong

A store selling one coat in four colors 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 you should implement it 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 catalog in the terms a machine asks about it: which colors 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 facts have to be text, and they have to agree

This is the least interesting section and the one with the most value in it. Across audits, the same four failures recur, and each one makes an attribute unretrievable regardless of how good the rest of the page is.

• Specifications rendered as an image. A photographed size chart, a dimensions diagram, a PDF datasheet. A human can read it; extraction cannot. Put the same numbers in a table and keep the image if it helps.
• Attributes injected after render. Delivery windows that arrive from an app, stock messaging from a widget, specification tabs populated by a script. If the fact is not in the served HTML, treat it as absent.
• Inconsistent naming. One product name, one spelling, one model number, on your site and everywhere you supply data to. A retailer listing that contradicts yours gets resolved by a machine picking one, and it may not pick yours.
• Attributes trapped in prose. “Made from a beautifully soft brushed cotton” is marketing; “Material: 100% brushed cotton” is a fact a system can lift. Have both: the prose sells, the field answers.

On Shopify, this is a metafield and template question

The mechanism for catalog-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 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.

The pages that actually get cited

The uncomfortable part is that 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 catalog does not generate them.

The short list, in the order we would build them: a selection guide per category that 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, done fairly; and a returns and delivery page that states the 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, useful introduction above the grid, is the highest-impact template change available to a catalog.

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.

The constraint that decides whether any of this happens

Everything above is a publishing program, and publishing programs 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 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 short of.

What we would not spend on

Generated product descriptions at scale. Four thousand fluent, near-identical paragraphs add length without adding a single fact, and they make your catalog 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.

Questions this raises

Read next

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