AI shopping product feeds are product catalog data adapted to a specific shopping service. Their fields tell Google, OpenAI, or another service what it can do with each listing.
On both Shopify stores I ran, Merchant Center acceptance could look like the final check. Comparing those feeds with newer checkout requirements exposed separate eligibility and return fields that the usual review hadn't flagged. This audit helps you find that kind of gap before submission.
Key takeaways
What is an AI shopping product feed?
There is no universal AI-shopping feed schema. The term describes a source catalog adapted to the rules of each shopping service. Google Merchant Center requires seven attributes in its base record. Its product data specification lists them,
- Include the ID.
- Add the title.
- Write the description.
- Provide the product link.
- Link the main image.
- Report availability.
- Set the price.
OpenAI, Google, and private catalog connections then apply their own field rules and submission paths. They may need to identify one variant, confirm stock, show the payable price, and support checkout. That's one practical example of AI across a dropshipping store.
A live Model Context Protocol connection changes how that record reaches the agent. The agent may query a store server. Its source catalog still needs correct identity, stock, price, and policy data.
Run the Agent-Ready Feed Audit
The Agent-Ready Feed Audit checks whether a feed can identify, describe, and keep a purchasable item current across agent surfaces.
Work through these checks in sequence,
- Identity: Match each item to a stable manufacturer or merchant identifier.
- Variants: Give every purchasable option its own stable record.
- Availability: Use the destination's accepted stock values.
- Price: Send the current payable amount and currency.
- Shipping: State order limits, charges, and handling cutoffs.
- Returns: Separate return acceptance, window, and policy URL.
- Media: Supply a crawlable main image for the selected variant.
- Provenance: Preserve required metadata on generated images.
- Refresh: Update price and stock when either changes.
Start with the live export. Run schema checks across every applicable feed record, then use the spot tests below to confirm the export matches the store. A check passes only when every applicable record meets its rule. Mark it fail for any known exception and unknown when you can't verify the source or destination rule. Both fail and unknown block submission.
1. Identity
Use the manufacturer's identifier when one exists, and keep your item ID stable for the life of that item. When a product has no assigned global trade item number, Google requires a manufacturer part number with its brand. OpenAI also tells sellers to store identifiers as strings and never reuse an item_id for another item.
Identity comes first because a mistake here can attach correct price and stock data to the wrong product. Scan the full export for missing or reused IDs. Then check a sample against manufacturer records and confirm that IDs survive a routine update. Pass only when the scan is clean and every sampled ID matches its source.
2. Variants
Give every purchasable variant a distinct, stable item_id, then connect related variants with one parent group. OpenAI's discovery format requires nine fields on each row to identify the item and seller, connect its image, and report price and availability. Its current variant rules also call for a separate row for each selection.
Match each row's URL, image, price, and availability to that exact option. A red medium shirt can't share the selected URL or image for a blue large shirt. Filter one parent group in the export and check that every option appears once.
Scan every parent group for duplicate, missing, or mismatched options. Pass when each purchasable option appears once with the correct URL, image, price, and stock. A catalog with no variants passes when grouping fields are absent.
3. Availability
Send an accepted stock value on every OpenAI row, and update it when the item's status changes. OpenAI accepts five values,
- Send in_stock.
- Choose out_of_stock.
- Use pre_order.
- Set backorder.
- Report unknown.
An empty or unrecognized value causes OpenAI to reject the row. Use unknown when stock status is unavailable, because it leaves purchasability unconfirmed. Scan the full column for values outside the list, then compare one in-stock and one sold-out SKU with the storefront. Pass only when the scan is clean and both spot checks agree.
Google uses preorder without the underscore, while OpenAI uses pre_order. If you send one value to both platforms without changing it, one may reject the row.
4. Price
Send the current amount with an uppercase three-letter currency code, and keep sale price separate from regular price. OpenAI's money format uses amount CURRENCY. One valid form is 79.99 USD. Google also expects the feed price to match the landing page and checkout.
Validate the amount and currency format across the full feed. Then compare one regular item and one sale item across the feed, product page, and checkout. Pass when the format scan is clean and both spot checks agree. Any mismatch fails the check.
5. Shipping
Record the shipping values that decide whether a shopper can place an order. Google's 2026 specification update added two product-level fields. They are handling_cutoff_time and minimum_order_value. The cutoff sets the daily processing deadline. The minimum states how much a shopper must spend before an order can ship.
OpenAI's format can carry shipping_price or the shipping structure named in your integration. If you omit the amount, OpenAI records shipping as unknown and won't assume it's free. Check the registered feed template, onboarding schema, or vendor field map for the accepted structure. Mark this check unknown when none of those records names it.
Pass when every mapped cutoff, minimum, and charge matches the active store rule. A guessed or unmapped value fails.
6. Returns
State whether you accept returns separately from the return window and policy URL. OpenAI separates the data into three fields,
- Use accepts_returns for return acceptance.
- Set the window with return_deadline_in_days.
- Link the policy through return_policy.
A policy link alone doesn't turn returns on or set the window, so all three fields need their own check.
Google can apply an account-level default policy or offer-level return data. A return_policy_label connects the row to the policy for that product. Check the return window and accepted item condition on the linked page.
Scan the applicable return fields across the full feed, then check the linked policy for one standard and one final-sale item. Pass when the structured fields and both pages agree.
7. Media
Use a direct, public main-image URL that shows the same variant as the row. Google and OpenAI both require a main image in the core discovery record. OpenAI omits invalid optional image URLs. Google can limit or reject offers with a missing or noncompliant primary image.
Test every exported main-image URL for public access, then compare a sample across each product family with its variant page. Pass when every URL loads and each sampled image matches its row.
Media requirements can change apart from the feed schema. Google has announced a larger minimum image size. Enforcement begins in 2027, so include image checks in your review schedule.
8. Provenance
Preserve provenance metadata when a product image was made with generative AI. Google's product specification names IPTC DigitalSourceType metadata for generated images. This audit checks whether the required tag survived export. Our AI product photography guide explains the full metadata check.
Inspect the delivered file, not just the original upload. Download the final image from its feed URL because processing can strip tags before delivery. Follow the linked guide's metadata-inspection steps. Pass when every generated image keeps the required tag. Mark the check unknown when the image's origin can't be verified.
If the image wasn't generated, record that fact and move on. Provenance depends on the image's source, so the pixels alone can't settle it.
9. Refresh
Update current price and availability whenever either value changes in the store. OpenAI says sale dates and availability dates don't schedule future feed changes. Send a new price when a sale changes. Send a new stock value when inventory changes.
To test the refresh path, trace one price update and one stock update from the storefront through the exported file to the shopping service. Record the elapsed time and the system responsible for each transfer. Pass when both changes arrive within the timing promised by your onboarding agreement. A missing promise leaves the timing criterion unknown.
I wouldn't promise a universal refresh interval because OpenAI's current public product reference doesn't set one. Use the fastest schedule that fits your onboarding agreement and the pace of inventory changes, then alert on missed runs.
Which fields, which surface, what breaks
Google, OpenAI, and MCP-connected agents may read different fields from the same catalog. Google's checkout flag is irrelevant to OpenAI, while an MCP server may query the catalog without accepting a file.
The comparison below records the service and failure mode for each check:
A private MCP server maps data through its own tool schema and catalog. I mark its result unknown until a test query matches the store's variant and its current price and stock.
What native_commerce actually controls, and what it doesn't
Google's native_commerce flag is a conditional checkout setting outside the nine shared catalog checks. Add it with checkout_eligibility only for Google's native checkout. A value of true enables the Buy button on supported Google services. A value of false or a blank field keeps the item as a standard listing. Google recommends a supplemental feed when you want to leave the primary feed unchanged.
Pass this Google-only subcheck when Merchant Center ingests true and the eligible item reaches the supported checkout flow. Mark it unknown when the account or region doesn't support that flow. Ranking happens after Google considers the query and product data, and no feed value guarantees an impression or citation.
An enabled flag also can't replace shipping and return data. If checkout still fails after Google ingests the flag, check the remaining audit rows before treating the behavior as a platform bug.
When this checklist will not fully protect you
The audit verifies the feed's structure, while the shopping service still controls ranking, approval timing, software support, and regional eligibility. A correct record gives the service usable data, but it doesn't decide how the service answers a shopper's query.
When a feed tool lacks a new attribute, record the gap and ask the vendor about a supplemental feed or direct mapping. A substitute column may be ignored or read with the wrong meaning.
I recommend submitting only after all nine checks have a recorded pass. For every failed or unknown check, record the affected feed records and the person responsible for the fix. That record tells you what to retest after an update.
FAQ
How is an AI feed different from a regular feed?
A regular Google Shopping feed can display and link a product using its core listing fields. An AI-ready feed also carries the variant and transaction details its destination needs for discovery or checkout.
Do ChatGPT and Google need separate feeds?
You can start with one source catalog, but each destination has its own submission and field rules. OpenAI accepts a Google-compatible format only after confirming it for the registered feed, while Google receives data through Merchant Center.
What if I skip AI-image provenance metadata?
The image won't meet Google's stated requirement for generated product images. Preserve the embedded tag through image optimization and feed delivery.
How often do AI feed requirements change?
Google and OpenAI publish no fixed schedule for feed changes. Review both specifications at least every six months and sooner after a change log, onboarding notice, or feed error.
