BeadnFloat: an agent readiness case study on our own WooCommerce store

This is our own store

BeadnFloat sells hand poured soft beads for salmon and steelhead fishing on BC's coast and interior rivers. We own it. This is not a client engagement: it is a dry run of the done for you tier, on our own catalogue, so we know what the work actually costs before we sell it to anyone else. Nothing below describes revenue, traffic, or conversion, because we did not measure any of that and would not claim it from a schema fix regardless.

An agentic commerce audit of the store came back 47, grade F.

What the store was already doing right

Before touching anything, crawl access scored 94 of 100. GPTBot, ClaudeBot, OAI-SearchBot, PerplexityBot and Google-Extended were all let in, robots.txt carried no blanket disallow, the site ran on HTTPS, and the homepage responded fast. Nobody had written a defensive robots.txt against AI crawlers, and nobody had to fix one.

That matters for the thesis here more than any of the numbers that follow: a store can be fast, well built, and completely open to agent traffic, and still be functionally invisible to it. Being crawlable is necessary and it is nowhere near sufficient. Everything wrong with this store was downstream of crawl access, not instead of it.

What it was invisible on

• Discovery, 38 of 100. No llms.txt, no agents.md, no manifest at /.well-known/ucp. The sitemap was valid, which was the one thing here already working.
• Product schema, 32 of 100. One product, Natural Rod Huggers, carried no Product JSON-LD at all, which took its own availability, breadcrumb, offer and SKU checks down with it. Every sampled product had an empty sku field.
• Merchant data, 40 of 100. Shipping and returns terms existed only as prose on linked policy pages. No FAQPage anywhere on the site.
• Content quality, 13 of 100. Most product titles and descriptions were short, generic, and did not carry the attributes that would let an agent match a specific bead to a specific fish, water condition, or season.

Before figures throughout are from a 5 page sample, the same sample size every free scan on this site uses. After figures are measured against all 46 published products, not a repeat of the same 5, because the real question was whether the fix held across the whole catalogue.

The one broken product, and why it was broken

Natural Rod Huggers was missing its JSON-LD entirely, not just missing fields. The product data was fine on every direct check against the store API. The actual cause was a caching bug: a transient upstream failure had been cached as a permanent "this product does not exist," and unlike the category and listing reads, the single product read had no fallback for that case. The fix was giving it the same snapshot fallback the other reads already had, so a future blip degrades to slightly stale data instead of a missing page.

This is worth naming because it is a different category of problem to everything else on this list. Nothing was wrong with the product. Nothing was wrong with the schema code in the abstract. One code path had a real bug, and it took an entire product off the map for any agent reading structured data.

What was fixed

• llms.txt, llms-full.txt, agents.md, and a manifest at /.well-known/ucp, generated from the store's real catalogue and policy data, not written by hand once and left to drift.
• The root cause above.
• SKU (a real store prefix convention where none was set), GTIN or MPN checked and confirmed genuinely absent, MerchantReturnPolicy and OfferShippingDetails structured data from the store's own published terms, and FAQPage schema rendered visibly on the page, not schema only.
• Titles and descriptions rewritten across all 46 products, built from the store's own real attribute and species-match data: which fish, which water condition, which real stocked sizes. Titles vary in construction even within a colour family, and every claim traces to a real data source. Nothing was invented to hit a character count.

What was deliberately left, and why

Two checks stayed failed because the data to pass them honestly does not exist:

• GTIN or MPN, 0 of 46. No barcode or manufacturer part number field exists anywhere in the store's product data. Checked directly against authenticated product records, not assumed absent.
• AggregateRating, 0 of 46. Zero real reviews, store wide.

Both could be faked in an afternoon. Neither was, because a fabricated identifier or a fabricated rating is worse than an honest gap: it is the exact failure mode this whole audit exists to catch, just moved one level up.

A softer version of the same choice shows up in content quality, which still sits at 67, not 100. Six of the 46 products, five soft worm colours and one rod hugger, kept warn on description length. Their real attribute data cannot support 500 characters without inventing specifics. Rod huggers in particular: one colour variant and two real facts, two per pack and an adjustable band, is the entire truthful content budget for that product. The shortest description we shipped runs 229 characters. That is the finding, stated plainly rather than buried in a footnote: sometimes the honest fix is a shorter page, not a longer one.

Performance

The scan measures homepage response time against a 3 second budget, and this store's early readings bounced between roughly 2 seconds and just over 4, which is the kind of swing that can flip a single scan's grade depending on when it lands. We measured this properly rather than guessing at a fix.

Two distinct, reproducible states exist. Warm, meaning the site's data cache and the serverless function serving it are both already active: 1.5 to 1.9 seconds, comfortably inside budget. Cold, meaning a fresh cache miss or a freshly started function instance: 3.6 to 3.7 seconds, which matches the original worst case almost exactly.

We looked for a cheap fix and did not ship one, because we did not find one that was actually a fix rather than a plausible looking gesture. The store's hosting spreads function instances across roughly nineteen edge regions; a warming mechanism that only touches one region does not solve cold starts in the other eighteen, and a bot request can land in any of them. That is a hosting architecture characteristic, not a defect in this store's code, and we are stating that directly rather than either claiming a fix we did not make or quietly leaving the question unanswered.

The result

47 to 89. F to B. Crawl access, discovery and merchant data all reached 100. Product schema moved from 32 to 76, held back entirely by the two checks we declined to fake. Content quality moved from 13 to 67, held back by six products where a short, honest description was the correct answer, not a padded one.

The work here was catalogue and content work almost everywhere it mattered. Nothing here required a new platform, a migration, or a plugin. The store was already fast, already crawlable, and already built well enough that none of that needed touching. What it lacked was structured, machine readable answers to the questions an agent actually asks, and that is a different kind of project than the one "add an app" implies.

If you want to see where your own store lands, the scan is free. If you would rather we did the fix work the way we did it here, that is the done for you tier.