Blog · Agents and commerce

Product feeds for AI shopping surfaces

Published 31 March 2026 · Updated 8 October 2026 · 8 min read

Product feeds for AI shopping surfaces
Photograph: Markus Winkler / unsplash

The short answer: A product feed is a machine-readable file of your catalogue, one row per buyable item, submitted to an engine rather than crawled from your site. Two shopping surfaces document feed intake today, OpenAI's commerce programme and Google's Merchant Center, and a feed carries fields a page rarely exposes cleanly: stable identifier, brand, seller, price, availability, returns. If you sell physical goods and submit nothing, those two surfaces are reading your HTML and inferring the rest.

We have not seen published feed intake documentation from the other engines, which is not the same as knowing they ignore feeds.

That guessing is the whole problem. A crawler arriving at a product page has to infer which of three prices on the page is the one you charge, whether the grey "notify me" button means out of stock, and whether this URL is the parent product or the blue size large variant. A feed row removes the inference. That is the mechanism, and everything below follows from it.

What a feed row actually has to contain

OpenAI's product feed specification lists nine required fields: item_id, title, description, url, brand, seller_name, image_url, availability and price. Nine is a short list, and most catalogues already hold all nine somewhere. The spec also caps title at 150 characters and description at 5,000, and it asks that identifiers stay strings so leading zeros survive.

Google's Merchant Center product data specification requires a comparable set: id, title, description, link, image_link, availability and price, with availability restricted to four values, in stock, out of stock, preorder and backorder. Note what both lists share and what neither contains. No keywords. No marketing copy slot. No place to argue your case.

The recommended fields are where position is usually won or lost. gtin or mpn let the surface match your listing to the same product sold elsewhere, which is how a comparison gets built at all. group_id with a variant dictionary tells it that eleven rows are one shoe in eleven sizes rather than eleven shoes. sale_price, review_count, star_rating, accepts_returns and return_deadline_in_days each fill a slot the answer would otherwise leave blank or fetch from somewhere you do not control.

Feeds and pages are two different reads, and both still happen

The useful mental model is two parallel pipelines. One crawls the open web and parses your product detail page. The other ingests your submitted feed. They produce different field sets, they update on different clocks, and an engine can mix them inside a single answer.

Google says this out loud in its Product structured data documentation: product snippets may use pricing data from your merchant feed when that price is not present in the structured data on the page. Read that twice. The page and the feed are not alternatives in a tidy sense. One can patch a hole in the other, which means a wrong value in either can reach the user, and a disagreement between them is a live risk rather than a tidy fallback.

This is why feed work does not replace page work. Product schema for AI shopping answers covers the on-page half, and the honest position is that a brand serious about this surface does both, with the same numbers in both. Crawl-side reach also still matters for everything a feed cannot express, which is most of your category and comparison content, and that is where agentic commerce and your catalogue picks up the thread.

The formats are narrower than you expect

The OpenAI feed spec accepts JSONL, one JSON object per line, as its native format. It also accepts a Google-compatible path: tab-delimited .txt or .tsv, or comma-delimited .csv, including gzipped versions of each. What it explicitly does not accept on that compatibility path is plain JSON, spreadsheets, XML, RSS or Atom.

That last exclusion catches people. XML product feeds have been a standard ecommerce export for years, because that is what older shopping channels wanted, and we have no count of how many platforms still emit them by default. If your team's answer to "do we have a feed" is "yes, the XML one", the honest follow-up is whether anything on this surface can read it. Check the file extension and the first line of the file, not the ticket that says the feed exists.

Submission is also not a one-off upload. OpenAI's commerce get started guide asks you to post the entire feed once a day as a file, overwriting the same file or shard set, and to send changes through the API during the day. The same guide describes onboarding as open to approved partners through an application, so availability on that surface is a business step and not only an engineering one.

The failure mode nobody notices: a feed that succeeds and lies

Here is the part that costs money. A broken feed throws an error and somebody fixes it. A stale feed uploads cleanly every night and quietly tells the surface that an item is in stock at last quarter's price. A well-formed row is a well-formed row, so the upload path has nothing to flag and the listing stays up. The buyer arrives at a page that disagrees with what the assistant told them. Neither specification tells us what a surface does with a merchant whose numbers failed that way, and we have no measurement of it, so treat the downstream cost as a reason to care rather than a documented penalty.

