We read the public catalog surface of 814 live WooCommerce stores and scored 56,896 products against what an AI shopping agent needs to list and transact. Two thirds of products carry at least one defect, a sixth cannot be bought at all, and the identifier the whole category is built on is not published on that surface by anyone.
814 live stores of 818 attempted, read from the public Store API on 2026-08-30. The 4 that stopped answering are counted as unmeasured, never as clean.
38,249 of 56,896 products failed at least one check. The remaining 18,647 (32.8%) passed every check the public surface can see. Defects cluster rather than scatter: the median store fails one check per product, and only 53 stores of 814 were clean end to end.
A missing image or an unbuyable price is not a quality problem, it is an exclusion. On the strict reading 11,842 products (20.8%) carry at least one excluding defect. On the conservative reading, which drops zero-priced products the platform still considers purchasable because most of those are deliberate free downloads, it is 9,762 (17.2%). Both readings are published because the gap between them is the honest measure of what a rule can know.
9,070 products carry `is_purchasable: false` on the public surface. That is not our inference, it is the platform's own verdict, published next to the product an agent is being asked to buy. It corroborates 78.9% of our price defects, and it also catches 762 products our price rule does not test at all, so our figure is a floor.
28,871 products publish no brand and no manufacturer part number, so there is nothing for an agent to match them against a product it already knows. This is the single largest defect class in the census and it is the one nobody can fix with code, because deciding what a product IS is authorship.
Every feed specification in this category asks for a GTIN: the barcode number GS1 issues against a real product. It is how an agent knows that the thing in your catalog and the thing in a price comparison are the same object.
WooCommerce core holds it. There is a field for it, it persists to a meta key, and it is indexed for lookup. The wc/v3 admin API returns it. But the Store API, which is the unauthenticated read surface that powers the cart blocks and is what an agent can actually reach, has no property for it. Not rarely, not on old versions: there is no `global_unique_id`, `gtin`, `ean`, `upc`, `isbn` or `barcode` property in the product schema on trunk.
So the defect cannot be measured from outside, and we excluded it from every rate in this census rather than let it fire on 100% of every catalog as an artefact of the API. That exclusion is published rather than quietly applied, because a muted finding is indistinguishable from an absent one.
The interesting part is what it means for a merchant who has done everything right. Fill in the GTIN field, and the surface an agent reads still does not carry it.
We then checked the other direction, on product pages rather than the API, because WooCommerce emits a GTIN into page structured data when the merchant has set one. Of 2,176 product pages carrying structured data, 36 published a GTIN. That is 1.7%, across 14 of 576 stores. On the same pages, 82.4% published a stock keeping unit, 16.2% a brand and 1.6% a manufacturer part number.
1.7% is a floor and not a ceiling. A merchant could hold a GTIN in a plugin field that never reaches page markup, and we would not see it. Rates are over pages carrying Product JSON-LD, never over all pages fetched. A theme that suppresses core markup is an unmeasured page, not a missing value.
| Check | Products | Share | Severity | Fixable unattended |
|---|---|---|---|---|
| Neither brand nor MPN present | 28,871 | 50.7% | degrades | judgement |
| No price on any variant | 10,536 | 18.5% | excludes | blocked |
| No usable description | 7,938 | 14% | degrades | judgement |
| Title all-caps or promotional | 5,833 | 10.3% | degrades | mechanical |
| No product type or category | 3,572 | 6.3% | degrades | judgement |
| No product image | 1,873 | 3.3% | excludes | blocked |
| Description is markup or entities once stripped | 1,134 | 2% | degrades | mechanical |
| Price present but not a clean decimal | 2 | 0% | excludes | mechanical |
Excluding means an agent skips the product entirely. Degrades means it can still be listed but ranks or reads worse. Of 59,759 defects, 20.8% are excluding. 53 of 814 stores (6.5%) had no defect on any product measured.
The census came out of a build decision with one gate on it: what share of real defects can a deterministic rule fix with no human deciding anything? Above roughly 60% there is a product in it. Below 40% there is an agency, competing on price against tools that already start at about thirty Australian dollars a month.
The answer over these 59,759 defects was 11.7% mechanical, 67.6% needing a human decision, and 20.8% not fixable from the outside at all. It survives every hostile and every generous reading of its largest rule, including deleting that rule outright. So there is no product, and the scanner stays an internal tool.
The defects are real and they are large. Our ability to fix them unattended is what failed the test, and those are different findings. The first is the one worth publishing.
We read the first page of each catalog, capped at 100 products. 440 of 814 stores hit that cap, so their tails are unmeasured. If defect rates differ between the front and the back of a catalog, and there is a reasonable argument that they do, this figure moves.
Candidates were found by URL shape, using two default WooCommerce taxonomy paths, rather than by anybody's list of shops worth looking at. An earlier attempt built from recognisable brands returned one readable store in fifty, because recognisability correlates with bot protection. Footprint search returned a population dominated by small merchants at a 50.4% hit rate. That is the population this census describes, and it is not a random sample of all WooCommerce.
4 stores answered the probe and then did not answer the scan. They are reported separately and excluded from every denominator. A fetch failure counted as a pass is how a catalog audit flatters itself.
Nothing here establishes that fixing these defects sells anything. No published evidence we have found ties a conformance rate to a transaction rate in agentic commerce, and we are not going to be the first to assert one. This is a measurement of what the surface carries, and that is all it is.
Surface: WooCommerce Store API v1 (/wp-json/wc/store/v1/products), public, unauthenticated. This is the read side that powers the cart and checkout blocks. It is unauthenticated by design, ships enabled in modern installs, and shows the published catalog exactly as a shopper or an agent sees it, which is the surface under audit.
Population: URL-footprint search on WooCommerce default taxonomy bases (/product-category/, /product-tag/) via a public scan index. 1,624 candidates, 818 answering the Store API, 50.4% hit rate.
Measured: 814 stores of 818 attempted, 56,896 products, on 2026-08-30.
Checks: twelve rules drawn from published feed specifications, the Google Merchant product data requirements and schema.org/Product. Each rule declares its own severity and whether a machine could fix it unattended. Three rules are excluded from every rate here because the Store API cannot observe them, and they are listed with the evidence in the dataset.
Cost to run: nothing. Every endpoint read is public.
The full aggregate dataset is published at https://ironbarktech.com.au/research/woocommerce-agentic-commerce-census.json. It is anonymous: no store is named and the raw catalogs were never published. Quote it with attribution to IRONBARKTECH and a link to this page. Questions and corrections to hello@ironbarktech.com.au, and a correction that moves a number will be published on this page with its date.