Practical guide

How AI shopping agents read your product data

A practical guide to product pages, feeds, and request evidence: what to check, what a fetch proves, and what remains outside your store’s view.

A product can have a clear description on your storefront and conflicting price or stock information elsewhere. For a merchant, the useful starting point is not “Are we AI-ready?” It is “Which version of this product can a shopping service access—and does it match what a customer can buy?”

How product information reaches AI shopping agents

An AI shopping agent helps carry out a shopper’s task, such as finding products, comparing options, or assisting with a purchase. Product information can reach these systems through more than one route. OpenAI, for example, documents both first-party and third-party product metadata in ChatGPT shopping results.[1]

Product pages. Page text and structured markup describe the item on a particular URL. JSON-LD is one way to express product details as named fields. Google documents how product-page markup and Merchant Center feeds can complement each other; it does not define one universal source priority for every AI agent.[2]

Feeds and commerce integrations. Merchants can supply product records through a platform’s supported feed or API. OpenAI’s product-upload reference, for example, specifies stable item identifiers, prices, availability, and variant information. Use the receiving platform’s current requirements rather than assuming one feed format fits every service.[3]

Information already held elsewhere. A service may use product information supplied by another provider rather than fetch your page for that interaction. OpenAI also notes that merchant price and shipping updates can take time to appear. Consequently, a product appearing in an AI answer does not necessarily produce a new request to your domain.[1]

These routes can coexist. Keep them separate when evaluating your catalog and your traffic.

Four questions to check for each product

Use these as a merchant review framework, not a claim about an AI model’s hidden decision process.

Which item is this? Identify the specific variant, not just the parent product. A color, size, or capacity selection should not silently change which item the record describes.

What is its current price? Include the currency and distinguish an ordinary purchase price from a member price, subscription, bundle, or conditional promotion.

Is this variant available? Check the selected item, not the availability of another variant. Stock status alone does not answer every shipping-destination question.

What are the purchase terms? Make delivery conditions, shipping costs, returns, and relevant product limitations clear. Google’s product documentation covers variant relationships, offers, and shipping and return information; its feed specification requires availability to agree with the landing and checkout pages.[4][5][6]

Worked example: one variant, consistent facts

Illustrative example only. The brand, product, price, stock state, and URLs below are fictional. This is not a Cartograph observation or a live merchant listing.

Suppose the selected item is a 750 mL slate bottle, SKU FLASK-750-SLATE, priced at 34.00 USD and in stock. The product page should state those facts for that selection. A trimmed JSON-LD example would look like this:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Field Flask — 750 mL, Slate",
  "sku": "FLASK-750-SLATE",
  "inProductGroupWithID": "FIELD-FLASK",
  "brand": {
    "@type": "Brand",
    "name": "Example Outdoor"
  },
  "description": "A 750 mL stainless-steel bottle in slate.",
  "size": "750 mL",
  "color": "Slate",
  "image": "https://example.com/images/flask-750-slate.jpg",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/flask-750-slate",
    "price": "34.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

The fields make the item, offer, and variant explicit. This example is not a complete merchant integration: actual products may need additional identifiers, variant-group markup, policies, and platform-specific fields. Do not invent a GTIN or manufacturer identifier to fill a gap.[3][4][5]

In a Google Merchant Center feed, the corresponding selected values would include id=FLASK-750-SLATE, item_group_id=FIELD-FLASK, price=34.00 USD, and availability=in_stock, with the link opening the same variant. These are field mappings, not an upload-ready feed.[6]

Now consider two faults. The page says 34.00 USD, but the feed still says 32.00 USD. Or the page describes the 750 mL bottle while the feed points to a sold-out 500 mL variant. Those are concrete inconsistencies to investigate. They are not, by themselves, proof that an AI service rejected the product or that a sale was lost.

Check one product before expanding the audit

Inspect both the response and the rendered page. Check whether the selected product’s identity, price, and availability are in the initial HTML or appear only after JavaScript runs. Google recommends placing Product markup in the initial HTML for shopping results and warns that dynamically generated markup can make Shopping crawls less reliable. That is Google-specific guidance—not a claim that every agent is unable to run JavaScript.[4]

Compare the same variant across sources. Match the page, its structured data, the submitted feed, and any platform validation result. Record the check time, currency, selected options, and each mismatch. Use Google’s Rich Results Test for supported page markup and the receiving platform’s feed checks for its records; passing one does not validate the other.[5][6]

Follow a legitimate product update. At the next planned price or stock change, check when the page, markup, and feed reflect it. Keep the product-update time, feed-publication time, and any observed fetch time separate. An updated feed is not evidence that an external platform has already refreshed its copy.[1]

