Most ecommerce teams treat AI visibility as a content problem. They write longer descriptions, add FAQ blocks, and hope a chatbot picks them up. That work is not wasted, but it is not where the leverage is. When an AI system answers a shopping question, it is usually assembling an answer from product attributes it can read, compare and trust: what the item is, what it costs, whether it is in stock, what it fits, and what happens if the buyer wants to send it back.
Clever copy is hard to compare. Specs are easy. If your product data is thin, inconsistent, or locked inside images and PDFs, no amount of brand voice will fix the gap.
Why product data decides AI shopping visibility
AI search results for commercial queries tend to be structured answers: a short list, a comparison, or a recommendation with reasons. To produce that, the system needs facts it can extract from your pages without guessing.
Consider what happens when someone asks an AI assistant for "a waterproof hiking boot under $150 that ships in two days." The answer requires at least four data points: category, a waterproof attribute, a price, and a delivery estimate. If your product page states the price in a table image, mentions waterproofing only in marketing prose, and buries shipping terms in a linked policy page, you are asking the system to do work it may not do.
This is the practical difference between ecommerce AI search and classic SEO. Rankings reward relevance and authority signals across a page. AI answers reward extractable, attributable facts. Both matter, but only one of them is under your direct control as a data problem.
The five data blocks that do the heavy lifting
1. Specifications in a consistent format
Every product in a category should expose the same attributes, in the same order, using the same units and vocabulary. If one boot lists "weight: 1 lb 2 oz" and another lists "weight: 510 g," you have made comparison harder for both a human and a machine.
Pick a canonical attribute set per category and enforce it. Size, material, dimensions, weight, compatibility, power requirements, capacity, color, and model number are the usual candidates. Where a spec varies by variant, state it per variant rather than in a single paragraph.
2. Availability that reflects reality
Availability is one of the most common reasons an AI answer changes. If your page says "in stock" in prose but the structured data says something else, or says nothing at all, you are creating ambiguity at exactly the moment of decision.
Keep availability in your product markup and keep it accurate. Stale availability is worse than missing availability, because it produces confident wrong answers.
3. Price and price context
List price, sale price, currency, and unit pricing where relevant. If a product is sold in multi-packs or subscriptions, say so explicitly. Ambiguous pricing is a frequent source of mismatched answers, and the customer blames you, not the model.
4. Return policy clarity, on the product page
The return window, who pays return shipping, condition requirements, and any category exclusions should be readable on the product page itself, not only in a linked policy. This is not a legal formality. Return terms are a decision input for a large share of online purchases, and they are exactly the kind of concrete fact an AI answer can carry.
Write it in plain sentences, then also expose it in structured data where the schema supports it.
5. Category buying guides that map to real questions
A buying guide earns its place when it explains tradeoffs between attributes: which material suits cold weather, why a higher weight rating matters for one use case and not another. That is different from a listicle of your own SKUs.
The useful structure is: what the attribute means, when it matters, when it does not, and which of your products fit each profile. This gives an AI system something to quote that is not just a price.
Product schema: what to mark up and what to skip
Product structured data is the machine-readable layer of everything above. The core properties worth getting right:
| Property | What it should contain |
|---|---|
| name | The product name as sold, without keyword stuffing |
| description | A factual summary, not marketing copy |
| sku / mpn / gtin | Whatever identifiers you actually have |
| brand | The brand entity, consistent across the catalog |
| offers | Price, currency, availability, seller, and price validity where known |
| aggregateRating | Only if you display real, collected reviews |
| additionalProperty | Category-specific specs that standard properties do not cover |
Two cautions. First, do not mark up data you do not show on the page. Second, do not invent review counts or ratings to fill a field. Fabricated markup is a fast way to lose trust with both search systems and customers.
If you are starting from nothing, our free schema markup generator builds JSON-LD for Organization, LocalBusiness, Product or FAQPage from a short form. It is a reasonable way to get a valid Product block onto a page before you invest in templating it across the catalog.
Crawler settings: the part people get wrong
Structured data only helps if the right crawlers can reach it. The major AI vendors document distinct bots with distinct jobs, and blocking one is not the same as blocking another.
For OpenAI, OAI-SearchBot surfaces websites in ChatGPT search, and sites opted out of it are not shown in ChatGPT search answers. GPTBot is a separate crawler used to improve foundation models, and blocking it does not affect ChatGPT search. ChatGPT-User handles user-initiated actions in ChatGPT and custom GPTs; because a user triggers it, robots.txt rules may not apply, and it is not used to decide whether content appears in search. OpenAI notes robots.txt changes can take about 24 hours.
Anthropic documents ClaudeBot for training, Claude-User for fetching pages when a user asks Claude a question, and Claude-SearchBot for indexing content to improve search results. Anthropic says its bots honor robots.txt, support Crawl-delay, and publishes its IP ranges.
Perplexity documents PerplexityBot, which surfaces and links sites in Perplexity search results and is not used to crawl content for foundation models, and Perplexity-User, which fetches pages for user questions and generally ignores robots.txt because the user requested it. Robots.txt changes may take up to 24 hours.
Google-Extended controls whether content is used to train future Gemini models and for grounding in Gemini apps and the Vertex AI Gemini API. It does not affect inclusion in Google Search and is not a ranking signal. AI Overviews are part of Google Search, so they are governed by normal Googlebot crawling and indexing.
One technical note that trips people up: under RFC 9309, a crawler follows the most specific group that names it and ignores the * group in that case. Within a group, the longest matching rule wins. And robots.txt expresses intent, not access control.
The practical takeaway: decide per crawler, not with a blanket block. A store that blocks everything "AI" may be opting out of search surfaces it wanted.
A workable sequence for the next few weeks
Start with your top twenty revenue products. For each, check four things: are the specs complete and in consistent units, is availability accurate, is the return policy stated on the page, and is there valid Product markup matching what is visible. Fix the gaps in that order.
Then pick one category and build a buying guide organized around attribute tradeoffs rather than product rankings. Link it from each product in that category.
After that, review robots.txt against the bot list above. Write down which crawlers you are allowing and why, so the decision survives your next site migration.
If you sell to businesses as well as consumers, the same logic applies to how your company is described; the SaaS version of this problem covers entity clarity and comparison pages.
Where to start today
Open your three best-selling product pages in a private browser window and read only the facts: price, availability, specs, returns. If any of those four is missing, vague, or only present in an image, fix that page first, then templating the fix across the catalog becomes a much easier conversation with your engineering team.