Product feeds for AI answer engines

What a feed does that a page cannot

Structured data describes the page a system already fetched. A product feed is different: it is a file the merchant pushes to a specific company, describing the whole catalog on a schedule, whether or not any page was crawled that day. Several AI products now accept one, and a few of them will not show a product at all unless the feed says so.

This matters for AI SEO because the decision is no longer only about retrieval. When an assistant quotes a price, it is expected to be able to transact at that price, so freshness and internal consistency become correctness requirements rather than quality improvements. A stale feed is not a missed opportunity; it is a wrong answer with your brand on it.

Read this guide to understand what each company accepts today, which fields are actually required, and what to reconcile before submitting anything. It does not teach feed management as a discipline, and it cannot tell you whether a program will accept your business. Most of these programs are application-gated.

Who accepts merchant data today

Six surfaces matter, and they do not work the same way.

Two of these publish an actual field list you can implement against: OpenAI and Google. Microsoft builds on Google’s protocol rather than inventing a third format. That convergence is the single most useful fact in this guide.

The shared baseline

Google’s product data specification has been the common vocabulary of retail feeds for years, and the AI programs mostly inherited it. Google requires id, title or structured_title, description or structured_description, link, image_link, availability, and price, with conditional requirements such as availability_date for preorders, brand for new products outside movies and books, and gender, color, size, and age_group for apparel in certain regions.

OpenAI accepts Google-compatible TSV and CSV files alongside its own JSONL format. Perplexity’s merchant program is described in terms of the same kind of product data rather than a novel schema. If you already maintain a clean Merchant Center feed, you have most of the raw material for every program listed above. If you do not, build that first; it is the prerequisite, not a parallel project.

OpenAI’s required fields

OpenAI publishes the most explicit field list of the group. Nine fields are required for every row.

Beyond those, several fields become required once a condition applies. Variants need group_id, listing_has_variations set to true on every variant row, and a variant_dict mapping option names to selected values, with group_id different from item_id. Separate length, width, or height values require dimensions_unit. A weight value requires item_weight_unit.

The remaining fields are optional and grouped by purpose: identity and variants, item information such as condition, product_category, material, color, size, gender, and age_group, additional media, sale pricing, shipping, returns, review counts and ratings, and geo-tagging by ISO 3166-1 country codes.

Files may be JSONL, CSV, TSV, or tab-delimited text, and gzip-compressed .txt.gz, .txt.gzip, .tsv.gz, and .csv.gz are supported. Use UTF-8 and absolute HTTP or HTTPS URLs. Keep identifiers as strings so leading zeros survive the round trip, which is the most common way a GTIN column quietly corrupts itself in a spreadsheet.

The three fields that decide whether anything happens

OpenAI’s flag fields control participation, and they are worth reading carefully because their defaults differ.

• is_eligible_search enables search eligibility and defaults to true. Setting it to false also disables checkout eligibility.
• is_eligible_checkout opts a product into checkout and defaults to false. Set it to true only when search eligibility is also true.
• is_ads_eligible includes a product in Ads processing and is independent of search.

Checkout additionally requires seller_privacy_policy and seller_tos, both public URLs. OpenAI states plainly that setting an eligibility flag does not complete checkout onboarding; that is a separate integration. Treat the flag as a declaration of intent, not a switch that turns on a payment path.

Where the protocol fits

The Agentic Commerce Protocol is a separate artifact from the feed specification, and conflating the two causes avoidable confusion. ACP is an Apache-2.0 open standard governed by OpenAI and Stripe as founding maintainers, using date-based versioning in YYYY-MM-DD form, with 2026-04-17 as the latest stable version at the time of writing. Its specifications cover the Agentic Checkout API, a Delegate Payment API, JSON Schema data models, and OpenAPI descriptions. Those are integration contracts for the transaction. The product feed is how the catalog gets there in the first place.

Google, Microsoft, and the UCP path

Google’s Universal Commerce Protocol does not introduce a new feed format. It extends what Merchant Center already holds so that product data can support a transaction rather than only a listing. Google asks merchants to configure shipping, returns, and the product feed, and states that integration requires Google approval, with a waitlist for contact.

One attribute governs the visible result. Google’s documentation says that only product listings using the native_commerce(checkout_eligibility) product attribute will display the Buy button for this checkout experience, that the guidance applies to products with eligibility in the United States, Canada, and Australia for participating merchants and partners, and that the experience may appear on specific surfaces such as AI Mode in Search and Gemini. Google also notes that UCP is an evolving standard and that not all features defined in the specification are available on Google’s surfaces. Read that as an instruction to verify the current documentation before promising a client an outcome.

Microsoft has taken the same path rather than a competing one. Microsoft requires a Microsoft Merchant Center account and a UCP-compliant feed, with feed updates covering native checkout eligibility, product warnings where needed, and a unique Merchant Item ID. Eligibility is currently limited to English-language merchants selling to United States buyers in USD. Microsoft states that the merchant remains the merchant of record, that Copilot does not become merchant of record, and that no Microsoft commission is charged because payments run on existing rails. Merchants are also asked to complete store settings in Merchant Center for return policy, customer support, and Copilot Checkout.

For a merchant already in Google Merchant Center, the Microsoft path is mostly a second destination for work already done. That is a genuine efficiency, and it is a reasonable argument for treating UCP attributes as the second priority after the baseline feed.

Perplexity, Amazon, and Anthropic

