AI shopping agents do not browse the way people do. When a shopper asks ChatGPT, Gemini, Perplexity or Copilot for “a waterproof trail running shoe under $140 that ships by Friday,” the agent does not scroll a category page and squint at badges. It queries a structured catalog, filters on a handful of machine-readable fields, and discards anything it cannot verify. That last step is the one most retailers underestimate. A product feed for AI shopping agents is not judged on how persuasive the copy is; it is judged on whether the agent can confirm the identifier, the price, the stock state, the delivery promise and the return terms without ambiguity. Products that fail any of those checks are not ranked lower. They are simply absent from the answer.
This article walks through the fields that decide inclusion, why each one carries the weight it does, and how to audit a feed against what the major agent surfaces actually read. It draws on the published feed specifications from OpenAI’s Agentic Commerce Protocol, Google’s Merchant Center product data specification, GS1’s identifier standards and schema.org, and on what merchants and platform partners have reported since agent-driven checkout moved from demo to live traffic in late 2025. Where a platform has not published a hard tolerance, this piece says so rather than inventing one.
In short
- Agents filter before they rank. A product missing a verifiable GTIN, a live availability state or a price that matches the landing page is typically excluded from the candidate set entirely, not demoted within it.
- Five field groups decide inclusion: identifiers (GTIN, MPN, brand, item group), availability and price, shipping and delivery estimates, return terms, and the merchant-level trust fields (seller name, policies, checkout eligibility).
- Freshness is a field, not a nicety. OpenAI’s feed specification asks for refreshes on the order of every 15 minutes for inventory-sensitive data, and Google’s Merchant Center disapproves items whose feed price disagrees with the page. Stale feeds are invisible feeds.
- The page and the feed are cross-checked. Agents and the crawlers behind them compare merchant feed values against on-page schema.org Product and Offer markup; when the two disagree, the safe move for the agent is to drop the product.
- Most failures are boring and fixable: variant products submitted without an item group, “in stock” set as a static default, prices exported before tax or in the wrong currency, and shipping and return fields left blank because they were “optional” in a Shopping feed five years ago.
Where do AI shopping agents source product data today?
There is no single catalog that every agent reads, which is why the same product can appear in one assistant and vanish from another. As of the 2026 shopping season, four sourcing paths dominate, and a retailer’s inclusion depends on which of them it has actually connected. The agentic commerce guide for retailers covers the strategic side of this shift; this section focuses on the plumbing, because the plumbing determines what the agent can see.
Protocol feeds submitted directly to the agent platform
OpenAI’s Agentic Commerce Protocol (ACP), launched with Stripe in September 2025 and expanded through 2026, defines a product feed specification that merchants or their platforms submit so ChatGPT can surface and, where enabled, check out items directly. Shopify, Etsy and a growing list of platforms push merchant catalogs into it on the merchant’s behalf. The spec reads like a stricter cousin of the Google Shopping feed: it has required identifier fields, explicit availability enumerations, structured shipping and return objects, and merchant-level flags that control whether an item is searchable, checkout-eligible or both. Google’s Universal Commerce Protocol (UCP), announced at NRF in January 2026 with Shopify, Etsy, Wayfair, Target and Walmart among the launch partners, plays a similar role for Gemini and AI Mode, with Merchant Center as the catalog of record.
Merchant Center and marketplace catalogs the agent already trusts
For Google surfaces, the feed that has powered Shopping ads and free listings for years is the same one AI Overviews and AI Mode draw on. The attributes have not changed much; what changed is how unforgiving the consumer of that data has become. Amazon’s Rufus and its “Buy for Me” agent read Amazon’s own catalog, which means the ASIN-level data a seller maintains in Seller Central is that seller’s agent feed. Microsoft’s Copilot Merchant Program, opened in early 2026 with PayPal and Shopify as partners, ingests catalogs through those partners rather than asking each merchant for a bespoke file.
Crawled pages and on-page structured data
Perplexity and, to a lesser extent, ChatGPT’s browsing mode still fetch product pages directly when no feed is available. In that path the agent’s only structured signal is schema.org markup in the page: Product, Offer, ProductGroup, OfferShippingDetails and MerchantReturnPolicy. This is the fallback route, and it is the weakest, because crawling is slow, sampling is partial, and the agent has no guarantee that the price it read an hour ago is still current. Retailers who want stable inclusion across assistants treat the crawled path as a backstop and the protocol feed as the primary channel. The broader discipline of making retail content legible to language models is covered in the site’s explainer on what AIO means for retailers; feeds are the transactional half of that same problem.
Which fields do agents rely on most, and why?
The honest way to describe an agent’s use of feed data is as a sequence of gates followed by a ranking. The gates are binary: does the product have an identifier the agent can resolve, is it available, is the price trustworthy, can it be delivered in the window the shopper implied, and can it be returned on terms the agent is willing to represent. Only products that pass every gate reach the ranking stage, where description quality, reviews, brand affinity and merchant reputation start to matter. The table below groups the fields by the gate they serve and what typically happens when each is missing or wrong.
| Field group | Core fields | What the agent uses it for | Typical outcome when missing or wrong |
|---|---|---|---|
| Identity | GTIN, MPN, brand, item_group_id, condition | Resolving the product to a known entity, deduplicating across sellers, matching to reviews and comparison data | Exclusion from comparison answers; treated as an unverified listing |
| Availability | availability, availability_date, quantity or inventory level | Deciding whether the product can be recommended and checked out now | Excluded when out of stock or unknown; preorder handled only if date is present |
| Price | price, sale_price, sale_price_effective_date, currency, unit pricing | Budget filters, “best value” reasoning, checkout total | Disapproved or dropped on mismatch with the landing page |
| Delivery | shipping (cost, region, service), min and max handling and transit time, ships_from | “Arrives by” questions, total-cost comparisons, region eligibility | Excluded from any deadline-based query; cannot be offered for checkout |
| Returns | return policy reference, return window, return fee, return method | Risk framing for the shopper, eligibility for instant checkout | Excluded from checkout-eligible results on some platforms; ranked below peers |
| Merchant trust | seller name, seller URL, privacy policy, terms of service, enable_search, enable_checkout | Attribution in the answer, legal disclosure at checkout, opt-in control | Feed rejected at ingestion or items hidden from checkout |
| Content | title, description, image_link, additional images, product category, attributes (color, size, material) | Semantic matching to the shopper’s request, ranking within candidates | Product passes gates but ranks poorly; weak or generic matches |
Two observations follow from that table. First, the content fields retailers spend the most time polishing sit in the last row, after every gate has been passed. Second, the fields that cause silent exclusion are precisely the ones that were marked optional in older Shopping feed templates and that many catalog exports still leave blank. A June analysis on this site argued that product feeds would become the bottleneck of agentic commerce before the 2026 holidays; the field-level view explains why.
How do identifiers decide whether an agent can match your product?
Identity is the first gate because everything else the agent wants to do depends on knowing what the product is. A GTIN lets the agent recognize that the listing on your store, the listing on Amazon and the listing on a specialist retailer are the same item, which in turn lets it compare prices, pool reviews and answer “who has this cheapest with delivery by Thursday.” Without a resolvable identifier the product is an island, and agents are cautious about recommending islands.
GTIN: the field that unlocks comparison
GS1, the standards body that issues company prefixes, defines the Global Trade Item Number in 8, 12, 13 and 14 digit forms, corresponding to the EAN-8, UPC-A, EAN-13 and ITF-14 barcodes most retailers already print on packaging. According to GS1’s GTIN documentation, a GTIN identifies a specific trade item at a specific packaging level, so a 6-pack and a single unit carry different numbers. Google’s Merchant Center specification requires a GTIN for any product that has one assigned, and it validates the check digit and the prefix against GS1 ranges. Feeds that submit a placeholder, a reused GTIN across variants, or an internal SKU in the GTIN field are flagged, and the affected items are excluded from the surfaces that depend on identity matching.
The ACP feed specification treats GTIN the same way: it is the preferred identifier, and its presence is what allows ChatGPT to connect a merchant’s listing to its wider product knowledge. Merchants selling private-label or handmade goods that legitimately lack a GTIN can declare that rather than leaving the field empty, which is the difference between “this item has no GTIN” and “this merchant did not fill in the feed.” Brand plus MPN is the accepted fallback pair for manufactured goods.
Brand and MPN as the secondary key
Brand is required by nearly every specification, and it needs to match the brand as the manufacturer writes it, not the storefront’s house style. “Nike” and “NIKE Inc.” resolve to the same entity in most knowledge graphs, but “Nike Running” as a brand value does not, and it fragments the product across the agent’s index. MPN, the manufacturer part number, matters most in categories where GTINs are inconsistent: components, auto parts, tools and industrial supplies. When brand and MPN are both present and consistent with the manufacturer’s own catalog, agents can resolve the item even when the GTIN is missing or malformed.
Variant structure: item groups and the parent-child problem
Variants are where otherwise clean feeds break. An agent asked for “the same jacket in a medium” needs to know that the medium exists, is in stock, and belongs to the same product family as the large the shopper was looking at. Feeds express that with item_group_id in Google and ACP terms, or ProductGroup with hasVariant in schema.org. The common failures are exporting only the parent product with no sizes, exporting every size as an unrelated product with its own title, or assigning the parent’s GTIN to every child. Each of those makes the product either unshoppable at the variant level or a duplicate that the agent collapses unpredictably. The fix is structural: one row per sellable variant, each with its own GTIN, its own availability and its own price, all sharing one item_group_id, with the varying attributes (color, size, material, pattern) filled in consistently.
How accurate do availability and price need to be?
Availability and price are the fields with the tightest tolerances because they are the ones an agent will be held accountable for. If an assistant tells a shopper an item is in stock at $89 and the checkout returns “unavailable” or “$104,” the platform wears the failure, so platforms police these fields hard. The mechanisms differ, but the direction is the same: mismatches lead to exclusion, and repeated mismatches lead to merchant-level penalties.
Availability states and what each one permits
Google’s specification, documented in its product data specification, accepts four availability values: in_stock, out_of_stock, preorder and backorder, with an availability_date required for the last two. ACP uses a comparable enumeration. Agents interpret these literally. An out_of_stock item is not recommended, full stop. A preorder or backorder item can be recommended if the date is present and the shopper’s request tolerates it; without the date, it is treated as unavailable. The most damaging pattern is the static “in_stock” default, common in exports built for ad platforms that were once forgiving about it. Agents that can check out are not forgiving, and the resulting failed checkouts show up in merchant quality metrics.
Price tolerance: matching the page, not roughly matching it
Merchant Center’s price mismatch policy is the clearest published rule: if the price in the feed does not match the price on the landing page for the same region and currency, the item is disapproved until the two agree. Google’s automatic item updates can patch the feed from on-page structured data when the page carries a valid Offer, which is one of the strongest arguments for keeping schema.org markup accurate. ACP and UCP rely on the merchant feed as the checkout price source, so a mismatch there surfaces later, at the moment the order is placed, which is worse. Sale prices need their effective dates, and prices need to be submitted in the form the page shows: tax handling and currency follow the region’s convention, and the feed has to say which convention it is using.
Refresh cadence is part of the field
A price that was correct at midnight and wrong by noon is a wrong price. OpenAI’s published guidance for ACP feeds asks merchants to refresh inventory-sensitive data frequently, with roughly 15-minute intervals cited for availability and price on high-velocity catalogs; merchants running a daily feed upload are effectively submitting stale data for most of the day. Google supports scheduled fetches, API-based updates through the Merchant API, and automatic updates from the page. The right cadence depends on how fast a catalog moves, but the principle is fixed: the refresh interval needs to be shorter than the interval at which stock and price actually change. For flash sales and limited drops, that means near-real-time API updates rather than file uploads. The site’s analysis of the Content API sunset and the two data tiers it creates goes deeper on why merchants still on file-based feeds are drifting into the slower tier.
What shipping, delivery and return fields do agents read?
Shipping and returns were the “optional” section of Shopping feeds for a decade, and that legacy is now the single largest cause of exclusion from deadline-based and checkout-eligible answers. When a shopper says “I need it by Friday,” the agent needs handling time, transit time and the shipper’s service level for the shopper’s region; when the shopper says “I want to be able to send it back,” the agent needs a return window and any fees. If those fields are blank, the agent cannot answer, and it will not guess.
Shipping: cost, region, and the two time windows
Both the Google and ACP specifications express shipping as a structured object rather than a free-text line: destination country and region, price, service name, and separate minimum and maximum values for handling time and transit time. The split between handling and transit matters, because an agent computes “arrives by” as order cutoff plus handling plus transit, and it needs both to do it. Free shipping is a real value, expressed as a zero price, not an empty field. Merchants with region-specific rates submit one shipping object per region rather than a single national rate, because agents filter by the shopper’s location before they filter by anything else.
Returns: window, method, fees and the policy link
Return fields are increasingly what separates “searchable” from “checkout-eligible.” Google’s Merchant Center supports a return policy at the account level and overrides at the product level, with return window in days, return method, restocking fee and the URL of the policy itself. ACP’s specification carries equivalent fields at the item and seller level and, critically, exposes them to the shopper before checkout is confirmed. In schema.org terms, MerchantReturnPolicy covers the same ground and is the field Google’s crawler cross-checks. Retailers with strict no-returns categories, such as final sale apparel or perishables, can say so explicitly; an explicit “no returns” is a valid value that agents can represent, whereas a blank is an unknown that some agents treat as disqualifying for checkout.
Structured data on the page versus the merchant feed: which one wins?
Retailers often ask whether they can skip the feed and rely on schema.org markup, or skip the markup and rely on the feed. The practical answer in 2026 is that the two are cross-checked, so both need to be right, and the feed is the one that unlocks checkout. The site’s guide to structured data for retail covers markup implementation in detail; here the question is how the two data sources interact from the agent’s point of view.
| Capability | Merchant feed (Merchant Center, ACP, UCP) | On-page schema.org markup | What happens when they disagree |
|---|---|---|---|
| Identity (GTIN, brand, MPN) | Required, validated against GS1 ranges | Supported via Product properties; not always validated | Feed value wins for matching; page mismatch can trigger a warning |
| Availability | Required enumeration; refreshable via API | Offer.availability, read at crawl time | Google can auto-update the feed from the page; ACP trusts the feed |
| Price | Required; checkout price of record | Offer.price plus priceCurrency; crawl-time snapshot | Mismatch disapproves the item in Merchant Center |
| Shipping | Structured per region with handling and transit times | OfferShippingDetails; less widely implemented | Feed wins; page used to fill gaps |
| Returns | Account-level policy with product overrides | MerchantReturnPolicy | Feed wins; page used for cross-check |
| Checkout eligibility | Explicit flags (enable_checkout, seller terms) | Not expressible | Only the feed can enable checkout |
| Crawled fallback for agents without a feed | Not applicable | Only source available | Missing markup means the product is invisible to crawl-based agents |
| Refresh speed | Minutes via API; hours via scheduled fetch | Depends on crawl frequency; often days | Stale page data is overridden by fresher feed data |
The pattern that emerges is that markup is the safety net and the feed is the working channel. For assistants that primarily cite rather than transact, page-level signals still carry weight, which is why the mechanics of how ChatGPT cites retail content and what Perplexity and Google AI Overviews reward remain relevant even for merchants with a fully compliant feed. But for the growing share of queries that end in an agent-initiated checkout, the feed is the only document that matters.
Where schema.org markup still does work the feed cannot
Two things markup handles better than any feed. First, it lives on the page the shopper eventually lands on, so it is the last-mile confirmation an agent can use before handing off. Second, it can express relationships a flat feed cannot: ProductGroup to variants, isSimilarTo and isAccessoryOrSparePartFor, and review and rating aggregates tied to the exact product entity. Merchants who maintain both see fewer discrepancies, because the same catalog source generates both outputs, and the discipline of keeping the page accurate for the crawler keeps the feed accurate for the agent.
How do you audit a feed and fix the common failures?
A feed audit for agent readiness is different from a Shopping ads audit, because the tolerance for blanks is lower and the consequences are exclusion rather than reduced ad performance. The steps below are ordered so that the gates are checked before the ranking factors, mirroring the way an agent consumes the data.
The audit sequence
- Pull the raw feed, not the platform’s summary. Export the file or API payload that is actually submitted, and count rows against the number of sellable variants in the catalog. A gap means variants are being collapsed or filtered before submission.
- Validate identifiers. Check every GTIN for length, check digit and prefix validity; flag any GTIN that appears on more than one row; flag brand values that do not match the manufacturer’s spelling; confirm that every variant row has a distinct GTIN and a shared item_group_id.
- Compare availability and price to the live page. Sample a few hundred rows across categories and fetch the landing pages. Any row where the feed says in_stock and the page says otherwise, or where the two prices differ by any amount, is a gate failure.
- Check the shipping and return objects for completeness. Every row needs at least one shipping entry for each target region with cost, handling time and transit time, and a resolvable return policy. Count blanks; the blank rate is the exclusion rate for deadline and checkout queries.
- Check the merchant-level fields. Seller name, policy URLs and terms need to be present and resolve to live pages. On ACP, confirm which items carry enable_search and enable_checkout flags and that the flags match the merchant’s intent.
- Measure refresh latency. Change a price or stock state in the source system and time how long until the feed reflects it. If the answer is measured in hours, the feed is stale for high-velocity items.
- Cross-check markup. For the same sample, parse the page’s schema.org Product and Offer objects and compare to the feed values. Discrepancies point to two catalog sources that have drifted apart.
- Only then review content. Titles, descriptions, images and attributes are the ranking layer. Improving them before the gates are fixed improves nothing the agent can see.
The failure patterns that recur
| Failure | How it shows up | Root cause | Fix |
|---|---|---|---|
| Static in_stock default | Failed checkouts, agent quality warnings | Export template hardcodes availability | Map availability from live inventory; add API push for changes |
| Parent-only variant export | Sizes and colors not shoppable through the agent | Feed generated from parent product records | One row per variant with item_group_id and per-variant GTIN |
| Reused GTIN across variants | Items disapproved or merged into one listing | Parent GTIN copied to children | Assign the correct child GTIN or declare no GTIN for that variant |
| Price mismatch with page | Merchant Center disapproval; ACP checkout errors | Tax, currency or promotion applied inconsistently | Generate feed and page from the same pricing service; use sale_price with dates |
| Empty shipping object | Excluded from “arrives by” and cost-comparison answers | Shipping configured in checkout only, not in the feed | Populate per-region shipping with handling and transit windows |
| No return policy reference | Hidden from checkout-eligible results | Policy exists on site but not in feed | Add account-level policy plus product overrides for exceptions |
| Daily file upload for fast-moving stock | Agent recommends items that sold out hours ago | Legacy scheduled fetch | Move inventory and price updates to the API; keep file for content |
| Brand written as storefront category | Product fails entity matching; no comparison answers | Brand field mapped from navigation taxonomy | Map brand from manufacturer attribute; normalize spelling |
None of these fixes involve rewriting product copy. They are data-plumbing changes, usually made once in the export layer or the catalog system, and they move a product from “invisible to agents” to “eligible to be ranked.” That is the largest single step available, and it is a prerequisite for anything content-related to pay off.
What is the outlook for feed requirements over the next 12 months?
Three trends are visible in the published roadmaps and in partner announcements. First, the field set is converging: ACP, UCP and Merchant Center already agree on the core identifier, availability, price, shipping and return fields, and Shopify, BigCommerce and the major PIM vendors are shipping single-source exports that target all of them. Second, freshness expectations are tightening, with API-based updates becoming the assumed path for inventory and price while file uploads are relegated to content and attributes. Third, merchant-level trust fields are expanding: seller identity, policy disclosure and per-item checkout consent are moving from optional to required as platforms take on the liability of agent-initiated orders.
For retailers, the practical implication is that the audit described above is not a one-time project. It becomes a standing control, reviewed at the same cadence as inventory accuracy or payment reconciliation. The strategic framing, including how agent channels fit alongside search, marketplaces and owned traffic, is laid out in the guide to preparing your store for AI shopping agents. The feed is where that strategy either becomes real or quietly fails.
FAQ: product feeds for AI shopping agents
Which single field causes the most exclusions from AI shopping agents?
Availability, because it is the field most often hardcoded in legacy exports. A product marked in_stock that is not actually in stock produces a failed checkout, and platforms respond to repeated failures by suppressing the merchant’s items. GTIN problems are a close second, but they tend to exclude individual products rather than the whole catalog.
Do I need a GTIN for every product to be included?
You need a valid GTIN for every product that has one assigned by the manufacturer. Private-label, handmade or custom goods that genuinely lack a GTIN can be declared as such, and brand plus MPN serves as the fallback identifier where applicable. What excludes products is a placeholder, a reused number or an internal SKU in the GTIN field.
How often does a product feed need to refresh for AI agents?
Faster than your stock and price actually change. OpenAI’s guidance for ACP cites intervals on the order of 15 minutes for inventory-sensitive fields, and Google supports API-based updates that apply within minutes. A daily file upload is acceptable for descriptions and images but not for availability or price on a catalog with meaningful turnover.
Is schema.org markup enough on its own?
Only for agents that crawl rather than ingest a feed, and only for surfacing, not checkout. Markup is a valuable backstop and is cross-checked against the feed by Google, but no major platform enables agent-initiated checkout from markup alone. Maintaining both, generated from the same catalog source, is the reliable approach.
What happens if my feed price and my page price differ?
In Google Merchant Center the item is disapproved until the values agree, unless automatic item updates can correct the feed from valid on-page structured data. In ACP and UCP flows the discrepancy surfaces at checkout as an error, which counts against merchant quality. Either way, the product stops being recommended.
Do shipping and return fields really affect inclusion, or only ranking?
Both. For any query that implies a delivery deadline or a total delivered cost, missing shipping data excludes the product because the agent cannot compute an answer. Missing return terms excludes products from checkout-eligible results on platforms that require a disclosed policy before completing an order. Where the data is present, better terms improve ranking among the remaining candidates.
How should variants be structured in the feed?
One row per sellable variant, each with its own GTIN, availability and price, all sharing a single item_group_id, with the varying attributes such as color and size filled in consistently. Exporting only the parent, or exporting children as unrelated products, makes the item either unshoppable at the variant level or a set of duplicates the agent collapses unpredictably.
Can a marketplace or platform submit the feed for me?
Yes, and for most mid-market merchants that is the default path. Shopify, Etsy and comparable platforms push catalogs into ACP, UCP and Copilot’s merchant program on the merchant’s behalf. The platform can only submit what is in the catalog, though, so blank shipping fields, hardcoded availability and missing GTINs pass straight through and cause the same exclusions.
What is the first thing to fix if the feed has never been audited?
Pull the raw submitted feed and count the blank rate on availability, price, GTIN, shipping and return fields, then compare a sample against live pages. The blank and mismatch rates tell you what share of the catalog is currently invisible to agents, and they usually point to one or two export-layer changes that fix the majority of rows at once.