The product data checklist AI shopping agents require in 2026

Six fields decide whether an AI shopping agent will consider your product in 2026: a clean primary image, a price, a valid GTIN, a brand, a shipping weight, and an availability status — and each has to be in the exact machine format the agent parses, not just filled in somewhere on the page. The trap every generic checklist misses is that a present-but-malformed field fails silently: an availability written as "usually ships in 2 days", or a GTIN field holding your internal SKU, passes a "the field exists" glance and still gets your product dropped.

We build a commerce-readiness auditor for WooCommerce, and the pattern that surprised us is how rarely the problem is a genuinely empty field. It's fields that are filled but wrong — the right data in the wrong place, the wrong format, or a value that disagrees with the same field in your feed. So this is a field-by-field checklist with the one thing the "add these attributes" lists skip: the acceptance criteria for each field, where WooCommerce actually stores it, and the test that tells you it passes rather than just exists.

Which product fields do AI shopping agents actually require?

Six fields act as hard gates across every major AI shopping surface — Google's Merchant Center feed, OpenAI's Agentic Commerce Protocol spec, and the crawled JSON-LD they all fall back on. Miss one and the agent usually can't place, price, or trust your product enough to surface it. Here's the checklist, but framed around the part that matters — what "correct" looks like versus the malformed version that slips through:

These six are the gate; everything an agent does after it accepts your product — matching it to competitors, aggregating reviews, spec-filtering — is covered in how AI shopping agents read your WooCommerce product data. This checklist is the layer before that: getting into the candidate set at all.

Why does a field that's filled in still fail?

Because agents validate a field's format and its agreement across sources, not merely that something is there — a value in the wrong shape is treated as no value, and a value that contradicts another copy is treated as a reason to distrust the whole record. Presence is the easy 20%; the checklist above is really about the other 80%, which is why an audit that only counts blank fields tells you almost nothing.

The GTIN field is the clearest example. It's the most common malformed field we see, and it's never blank — it's filled with the store's own SKU, because both are "a product number" to whoever set it up. Google Merchant Center runs the GTIN check digit and rejects a number that doesn't compute, so an invented or mistyped identifier isn't a weak signal, it's a hard reject on the surface that matters most. Availability fails the same way: <meta> markup or a feed expects the enum in_stock / out_of_stock, and "usually ready to ship" — however true and human — parses to nothing.

Then there's disagreement, which WooCommerce is structurally prone to because three systems generate the same fact independently: core emits the JSON-LD, a feed plugin builds the feed, and your theme renders the page. A sale price the theme shows live, a JSON-LD offers block still caching last week's number, and a feed on its own sync schedule are three prices for one product — and Google lets merchants refresh price and stock as often as every 15 minutes precisely because agents penalise a feed that lags reality. A field that's present in all three but says three different things is worse than one that's simply blank.

Source of truth

One product field value

price, GTIN, availability…

JSON-LD

the Product block in your page source

Merchant Center feed

the copy Google validates

Rendered HTML

what a no-JS crawler reads

How do you set each of the six fields correctly in WooCommerce?

Each field has one right home in the WooCommerce product editor, and the default install leaves several of them either empty or in a format an agent won't accept. Walking the six in the order the editor presents them:

• Image — the featured image is your primary; make it the clean product-on-background shot, not the lifestyle hero, and keep a version at ~800px or larger. Google Merchant Center rejects promotional overlays, watermarks and borders, and agents render the primary as the thumbnail a shopper clicks.
• Price — set regular and sale price in Product data → General, and confirm your currency is one ISO code store-wide. The work here is reconciliation, not entry: the page, the JSON-LD and the feed must show the same number.
• GTIN — WooCommerce added a native GTIN, UPC, EAN or ISBN field under Product data → Inventory in a 2024 release, so put the real barcode number there rather than in the SKU box. For genuinely identifier-less items (handmade, custom, own-brand), flag them as such instead of faking a number.
• Brand — WooCommerce folded a Brand taxonomy into core in a late-2024 release; as of 2026 you assign it like a category. Older stores that kept brand in the title or a loose attribute need it moved into that taxonomy so it maps to the brand field.
• Weight and dimensions — Product data → Shipping, in the unit set under WooCommerce settings. Agents estimate delivery cost and "arrives by" answers from this, so a blank or zero weight drops you from delivery-time comparisons.
• Availability — Product data → Inventory, using the stock status control so it emits a real enum, not a hand-typed phrase.

Doing this once is simple; doing it across a few hundred SKUs, and re-checking that each field is valid and consistent, is the task nobody finishes by hand. That's the gap Contexta's commerce readiness audit closes — it checks every product for the image, price, GTIN, brand and weight an agent needs, verifies the format rather than just presence, and hands you a per-product fix link instead of a pile of warnings.

How do you verify the six fields pass, not just exist?

Check each field in the three places an agent reads it — the JSON-LD, the feed, and the raw HTML — because a field can be correct in one and wrong in the other two. A single verification pass per product catches the format and consistency failures that a glance at the editor never will:

1. JSON-LD — view the page source or run Google's Rich Results Test and read the Product block. Confirm gtin, brand, offers.price, priceCurrency and availability are present and formatted, not just visible in the page copy.
2. Feed — open Merchant Center diagnostics; it flags GTIN check-digit failures, missing brand and disapprovals field by field, which is the closest thing to an agent's own rejection list.
3. Raw HTML — fetch the page with curl -s <url> and search for the values, because several AI crawlers still don't run JavaScript, and any field your theme injects client-side is absent before extraction starts.

Run those three and you're testing what the agent tests. It's worth spending the effort where agents actually reach you first, which is something AI referral traffic in your analytics will show you before you audit the whole catalog.

Which fields should you fix first?

Fix the hard identity and offer gates before the refinements — GTIN, price and availability first, because those decide whether your product enters a comparison at all, then brand, image and weight, which decide how well it does once it's in. A product with a valid GTIN, a consistent price and a correct stock enum is a candidate even with a plain image; a product with a beautiful image but an invented GTIN and a stale price is invisible on the surfaces that matter.

The honest part is that none of this improves your product page, which is exactly why it gets skipped — the work is unglamorous and lives in fields no shopper ever sees. But an agent chooses among records, and the most complete, correctly-formatted, internally-consistent record tends to take the sale regardless of whose page is prettier. This same fixed data is also the prerequisite for any UCP or ACP checkout you bolt on later — a protocol endpoint over a catalog agents can't read transacts nothing. Start at the top of the six, verify format over presence, and re-check after every feed or plugin change, because the copy that disagrees with itself is usually the one you edited last.