Perplexity operates an application-based merchant program. Its Merchant Program Terms define Product Data broadly: product title, price, description, brand or source, model, weight, in-stock and availability status, country of origin, shipping lead time, shipping options, shipping origination, dimensions and other shipping specifications, images, warranties, disclaimers, returns and exchange policies, warnings, notices, labels, testing certificates or certificates of compliance, and other product information Perplexity requests. Perplexity has said the program is free for merchants. There is no public field-level specification equivalent to OpenAI’s, so treat the terms as the scope statement and expect the technical detail to arrive during onboarding.

Amazon is a closed system. Amazon describes bringing Rufus and Alexa+ together as Alexa for Shopping, and its seller guidance is that complete and accurate product attributes help the assistant recommend a product, with sellers advised to anticipate the questions customers ask before purchasing and make sure the listing answers them. There is no external feed to submit. This is listing work inside Amazon’s own systems, and it belongs to whoever owns the marketplace account rather than to the website team.

Anthropic has published no merchant field specification. On September 2, 2026, it released a blueprint for building commerce agents on Claude, with reference implementations for a shopping agent and a merchant agent and integration points for catalog, cart, checkout, customer preferences, and order history, available at github.com/anthropics/commerce-agents. The merchant defines the interface. That is a build decision for an engineering team, not a feed submission, and it does not put products into Claude’s general answers.

Reconcile before you submit

The work that actually changes outcomes is not filling in fields. It is deciding which system owns each fact, because a feed introduces a third copy of data that a product page and its JSON-LD already describe.

Consider a hypothetical variant. The product page shows £49.00. The Offer in the page’s JSON-LD says 52.00 GBP. The ecommerce platform’s price table says 49.00. The draft feed row, exported last week, says 52.00 GBP and availability: in_stock, while the platform shows zero sellable units.

Three values, two of them wrong, and the resolution order matters:

1. Identify the owning system. The platform’s price table is the system of record for price and stock. The page and the JSON-LD are outputs; the feed is another output.
2. Read the disagreement as a symptom. The page and the platform agree at 49.00, so the JSON-LD and the feed share a cause: both were generated before the price change and neither regenerates on a price event. The fix is the regeneration trigger, not the two values.
3. Repair upstream, then republish every dependent output. Correcting the feed row by hand produces a feed that is right today and wrong at the next price change.
4. Recheck all three surfaces together. Page shows 49.00, JSON-LD says 49.00 GBP, feed says 49.00 GBP and availability: out_of_stock.

The checked result is that a shopper, a rich-result consumer, and a shopping agent now see the same offer. The plausible mistake here is treating in_stock as the safer default because it keeps the product visible. It does not: it converts a discoverability problem into a failed transaction, and in a checkout-enabled program it fails at the worst possible moment.

Apply the same test to identifiers. A GTIN that differs between the feed and the page, or a variant URL that resolves to a parent listing, breaks the match between what the agent describes and what the shopper lands on.

The merchant feed readiness checklist turns this into a review record, with the sampling approach and the maintenance triggers that keep a corrected feed correct. For the on-page half of the same data, use the Product JSON-LD template, the Offer and AggregateOffer templates, and the ProductGroup template when variants are involved.

Decide what to do first

First, get the baseline feed correct. A complete, current Google product data specification feed with accurate identifiers, price, availability, and variant structure is the prerequisite for four of the six surfaces. Nothing downstream improves while it is wrong.

Next, if the feed is clean, reconcile it with the page and the markup. Use the price, currency, availability, variant, and identifier comparison above. This is the part that belongs to the SEO team, because it is the same claim-and-evidence discipline applied to commerce data.

Next, if the business sells into a supported market, add the program-specific attributes. UCP checkout eligibility for Google and Microsoft; OpenAI’s eligibility flags plus the privacy policy and terms URLs. Check current eligibility before committing the work.

Can wait: the transaction integrations. Checkout onboarding, payment delegation, and agent APIs are engineering projects with commercial and legal review attached. They do not block discovery.

Does not apply to most readers: building a commerce agent. Anthropic’s blueprint is for teams shipping their own assistant.

Move on when the feed, the page, and the structured data agree on every material value for a sample of products spanning your variant structures, and when you can name the system that owns each of those values.

What a feed does not do

Submitting a feed does not place a product in an AI answer. Every program here selects what to show. Acceptance into a merchant program is not a ranking factor, a citation, or a guarantee of visibility, and none of these companies publishes a mechanism by which feed completeness produces placement.

Availability is also narrower than the coverage suggests. Google’s checkout is limited to three countries and participating merchants. Microsoft’s is limited to English-language merchants selling to United States buyers. Several programs require approval that a small merchant may not receive. Plan the baseline work, which is useful regardless, and treat program participation as conditional.

Finally, these specifications are moving. ACP versions by date, Google says its standard is evolving, and field lists change. Check the primary documentation before implementation rather than relying on any summary, including this one. Third-party accounts of these specifications frequently disagree with the vendors’ own published field counts and requirements.

Official references

• OpenAI: product feed specification
• OpenAI: agentic commerce specifications
• Agentic Commerce Protocol repository
• Google Merchant Center: product data specification
• Google Merchant Center: about UCP and UCP-powered checkout
• Google: UCP for merchants
• Microsoft Advertising: agentic commerce
• Perplexity: merchant program terms
• Amazon Seller Central: Alexa for Shopping
• Anthropic: building commerce agents with Claude