Continue with the AI agent readiness checklist for ecommerce teams for the broader storefront and checkout review.

What a product fetch leaves behind—and what it does not

When a request reaches a system you can observe, a privacy-minimized evidence record can identify the time, product or feed path, response status, and any supported actor-verification result. A product or feed version can add context when there is a reliable association between that version and the response.

The observation point matters. A CDN can serve a cached response without a new request reaching the origin server. Cloudflare’s cache documentation distinguishes cache hits from origin-served responses. Origin logs alone therefore cannot establish complete coverage of requests to a cached storefront.[7]

A claimed identity is not a verified identity. A user-agent name is a claim. Verification must follow the relevant provider’s published method; Google, for example, documents IP-range checks and reverse DNS followed by a forward lookup. Verification identifies the actor supported by that evidence—not the shopper’s intent or an unseen service behind an intermediary.[8]

A request is not a recommendation. In a hypothetical case, a record might establish that a verified service requested a catalog feed at 14:02 UTC and that your server recorded a successful response for feed version 17. It would not establish which item the service selected, which fields it used, or what a model recommended. Fetching a whole feed is not proof that every product was individually evaluated.

Likewise, a request that does not execute the page’s JavaScript will not trigger that page’s JavaScript analytics tag. Missing pageviews do not establish missing requests. Missing agent evidence does not prove human traffic.

Keep the evidence limited to what the question requires. Do not collect form values, passwords, payment data, cookies, private messages, or full query strings to investigate product access.

For provider-specific references, use the AI crawler and agent directory. For the broader evidence boundary, read the agent-commerce evidence guide.

Common questions

Does every AI-related request mean someone is shopping?

No. OpenAI distinguishes search crawling, model-development crawling, and user-triggered fetches. A verified crawler request establishes that request—not a buyer, an active shopping session, or a purchase intention.[9]

Do I need a separate AI product feed?

Not as a universal rule. Requirements depend on the receiving service and integration. Check the platform’s current feed contract before creating another export or assuming your existing one is accepted unchanged.[3]

Does correct structured data guarantee an AI recommendation?

No. Google says its AI Overviews and AI Mode do not require special AI markup; eligibility does not guarantee inclusion. OpenAI likewise states that product-feed search eligibility does not guarantee display. Accurate product data is worth maintaining without turning it into a ranking promise.[10][3]

Where Cartograph fits

Cartograph is being built as the evidence layer for agent commerce: merchant-side observability of AI-agent traffic, bot/agent ambiguity, and commerce events, with the limits of each finding made explicit.

Cartograph does not claim to know what an external model concluded, preferred, or recommended off-property. Absence of agent evidence does not prove human traffic.

Request early access to discuss your store’s evidence needs and potential fit. Cartograph is still in development; an early-access request is not an instant scan or a production integration.

Related: What is agentic commerce? · For retail teams

Sources

  1. OpenAI, Shopping with ChatGPT Search — first- and third-party product data and delays after merchant updates. https://help.openai.com/en/articles/11128490-shopping-with-chatgpt-search
  2. Google Search Central, Introduction to Product structured data — product-page markup and Merchant Center feeds. https://developers.google.com/search/docs/appearance/structured-data/product
  3. OpenAI, Products — File Upload — item identity, variants, fields, identifier cautions and eligibility limits. https://developers.openai.com/commerce/specs/file-upload/products
  4. Google Search Central, Merchant listing structured data — Product/Offer fields, initial-HTML recommendation and JavaScript caution. https://developers.google.com/search/docs/appearance/structured-data/merchant-listing
  5. Google Search Central, Product variant structured data — product groups, variant URLs and validation. https://developers.google.com/search/docs/appearance/structured-data/product-variants
  6. Google Merchant Center, Product data specification — feed fields, availability consistency and submission requirements. https://support.google.com/merchants/answer/7052112?hl=en
  7. Cloudflare, Cloudflare cache responses — cache hits, misses and origin responses. https://developers.cloudflare.com/cache/concepts/cache-responses/
  8. Google Crawling Infrastructure, Verify requests from Google crawlers and fetchers — IP ranges and reverse-plus-forward DNS. https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests
  9. OpenAI, Overview of OpenAI Crawlers — search, model-development and user-triggered requests. https://developers.openai.com/api/docs/bots
  10. Google Search Central, AI features and your website — no special AI markup and eligibility/inclusion distinction. https://developers.google.com/search/docs/appearance/ai-features

Provider documentation checked on 2026-09-11.