AI search visibility for a retail brand is whether individual products, not just the brand, reach the answers assistants write for shopping questions. That runs on a different supply chain from everything else on this site.
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. Every one of those is a field in a feed or a property in markup. None of them are prose. OpenAI's published product feed specification requires nine fields for every item, a stable item_id, title, description, url, brand, seller_name, image_url, availability and price, and it is blunt about what inclusion buys you: eligibility does not guarantee display. Google's merchant listing documentation requires name, image and offers on the Product, with price and a three-letter ISO 4217 priceCurrency required inside the Offer.
So the order of work inverts. Structured feed and product markup feed the shopping surfaces; reviews and roundups feed the prose around them. Fix the data first. A beautifully written category page will not rescue a product that carries no price, no availability and no stable identifier. Most teams arrive here having already done content work and are surprised that it moves nothing, because on a shopping question the assistant is not summarising their essay.
Those are the two contracts that publish their rules. The other shopping surfaces publish no equivalent we can quote, so treat the field lists above as two documented contracts rather than a standard the whole category follows.
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 an opinion. A buyer asking for one size, one colour or one capacity is asking about a child that does not exist as a thing a machine can price.
Google warns that dynamically generated markup can make its Shopping crawls less frequent and less reliable, and flags that as a problem specifically 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. The practical version: if the price only exists once a script has run, assume the row a shopping surface holds for you is older than your pricing page.
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, repeated 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. This is why the retail version of the work is a data audit with an identity problem attached, not a writing exercise.
A GTIN on your site, a different one in your feed, and a third on the marketplace listing somebody else made for the same item. Nothing about that is visible in your analytics, and it is the quiet reason a shopping answer describes your product under someone else's listing. Stock and price make it worse: an answer assembled from a stale row keeps selling an item you no longer have, in a currency you no longer price it in.
That list is not assembled from reading. We work with D2C brands in hair care and in skin care, and the method on this page has been applied inside their catalogues. We do not name a client and we do not publish a client result: none of them has agreed to be named, and a figure you cannot check is worth less than work you can read, which is what the sample audit and the posts below are for.
Ten posts on catalogues, feeds and the surfaces that read them.
Everything else is in the blog index.
Open Search Console, go to Shopping, then Merchant listings, and read the invalid count. Every invalid item is a product an engine cannot price or compare. Reading the count takes a minute. Working out which field breaks which product is the week.
The ten-point self-check is free and asks for no email. Two of its ten are retail-shaped: whether your product feed validates, and whether your prices exist as text rather than inside an image or a script. Both are answerable today, on your own site.
When you want the catalogue measured rather than sampled, the audit runs 45 prompts across five engines, with retrieval on and retrieval off, and attaches the evidence to each finding. It is $500 and it lands within 7 working days. The only deliverable is the report. The sample audit shows what is in it before you decide, and the contact form is the way in.
Nobody can promise a shopping surface will carry a product, and the feed specification above says so in its own words. What an audit gives you is the list of items a machine currently cannot read, and why.