Both specifications are blunt about this. Google asks that price and currency match the landing page, the structured data and the checkout, and that availability match the landing page. The OpenAI spec asks you to submit the current price and update when a sale starts or ends, and to update availability when an item sells out.

So run the reconciliation yourself. Neither specification describes an engine-side check that compares your submitted rows against your live pages and tells you when they drift, so assume nothing reports it to you. Take fifty rows at random from last night's feed. For each, fetch the product URL and pull three values off the live page: the price, the availability, and the canonical URL. Compare them to the feed row. Count the mismatches. We have run this check by hand during audits of a small number of mid-size catalogues and have found mismatches each time, most often around sale endings, variant-level stock, and discontinued items whose delete path was never wired up. We did not record the counts in a form we can publish, so read that as a pattern we have seen in a handful of samples, not as a rate.

A second check takes ten minutes. Sort your feed by item_id and look for rows sharing a gtin with different item_id values, or variants with no group_id. Each one of those is a product that may be split across several weaker listings instead of consolidated into one strong one.

A third: diff two consecutive nightly files. If a catalogue of thirty thousand rows produces a byte-identical file two nights running, something upstream has frozen. That is the same freshness discipline described in sitemaps, feeds and freshness signals that matter to AI, applied to a file that updates far more often than a sitemap does.

Where the feed stops and the agent starts

A feed gets you considered. It does not get you bought. Once an assistant moves from recommending to acting, the questions change: can the agent reach a checkout, does it hit a bot challenge, does the form it needs to fill exist in HTML. That boundary is the subject of can an agent book, buy or fill your form, and it is worth mapping before anybody promises that a feed will produce orders.

The self-check has ten things you can test this afternoon, several of which apply directly to a catalogue, and none of which need a tool.

Honest limits

Everything checkable in this post comes from two sets of vendor documentation, OpenAI's and Google's, read on 8 October 2026. Field lists, format rules and cadence are what those two publish about their own surfaces on that date, and we do not know whether ChatGPT shopping answers, Google AI Overviews, Perplexity, Claude, Copilot or Gemini behave the way the documents describe, because none of them report which source fed a given answer. The reconciliation check above is something we have run by hand on a handful of mid-size catalogues during audits, which is a sample and not a census, and we are not publishing a mismatch rate because we did not record the counts in a reproducible form. We also have no independent figure for how often an engine prefers feed data over crawled data, and no documentation anywhere describes how recommended fields are weighted against each other, so anything you read on that is inference. Feed eligibility is gated by partner programmes that change, so today's access list is the thing most likely to be wrong by the time you read this.

What is checkable is the part above: the required fields, the accepted formats, the daily cadence, and whether your own feed agrees with your own pages tonight.

FAQ

Do I need a product feed if I already have Product schema on every page? They do different jobs. Schema helps a crawler parse the page it already fetched. A feed gives the surface your catalogue without a fetch, with fields such as seller_name and return terms that pages rarely expose consistently. Most sellers of physical goods benefit from both carrying identical values.

What if my feed and my product page disagree? Treat it as a defect, not a tolerance. Google's specification asks for price and availability to match across feed, landing page, structured data and checkout. A mismatch can surface a wrong number to a buyer, and it gives any system reading you a reason to trust you less.

Can I submit an XML feed? Not on the Google-compatible path described in the OpenAI feed spec, which names JSONL, tab-delimited text, TSV and CSV, and excludes XML, RSS, Atom, plain JSON and spreadsheets. Converting an existing XML feed is usually a small job, once somebody owns it.

How often should the feed update? OpenAI's commerce get started guide asks for a full file once a day, with intraday changes sent through the API. Prices and stock move faster than a daily file in most catalogues, which is exactly why the API path exists.

Sources

All four read on 8 October 2026.

Related reading

Agentic commerce: what an agent needs from your catalogueCan an agent book, buy or fill your formSitemaps, feeds and freshness signals that matter to AIProduct schema for AI shopping answersAgent payments, and the trust signals in the wayAgent traffic is not bot traffic