Product Feeds for AI Agents: What Machines Need to Compare.
An agent can only choose between items whose attributes, availability and price it can read without rendering a page. That makes feed completeness and structured data the entry requirement for being in the comparison set rather than an improvement applied to items already inside it.
Ask an agent to find a 15-inch laptop bag under $60 that ships within three days. It never looks at the page a shopper sees. It evaluates fields: a price with a currency attached, a dimension expressed as a number and a unit, a delivery window it can test against three days. Comparison happens against typed data. If the dimension exists only inside a photograph, the price only as a rendered string, and the delivery estimate only on the checkout page, the item is not ranked lower. It is absent.
Google and Adyen both shipped named agentic commerce tooling during 2026. That is why the requirement is now being written down by the parties who intend to consume it.
What does an AI agent actually read when it compares two products?
An AI agent reads structured data and feed records, not the rendered page. What reaches it is a set of typed fields for each item, retrieved without executing JavaScript and without inferring meaning from layout.
Item data travels by three routes. The first is a product feed, either submitted to a consumer that ingests it or hosted at a URL on a schedule. The feed is usually delimited text, in CSV or TSV form, or an XML list of items in the shape RSS 2.0 and Atom 1.0 established. The second is on-page structured data, where the same facts are marked up in the page itself using JSON-LD, microdata or RDFa. The markup expresses schema.org types such as Product and Offer. The third is a catalogue API that answers a query with records rather than with a document.
"Readable without rendering" means something narrow and testable. A single fetch returns values that already carry a label and a type: a number that is declared to be a price, a currency given as an ISO 4217 code, a date given in ISO 8601, a state drawn from a fixed list of allowed values such as the schema.org ItemAvailability enumeration. Nothing in that response has to be recovered from styling, position or wording.
Comparison then becomes a field-level operation. The agent holds a constraint set assembled from the request, such as a budget ceiling, a size, a delivery deadline and a condition. It tests each item's attributes against every constraint in turn. It is not reading your description and forming an impression. It is checking whether a value satisfies a rule. An item with no value to check is eliminated before any judgement about quality happens.
Which attributes decide whether an item can be compared at all?
Four classes of field decide whether an item can be compared: a stable identifier, a current price with its currency, an availability state and the variant axes that distinguish one SKU from its siblings. Missing any one of them removes the item from a constrained comparison rather than lowering its position within one.
| Field class | What the agent does with it | What happens when it is absent |
|---|---|---|
| Identifier (gtin global trade item number, mpn manufacturer part number, sku internal stock keeping unit) | Recognises the same item across merchants and deduplicates the set | One product appears as several unrelated listings, or it matches no known item at all |
| Price and currency (price, priceCurrency) | Tests the item against a numeric ceiling | The budget constraint cannot be evaluated, so the item drops out of any priced query |
| Availability state (availability, an enumerated value such as InStock or OutOfStock) | Filters to what can be bought now | Buyable and unbuyable items compete on equal terms until checkout fails |
| Variant structure (item_group_id plus axis fields) | Separates a size or colour from a genuinely different product | The wrong variant is selected, or the variants collapse into one ambiguous row |
A gtin administered under GS1 rules resolves outside your catalogue. That is what allows an agent to notice that three merchants are offering the same item at three prices. An internal sku carries no meaning beyond your own systems, so it deduplicates nothing.
Price has to be a single typed number. A rendered "from $39" supplies no single value to compare against $60, so it defeats a constraint check. An agent that cannot resolve the ambiguity drops the item.
The same logic reaches the specification fields, which is where most catalogues are weakest. A numeric constraint cannot be evaluated against an unquantified adjective, so "compact" satisfies nothing. A width, a height and a depth satisfy a dimension rule directly when they are carried as additionalProperty values with units. Published feed specifications revise which individual fields they require. Treat the four classes above as the durable requirement, and check the current field list against whichever specification you are writing to.
Why does a page that looks complete to a shopper look incomplete to a machine?
Most product pages hold their decisive facts in places a parser never reaches. The page is complete to a person who can see, click and interpret, and thin to a parser that does none of those things.
Start with images. Dimensions printed on a diagram, compatibility shown as a grid of ticks, care instructions rendered as a label photograph: all of it is invisible to a parser that reads the response body. The alt text written for accessibility rarely repeats the numbers. Then consider content behind interaction. Specification tabs, accordions and review panels arrive through a client-side fetch after the initial response. They exist in the DOM only once a browser has run the page, so a parser that does not render receives the shell and nothing in the drawers. That is the same blind spot covered in the LLM-ready storefront.
Free-text specification prose fails differently. A shopper reads "fits most standard frames" and knows roughly what to do with it. A constraint check has no rule for "most" and no definition of "standard". The sentence contributes nothing to a comparison, even though it is the sentence a human would have relied on.
The last failure is disagreement. When a page and a feed both describe an item and their prices, availability or titles differ, the agent has two contradictory records and no principled way to choose between them. Sometimes it takes the feed because the feed is what it ingested. Sometimes it takes the page because the page was fetched more recently. Neither outcome is under your control. That makes parity between the two a data requirement rather than a tidiness preference.
How do feeds built for advertising fall short for an agent buyer?
Advertising feeds are built to establish eligibility, meaning enough fields to be matched to a query and shown. An agent buyer needs enough fields to eliminate, which is a stricter test. It also needs values fresh enough to commit money against.
Eligibility tolerates vagueness because a human closes the gap. An ad can carry an approximate title and an unquantified attribute, because the person who clicks will read the landing page and decide. An agent has no landing page step. Whatever the field does not say is a fact the agent does not have when it shortlists, and it will not guess on your behalf.
Freshness works the same way. A price that is a few hours stale costs an advertiser a mismatched impression. The same staleness at the moment of selection produces a wrong recommendation, and at the moment of purchase it produces a failed transaction. The acceptable age of a price and a stock level is therefore far shorter for an agent buyer than for an ad auction.
Then there are the fields nobody filled in because no advertising channel scored them: condition, shipping, return_policy, the delivery window and the compatibility attributes that decide whether an item works with something the buyer already owns. Those are exactly the fields an agent uses to narrow a set.
Some habits are worse than omission. Keyword-loaded titles corrupt the field an agent uses to identify the product, and promotional text inside the title field pollutes it further. Variants merged into a single row to simplify reporting destroy the structure that tells a colour from a different model.
Being unreadable is not a ranking penalty. It is an absence from the shortlist.
Google published retailer tooling for agentic shopping on 11 January 2026. That tells you the consuming side has started writing its requirements down. Treat it as a date on a calendar rather than as a finding.
Does an agent need a feed, on-page structured data, or a catalogue API?
A product feed, on-page structured data and a catalogue API all carry the same facts and fail in different ways. In practice a feed and on-page structured data are both non-optional, and an API is what you add when freshness matters more than reach.
| Route | Freshness | Coverage | Access requirement | Main failure mode |
|---|---|---|---|---|
| Product feed | Batch, set by the ingestion schedule | Whole catalogue in one artefact | A relationship with whoever ingests it | Values age between runs |
| On-page structured data | As current as the page | One item per URL, discoverable through the sitemap | None beyond a fetchable URL | Blocked or unrendered pages yield nothing |
| Catalogue API | Live, with query flexibility | Whatever the endpoint exposes | Authentication for non-human clients, plus a rate limit | The consumer has to know the endpoint exists |
The choice between them matters less than what sits behind them. When the feed, the page markup and the API each derive from a separate export, they drift. A consumer reading two of them finds a feed and a page that disagree on price, availability or title, with no principled way to choose between them. Generate all three from one source of truth for item facts, and a correction made once appears everywhere within one publishing cycle. How much of that pipeline you control depends on the platform underneath.
What still breaks when an agent can read the catalogue but cannot trust it?
Readability is necessary and not sufficient. Three things still break: the retrieval gets blocked, the values go stale, and the same item fails to resolve to itself across merchants.
Bot mitigation is the first wall. CDN-level defences, rate limiting and robots.txt rules were written to stop scrapers. A legitimate shopping agent presents at the edge much as a scraper does: an automated client, a user agent string you have not seen before, a burst of requests against product URLs. Allowlisting requires you to identify the caller, and there is no settled way to identify a non-human client. The current answer is therefore a policy decision rather than a configuration, and it belongs alongside the other changes a platform has to make.
Staleness is the second, and it is a transaction failure rather than a data quality complaint. A cache time-to-live that suits a human browsing session lets an agent commit to a price or a stock level that has already changed. The result is a cancelled order that both sides record as your fault.
The third is standards. Trade coverage in January 2026 described more than one agent-to-merchant protocol competing for adoption. That coverage included a post on the Rezolve Ai vendor blog, dated 29 January 2026. Adyen's press release of 16 June 2026 announced Adyen Agentic, a product positioned as a translator between agents and merchant checkout. Both are interested parties rather than neutral evidence. What they establish is only that plurality was real enough to sell against. That is the reason to keep your catalogue format-agnostic and to avoid depending on the vocabulary of any one candidate.
The honest limit: none of this is fully specified, and a merchant cannot fix it alone. You control whether your facts are typed, complete and current. You do not control whether the consuming side agrees on how to ask for them.
What should you fix now, and what should wait for the standards to settle?
Fix everything that makes item facts typed, complete and current, because every route and every candidate protocol requires that work. Defer anything that commits you to one agent protocol or one payment rail, because the field has several candidates and no winner.
Do these in order. First, audit identifier coverage, and count the live SKUs carrying a resolvable gtin or mpn rather than only an internal sku. Second, make price, currency and availability typed and identical in the feed and on the page, because parity removes the contradiction an agent cannot adjudicate. Third, move image-only and prose-only facts into fields, taking dimensions, compatibility and materials out of diagrams and specification paragraphs and into named properties with units. Fourth, shorten the freshness interval on price and stock until it is defensible at the moment of purchase, not merely at the moment of retrieval. Fifth, make variant structure explicit, so that a group and its axis fields describe the range instead of one merged row implying a single product.
Second tier, and slower because it crosses teams: decide how a legitimate agent identifies itself to your edge, and name the person who owns that decision.
Defer protocol selection, agent payment rails and any integration that binds your catalogue to one vendor's vocabulary. The test is a single question. Would this change still be useful if a different protocol won? Typed prices, resolvable identifiers and unit-bearing attributes pass it. A protocol-specific endpoint does not.
Start with an audit, not an integration
Run a catalogue audit this quarter against four questions. What percentage of live SKUs carry a resolvable gtin or mpn? Are price, currency and availability typed and identical in the feed and on the page? Which decisive attributes exist only in images or prose? How many minutes old can a price be when an external consumer reads it?
Whoever owns the product data model owns the first three. Whoever owns the CDN and the bot policy owns the question of how a legitimate agent identifies itself. That conversation should happen before the first integration request arrives rather than after it has been blocked.
Feed completeness and structured data remain the entry requirement whichever protocol wins. That is why it is the work to do now.
Frequently asked questions
- What does an AI agent actually read when it compares two products?
- An AI agent reads structured data and feed records, not the rendered page. Item data travels by three routes: a product feed in delimited text or XML, on-page structured data marked up as JSON-LD, microdata or RDFa expressing schema.org types such as Product and Offer, and a catalogue API that answers a query with records. Readable without rendering means a single fetch returns values that already carry a label and a type.
- Which attributes decide whether an item can be compared at all?
- Four classes of field: a stable identifier such as a GTIN or MPN, a current price with its currency, an availability state drawn from an enumerated list, and the variant axes that distinguish one SKU from its siblings. Missing any one of them removes the item from a constrained comparison rather than lowering its position within one.
- Why does a product page that looks complete to a shopper look incomplete to a machine?
- Most product pages hold their decisive facts where a parser never reaches: dimensions printed on a diagram, compatibility shown as a grid of ticks, specification tabs and accordions that arrive through a client-side fetch after the initial response. Free-text prose fails differently, because a constraint check has no rule for a phrase such as fits most standard frames.
- How do feeds built for advertising fall short for an agent buyer?
- Advertising feeds are built to establish eligibility, meaning enough fields to be matched to a query and shown. An agent buyer needs enough fields to eliminate, which is a stricter test. Eligibility tolerates vagueness because a human closes the gap on the landing page, and an agent has no landing page step. Freshness is stricter too: staleness that costs an advertiser a mismatched impression produces a failed transaction for an agent.
- What should a merchant fix now, and what should wait for standards to settle?
- Fix everything that makes item facts typed, complete and current, because every route and every candidate protocol requires it: identifier coverage, typed price and availability with parity between feed and page, image-only and prose-only facts moved into fields with units, a shorter freshness interval, and explicit variant structure. Defer protocol selection, agent payment rails and any integration that binds the catalogue to one vendor's vocabulary.