Merchant feed readiness checklist

Use this as a review record

Use this checklist before submitting a product feed to an AI merchant program, and again after any change to pricing, inventory, or catalog structure. It reviews whether the feed is correct and consistent with what a shopper and a crawler can see. It does not assess merchandising, bidding, or whether a program will accept the business.

Read product feeds for AI answer engines first for what each company accepts and which fields are required. Mark each check as applicable, not applicable, complete, gap, or needs confirmation, and record the evidence, the owner, and the recheck trigger for every gap.

Run the checks against a sample rather than the whole catalog. Choose products that span your structures: a simple item, a multi-option variant group, a sale item, an out-of-stock item, a preorder, and anything with unusual shipping or returns terms. A feed that is correct for those is usually correct at scale, and a feed that fails one of them will fail thousands of rows.

Choose what to resolve first

Start with a material disagreement between the feed and the live page on price, currency, availability, or identifier. Those errors are visible to a shopper and, in a checkout-enabled program, can produce a failed transaction. Repair the system that owns the fact, republish the dependent outputs, and recheck before moving on.

When no material conflict is open, complete the baseline feed checks. Program-specific attributes and eligibility flags can wait until the baseline is accurate, because an eligibility flag on wrong data only distributes the error faster. Building or integrating checkout can wait entirely; it does not block discovery.

The review is sufficient for submission when every applicable baseline check has an observable result, each material value has a named owning system, and the sampled products agree across the feed, the page, and the markup.

Review register

Copy this register into the system that owns the work.

Establish ownership before checking values

1. Each material value has one owning system. Price, currency, availability, variant selection, and identifiers name the platform, PIM, or ERP that holds the authoritative value. The page, the structured data, and the feed are outputs of that system.
2. The regeneration trigger is known. The record states what causes the feed to rebuild: a schedule, a price or stock event, or a manual export. A feed that only rebuilds on a schedule will be wrong between price changes.
3. The catalog scope is deliberate. The feed contains the products intended for the program, and excludes discontinued items, internal SKUs, test products, and anything the business cannot fulfill.
4. Someone owns the feed. A named person or team is accountable for submission, error reports, and the response when a program flags a product.

Check the baseline fields

5. Identifiers are stable and unique. Every row has a unique item identifier, and no identifier has ever been reused for a different product.
6. Identifiers survived export as strings. GTIN, UPC, MPN, and SKU values retain leading zeros and have not been converted to scientific notation by a spreadsheet step.
7. Titles and descriptions are within limits and factual. Titles identify the variant where relevant. Descriptions describe the product rather than repeating marketing copy or keyword lists.
8. URLs are public, absolute, and specific. Each product URL returns a successful response without a session, uses HTTPS, and lands on the variant rather than a parent listing or a redirect chain.
9. Image URLs resolve directly. The main image URL returns the image itself, is publicly accessible, and shows the variant described by the row.
10. Brand and seller are real names. Neither field contains a placeholder, an internal code, or a category label.
11. Price uses the required format. The amount and the ISO 4217 currency code follow the receiving program’s format, and the currency matches the market the row targets.
12. Availability uses an accepted value. The status is one the program defines, and it reflects sellable stock rather than a default that keeps the product visible.
13. Encoding and file format are correct. The file is UTF-8, uses an accepted format and compression, and parses without row-level errors.

Check variants and conditional fields

14. Variant groups are structured correctly. Variant rows share a parent group identifier that differs from the row identifier, carry the variation flag the program requires, and map each option name to its selected value.
15. Conditional units are present. Dimension values include a dimensions unit; weight values include a weight unit.
16. Category, condition, and attribute fields are accurate. Product category, condition, material, color, size, gender, and age group describe the actual item where supplied.
17. Sale pricing is consistent. A sale price is lower than the regular price in the same currency, and the sale dates match what the page shows.
18. Shipping and returns match published policy. Shipping costs and regions, return acceptance, return window, and return policy URL agree with the customer-facing policy.
19. Ratings and review counts come from real reviews. Values match what the page displays and are not aggregated from a different product or a parent listing.

Reconcile the feed with the page and the markup

20. Price agrees across all three surfaces. The live page, the page’s Offer markup, and the feed row show the same amount and currency for each sampled product.
21. Availability agrees across all three surfaces. A product marked in stock in the feed is purchasable on the page.
22. Identifiers agree across all three surfaces. The GTIN or MPN in the feed matches the value in the page’s structured data and any value shown to shoppers.
23. The variant that the URL opens is the variant the row describes. Following the feed’s URL selects the described option combination.
24. A disagreement was traced to a cause, not patched. Where values differed, the record names which output failed to regenerate and what changed, rather than recording a manual correction to the feed.
25. The structured data was validated after the repair. The corrected page passes a parser and the relevant consumer test. Use validate JSON-LD on a live page for the procedure.

Check program-specific attributes

26. Market eligibility was confirmed against current documentation. The countries, languages, and currencies the program supports were checked at the source, not inferred from a summary or a previous project.
27. Eligibility flags are set deliberately. Search, ads, and checkout eligibility carry intended values, and the defaults were read rather than assumed. A checkout flag is set only where checkout is genuinely intended and permitted.
28. Required policy URLs are public and current. Privacy policy and terms of service URLs resolve publicly and describe the selling entity named in the feed.
29. Checkout onboarding is understood as separate work. The record notes that setting an eligibility flag does not complete checkout integration, and names who owns that project if it is planned.
30. Merchant-of-record and payment responsibilities are documented. The business has confirmed which party is merchant of record for each program it joins, and legal or finance has reviewed that position.

Establish maintenance triggers

31. A recheck is scheduled for each change type. Price changes, stock changes, catalog additions, URL structure changes, platform migrations, and policy updates each have a recheck owner.
32. Feed error reports are monitored. Someone reads the rejection and warning reports each program produces and routes them to the owning system.
33. Specification changes are reviewed. The programs version their specifications, and a named person rechecks the primary documentation on a stated interval rather than after a failure.

What this checklist does not establish

A complete feed does not place a product in an AI answer. Each program selects what to show, and none of them publishes a mechanism by which feed completeness produces placement. Acceptance into a merchant program is not a citation, a ranking factor, or evidence of visibility.

The checklist also does not confirm eligibility. Several of these programs are gated by application, approval, or market, and a merchant can complete every check here and still not be accepted. Treat the baseline feed work as useful on its own terms, because it improves the accuracy of product data everywhere it is consumed, and treat program participation as a separate and conditional outcome.