To audit a WooCommerce catalog for AI readiness, check every product for the machine-readable fields an AI shopping agent gates on — image, price, GTIN, brand, weight and availability — then fix them in the order of which products shoppers actually ask about, not in the order of how broken each one looks. On a default WooCommerce install that audit starts from a predictable place: core emits a Product JSON-LD block with roughly six fields populated (name, description, image, SKU, price, currency, availability) and leaves GTIN, brand, shipping and return data blank on every SKU — so most catalogs fail in bulk, by the same pattern, not one product at a time.
We build Contexta, our WordPress plugin, and its commerce-readiness auditor for WooCommerce taught us a pattern that reframed how we think about this: the products worth fixing first are almost never the ones with the most red flags. A near-complete bestseller missing only its GTIN costs more lost sales than a hand-made item with every field empty that nobody searches for. That gap — between "most broken" and "most costly" — is the reason an AI-readiness audit needs a method, not just a scanner.
What does "AI readiness" mean for a single product?
A product is AI-ready when an assistant can build a complete, unambiguous record of it from machine-readable fields alone — without reading a sentence of your description prose or running your theme's JavaScript. Agents don't shop your page; they assemble a record from your JSON-LD, your product feed and the raw HTML, then decide whether that record is complete and trustworthy enough to surface. Readiness is a property of the record, not the page.
That distinction matters because the prettiest product page can produce a record an agent rejects. If your brand lives only in the product title, your GTIN sits in the SKU box, and your price renders client-side after a script runs, a shopper sees a perfect page and an agent sees a half-empty record. It is also the groundwork for anything transactional you bolt on later: a checkout protocol like Google's Universal Commerce Protocol laid over a catalog agents can't read transacts nothing.
Should you audit a sample of top sellers or the whole catalog?
Audit the whole catalog, not a sample of your best sellers — because AI-readiness failures cluster by cause, not by revenue, so a scan of your top 50 SKUs systematically misses the batches where most of the damage lives. The advice you'll read elsewhere — "score your top products" — hands you the catalog's average, which is the one number that doesn't tell you what to fix.
Failures cluster because of how catalogs get built. A supplier CSV imported before WooCommerce had a native GTIN field has that column blank on every row it added; a category migrated between plugins lost its brand taxonomy in one move; variable products all share the price-range bug while simple products don't. When we run a full pass, the red flags arrive in blocks that trace back to an import, a plugin swap or a product type — never a random scatter. Sample your bestsellers and you'll conclude the catalog is mostly clean while an entire imported batch of long-tail SKUs stays invisible to every agent. Those long-tail products are exactly the ones an assistant reaches for on a specific query, where the record — not the brand name — decides the pick. It helps to know how agents assemble that record from your fields before you decide what "clean" even means.
How do you audit each product — what do you actually check?
For each product, check the six gate fields in the three places an agent reads them — the JSON-LD, the feed and the raw HTML — and score each field present-and-valid, present-but-wrong, or missing, because those three states need different fixes. The trap is treating the audit as a blank-field count: the most common failure we see isn't an empty field, it's a filled one in the wrong format — a GTIN box holding an internal SKU, a "usually ships in 2 days" where an enum belongs, a variable product's price range where a single number should be.
| Image | Price | GTIN | Brand | Weight | |
|---|---|---|---|---|---|
| Bestseller jacket | SKU | ||||
| Imported mug (batch 3) | |||||
| Variable hoodie | range | ||||
| Handmade ring | none | 0 |
Reading the row, not the count, is the point: the jacket is one edit from ready, the mug's whole import batch never populated, the hoodie trips the range bug shared by every variable product, and the ring is genuinely identifier-less and needs flagging as such rather than a faked number. The acceptance criteria for each of the six — what "valid" looks like versus what merely "exists" — is a field-by-field job in its own right, and the product-data checklist agents require lays out the pass test for each one.
Which products should you fix first?
Fix products in order of demand first, severity second — the SKU that costs you a sale is the one an assistant gets asked about and can't answer, which is rarely the one with the most empty fields. Sorting an audit purely by severity floats your worst-scoring products to the top; but a badly-broken product nobody searches for is a wasted afternoon, while a near-perfect bestseller missing one gate field is the fix that pays for the whole exercise.
If the volume tempts you into letting an AI agent apply these edits in bulk over WooCommerce's MCP integration, find out which of its actions merely update and which permanently delete before you hand it a write-scoped key: what an agent can and shouldn't do with your store draws that line.
↑ AI & search demand
High demand, one field short
Quick wins. Cheapest fixes, fastest payback — start here.
High demand, record unreadable
Emergencies. Agents get the query and can't answer it. This week.
Low demand, nearly clean
Leave them. No lift worth the time.
Low demand, badly broken
Batch for later. The severity looks alarming, but nobody's asking.
audit severity →
The demand axis is where most audits go blind — a generic completeness score has no idea which products anyone actually searches for. Pairing each product's audit severity with its real query and impression data from Google Search Console is what turns a scary list of red flags into a ranked work queue. This is the job Contexta's commerce-readiness audit is built to do: it checks every WooCommerce product for the image, price, GTIN, brand and weight an agent needs, verifies format rather than mere presence, and — because it reads the store's own Search Console data — orders the fixes by the products that actually have demand, handing you a per-product fix link instead of a wall of warnings.
How do you fix a product without breaking it again?
Fix each field at its WooCommerce source — the product-editor field, not the schema output — then re-audit that single SKU to confirm all three copies (JSON-LD, feed, HTML) now agree. Editing the rendered schema or patching the feed by hand fixes one copy and leaves the other two stale, which is worse than the original gap: an agent that sees three different prices for one product distrusts the whole record.
The source field is the one place all three copies regenerate from. Put the real barcode in WooCommerce's native GTIN field (added to core in a 2024 release) rather than the SKU box, and on the next build core's JSON-LD, your feed plugin and the page all emit the same value. GTIN is usually the first field worth fixing across the catalog, because it's the join key that lets an agent recognise your listing and a competitor's as the same product — why agents skip products without a valid identifier is the clearest case of a field that's a hard reject, not a soft signal. After each fix, re-fetch the product with a plain request and confirm the value is in the raw HTML too, since several AI crawlers still don't run JavaScript.
How often should you re-audit the catalog?
Re-audit on catalog change events, not on a fixed calendar — the regressions that undo your work enter on a bulk import, a feed re-sync, a plugin update or a theme change, so those are the moments to re-check, not the first of the quarter. A quarterly review is a reasonable floor for a static catalog, but a store that imports stock weekly can regress dozens of SKUs between two calendar checkpoints and not know until the traffic drops.
The honest trade-off is that a full re-audit after every change is impractical by hand, which is why most stores do it once, feel finished, and quietly rot. The realistic cadence is a full pass after any bulk operation plus a spot-check of the products you edited, because the copy most likely to disagree with itself is the one you touched last. A WebP-conversion or CDN change deserves the same re-check, since the re-encode that regresses an image field can also strip the photo's metadata — increasingly relevant now that Google surfaces image provenance in Search. Tie the re-audit to the event that caused the risk and the catalog stays ready; tie it to the calendar and it drifts out of sync with reality between checkpoints.
FAQ
How long does a WooCommerce AI-readiness audit take?
A manual audit runs at roughly a few minutes per product across the three places each field must agree — JSON-LD, feed and raw HTML — so a 500-SKU catalog is a multi-day job by hand, which is exactly why most stores audit a sample instead. The faster path is to scan the whole catalog automatically for present-but-wrong fields, then spend your manual time only on the products the scan flags that also have real demand.
Can I just use Google's Rich Results Test to audit AI readiness?
The Rich Results Test validates one product's JSON-LD at a time, which is useful for confirming a single fix but impractical as a catalog audit and blind to two of the three sources agents read. It checks your schema, not your feed or your raw HTML, and it has no notion of which products have demand — so it tells you a page is valid, not whether that product is worth fixing first.
Which product field should I fix first across the whole catalog?
GTIN is usually the highest-leverage first fix, because it's the identifier an agent uses to recognise your product as the same item a competitor sells, and without it you're dropped from every comparison query. It's also the most commonly malformed field — filled with an internal SKU rather than the real barcode — so a catalog-wide GTIN pass often clears the single biggest gate before you touch anything else.
Does AI readiness matter if my products aren't in a shopping feed yet?
Yes — agents fall back to crawling your product page's JSON-LD and raw HTML when there's no feed, so the same fields decide your visibility whether or not you run a Merchant Center feed. Getting the source fields right first means any feed or checkout protocol you add later inherits clean data instead of propagating the same gaps to a new surface.