Blog · By industry

AEO for ecommerce, when the product is the answer

Published 29 April 2026 · Updated 12 October 2026 · 7 min read

AEO for ecommerce, when the product is the answer
Photograph: Giorgio Trovato / unsplash

The short answer: AEO for ecommerce is the work of getting individual products, not just your brand, into the answers assistants write for shopping questions. It runs on a different supply chain from editorial AEO: a structured product feed and product markup feed the shopping surfaces, while reviews and roundups feed the prose around them. Fix the feed first. A beautiful category page will not rescue a product that has no price, no availability and no stable identifier.

Most teams arrive at this having already done content work, and are surprised that it moves nothing. The reason is structural. On a shopping question, the assistant is not summarising your essay. It is reading a row.

The catalogue is the content

Look at what the two published shopping contracts ask a merchant for: a product name, a brand, a price, a stock state, an image, optionally a rating. Each of those is a field in a feed or a property in markup. None of them are prose. We are describing the two contracts below, not every shopping surface, because these are the two that publish their rules.

OpenAI's published product feed specification makes the shape explicit for its own commerce surface. Nine fields are required for every item: a stable item_id, title, description, url, brand, seller_name, image_url, availability and price. The spec asks you to aim for at most 150 characters of title and 5,000 of description. It is blunt about what inclusion buys you, in its own words: eligibility does not guarantee display. You are buying the right to be considered on that surface, and the other engines publish no equivalent contract we can quote.

Google's merchant listing documentation describes the same economics in its own vocabulary. name, image and offers are required on the Product; inside the Offer, price and a three-letter ISO 4217 priceCurrency are required, with availability, itemCondition, priceValidUntil, shippingDetails and hasMerchantReturnPolicy recommended. There is a line in there worth taping to a monitor: Google warns that dynamically generated markup can make its Shopping crawls less frequent and less reliable, which it flags as a problem for fast-changing fields like price and availability. That warning is Google's, about Google's crawls. We have not seen another engine document the same thing, which is not evidence that the others are unaffected.

Where ecommerce diverges from everything else

This is the part that makes a general AEO playbook misfire. The split is worth reading against AEO by industry: where the work differs, because the same three layers sit underneath every sector and the weight on each one moves.

Editorial AEO is mostly an identity and corroboration problem. Ecommerce AEO is mostly a data freshness problem with an identity problem attached. A regulated sector like healthcare pushes the weight back towards provenance and claim accuracy. Retail pushes it towards the boring machinery: a GTIN that matches across your site, your feed and the marketplace listing somebody else made for the same item.

Scale makes it worse in a specific way. A publisher has a page count a human has actually read. A mid-sized retailer has a catalogue nobody has read since the PIM generated it. The failure mode is not a bad page. It is a single field error in a template, replicated across every item the template touches, which shows up as an even drop rather than an outage and so reads as normal on the dashboards most teams watch.

Three failure modes we keep finding

These are the three patterns that recur in our own audit work on retail catalogues. We have not counted them across a defined sample, so read this as the shape of what we meet rather than a frequency we can quote. Each one is described below in terms of what the published documentation says, which is the part you can check without us.

Variant collapse. A parent product carries the markup and the twelve children carry nothing, or each child carries identical markup with the parent's price. Google publishes a separate ProductGroup and Product specification for variants, so on Google's surfaces an unresolved variant is a documented modelling failure rather than a guess on our part. What happens next, whether a rival gets named instead, is our inference from watching answers, not something we have found documented.

Stale availability. The feed says in stock, the page says sold out, and which one an answer repeats depends on what it last fetched. This is not a rounding error. OpenAI's feed spec states plainly that sale windows, expiration dates and availability dates do not schedule price or availability changes for you, so in that contract an item that sold out on Friday keeps advertising itself until an update is pushed.

Identifier drift. The same shoe is SKU-4471 on your site, a different id in the feed, and an unbranded title on a reseller's page. Nothing links them, so no corroboration accrues to you. The reseller gets quoted instead.

A check a merchandising team can run this week

Take twenty products that matter commercially, not the twenty that are easy. For each one, in this order:

  1. Fetch the live product URL with JavaScript disabled, or just curl it, and search the

    2. returned HTML for the price string. If the price is not in the raw response, note it.

  2. Pull the same item from your feed export. Compare price, availability and the

    3. identifier against what the page returned.

  3. Search for the product's exact name plus your brand, and see what a third party says

    4. the price and stock are.

  4. Ask two assistants a buying question that your product should win, phrased the way a

    5. customer phrases it, and record whether you were named, whether the facts attached were true, and which sources were cited.

Run each prompt more than once. On the engines we test, repeated identical prompts return different answers, so a single run is an anecdote, not a measurement. Four of twenty failing step one is a sprint, not a strategy meeting. If you want a structured version of this with more coverage, the self-check lists ten tests that need no tooling at all.

Who actually fixes this

Almost none of the work above belongs to the content team, and that is the organisational trap. Feed accuracy lives with merchandising or the PIM owner. Server-side rendering of price lives with engineering. Review volume lives with CRM. The person who was handed AEO usually controls none of them, which is why the question of who owns AEO inside a company turns into a budget argument about six weeks in.

The practical move is to split the work by system rather than by surface, and to stop arguing about vocabulary. Whether your deck says AEO, GEO or SEO matters far less than whether somebody has a ticket open against the feed.

Honest limits

This post is built on two vendors' documentation plus our own audit experience, and a careful reader should hold it to that. The field requirements are OpenAI's and Google's, quoted from their current pages; we do not know what the engines without a published feed or markup contract do with a catalogue, and we cannot see inside them to find out.

We cannot cleanly attribute a product mention in an assistant answer to a sale, because the referrers we see in client logs rarely identify the surface and the buyer often returns later through a branded search. A precise revenue figure from AI shopping visibility is therefore a model, not a measurement.

We also do not know how each engine weights feed data against on-page markup against third-party reviews, because we have found no published weights and the behaviour moves between runs. Our reason for putting the feed first is the documentation, not a measured effect size: OpenAI's spec rejects rows with missing or unrecognised required values, so an item that fails those checks cannot be considered on that surface at all. We have not run a controlled before-and-after test that isolates the feed from everything else a client changed at the same time.

FAQ

Do I need a product feed, or is structured data enough? Both, for different surfaces. Markup serves the general web answer path. A feed serves OpenAI's commerce path, which draws on an uploaded feed rather than on your markup. We cannot tell you what the engines with no published contract use. Treat markup and feed as two inputs that must agree.

Why does the engine quote a reseller's price instead of mine? Usually because the reseller's data is cleaner or fresher, or because nothing ties their listing to your identifier. Check whether your price is in the server-rendered HTML before blaming the engine.

Does more review volume help? It helps the prose around the product, which is where buying advice gets written, and ratings are carried in both contracts: star_rating and review_count are optional fields in OpenAI's feed spec, and aggregateRating is recommended in Google's merchant listing markup. Neither is required, and neither rescues a product the engine cannot price.

How many products should we fix first? Start with the items that carry the margin, confirm the pattern on twenty, then fix the template or the feed mapping that caused it. These errors are almost never per-product.

Sources

All four pages were opened and checked against the sentences that cite them on 12 October 2026.

Related reading

AEO by industry: where the work differsAEO for healthcare, with the compliance in mindAEO vs GEO vs SEO: what the three terms actually meanWho owns AEO inside a companyAEO inside an enterprise, where approval takes longerAEO for fintech