Nexyra Lab: an agent readiness case study on our own headless Shopify store
2026-08-02
Readiness score
Before
74
After
92
- Discovery63→100(+37)
- Crawl access100→100(+0)
- Product schema76→76(+0)
- Merchant data100→100(+0)
- Content quality13→87(+74)
Both scans are 5 page samples, the size every free scan on this site uses, run 16 minutes apart on 2026-08-02. Unlike the BeadnFloat study, before and after here are like for like on sample size as well as on the store.
This is our own store
Nexyra Lab supplies research compounds to laboratories. The storefront is headless Shopify: a Next.js front end we write, with Shopify as the commerce back end behind it. We own it. This is not a client engagement, it is the second dry run of the done for you tier, on a different platform and a much more constrained catalog than the first. 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 74, grade C, scanned 2026-08-02 13:03 UTC.
Most of this score already existed
Three of the five categories needed nothing. Crawl access was already 100: every AI crawler allowed, no blanket disallow, HTTPS, homepage inside the response budget. Merchant data was already 100. Product schema was already 76, and it finished at 76, because the two checks holding it there are ones we declined to fake.
That is worth saying plainly rather than letting the headline number imply otherwise. 74 of the available points were on the board before this engagement started, and 18 of the 26 remaining were in two categories. This was not a rescue. It was a store that was well built, fully open to agents, and still could not answer the questions an agent asks.
What it was invisible on
- Discovery, 63 of 100. llms.txt existed. There was no llms-full.txt, no agents.md, and no manifest at /.well-known/ucp. The sitemap was valid and exposed product URLs, which was the part already working.
- Content quality, 13 of 100. Product titles and descriptions, as an agent reads them, were near enough absent. The detail below is the heart of this study.
The scanner says Shopify. The store is not a Shopify theme.
Sextant fingerprinted this store as Shopify, and it was right to, and it
could not have known better. We checked which of its six Shopify signals
actually fire on the live homepage: exactly one. cdn.shopify.com appears
207 times, all of them product images. There is no window.Shopify global,
no shopify-section markup, no /cdn/shop/ path, no myshopify.com
hostname. Every fingerprint that would indicate a Liquid theme is absent, and
the only one present is an image host that a headless store keeps using
precisely because there is no reason to move the images.
From outside a store, headless and Liquid are not reliably distinguishable, and our own scanner does not pretend otherwise. We are flagging it here because it changes how you should read the rest of this page: the scanner would fingerprint a Liquid theme merchant identically, and some of what follows is not available to them.
What was fixed
The three missing discovery files. llms-full.txt, agents.md and a
manifest at /.well-known/ucp, all served as route handlers and all built
from the store's real catalog, policy and company data.
A shadowing bug that would have silently reverted the catalog. A static
public/llms.txt, last updated 2026-06-29 and listing 16 products, was
sitting in front of the dynamic /llms.txt route that lists all 20. Next.js
checks the public folder before the app router, so the stale file was winning
and nobody had noticed. Deleting it was a one line change and it was the only
thing on this list that was actively getting worse over time.
Product JSON-LD names and descriptions, rebuilt from a verified facts module. This is the whole of the content story below.
Content quality, 13 to 87
The cause was one template string. Every product's JSON-LD carried the same
generic description, and Sextant's parser prefers a JSON-LD
Product.description over page body text when it measures description
length, so a short blurb was masking substantially longer real copy on the
page. The title check has the same shape: it reads Product.name, not the
HTML title tag. Both checks were reading a template, not the store.
The fix was a single module that builds both fields from the product's own record: CAS number, molecular formula and weight, physical form, composition, solubility, storage, shelf life, real stocked sizes, live price, and the batch specific Certificate of Analysis where one exists. Everything the discovery files and the manifest say about a product now comes from that same module, so the four surfaces cannot drift apart from each other.
The clearest example is Bacteriostatic Water. The old template described it as a lyophilised peptide powder at 99 percent purity by HPLC. It is a sterile solution and always has been. It now carries a 108 character name and an 813 character description built from its own spec table, and it correctly says sterile solution. That is not a scoring fix that happened to be true. It is a correctness fix that happened to score.
Seven of the 20 products came up short of the 500 character threshold on the first pass. None of them were padded. Each was brought up by adding spec fields that already existed in that product's own record and had simply not been surfaced. The floor was raised with real data or not at all.
This is the part no app installs. A plugin can emit a schema field; it cannot know what your product is. That is the honest argument for a done for you tier existing alongside a subscription that watches for regressions: the watching can be automated and the writing cannot.
A regulated catalog has a lower content ceiling
This is a research use only supplier, so every description was written with no therapeutic claim, no dosage guidance and no benefit framing, and every existing RUO disclaimer was preserved on every page that carried one. Rather than check that by eye across 20 products, we ran all the generated copy through the store's own compliance scanner: zero structural flags and zero publish gate signals, across the whole catalog.
The finding worth publishing is the constraint itself. An unregulated catalog can describe what a product does for the person buying it, which is most of what fills 500 characters easily. This one can only describe what the product is. Identity, composition, form, purity, storage, packaging. That is a real ceiling, and a regulated catalog will hit it sooner than a general one will.
Where that constraint turned into an advantage was in the discovery files, which we used to state what is not known rather than omit it. 13 of the 20 products have a published batch certificate; the other 7 say so in plain text instead of leaving a reader to assume. The manifest declares that no GTIN and no rating data exist for this store, as explicit fields, so an agent does not go looking for them or infer them from silence. The agents.md file draws the distinction between a purity figure measured from a batch certificate and a purity figure that is only a manufacturing specification, and tells agents not to present the second as the first.
None of that is scored. An absence stated plainly is still better than an absence, and it is the same discipline as declining to fake the two checks below.
What a Liquid theme merchant can and cannot replicate
Root path files: harder on standard Shopify. agents.md and
/.well-known/ucp have to be served from the store's root. Here that is a
file in the app and nothing else. On standard Shopify you do not control the
root path, so this needs an app or a reverse proxy in front of the store.
Achievable, but it is infrastructure work, not a content change.
Product JSON-LD: possible, but you are overriding rather than generating. On a Liquid theme the Product schema comes from the theme's own template. A merchant can edit theme code or install an app to change it, so this is not closed to them. The difference is that it is a template edit constrained by what Liquid exposes, rather than app code reading directly from the product data layer. The single module feeding four surfaces from one source, which is what stops these files drifting apart here, is a headless shape.
The catalog content work: identical for everyone. This is the important one, because it is the largest single movement on this page. Content quality 13 to 87 is not a headless win. There is nothing about the platform that made it possible and nothing about a Liquid theme that would prevent it. Any merchant on any platform can do this work, and no merchant on any platform can automate it.
What was deliberately left, and why
Two checks stayed failed because the data to pass them honestly does not exist:
- GTIN. Shopify's barcode field is not populated for any product in this store. Checked against the data layer directly, not assumed absent.
- AggregateRating. Zero reviews. The review platform is installed and returns an empty set, and the product pages say no reviews yet.
Both could be faked in an afternoon. Neither was, for the same reason as last time: a fabricated identifier or rating is the exact failure this audit exists to catch, moved one level up.
Content quality finished at 87 rather than 100 for a third reason, and it is a genuine gap rather than a principled one. The image check wants three detectable product images and this catalog exposes two, which on inspection turn out to be the same photograph served from two different hosts. Exposing more markup would not fix that. It needs photography that has not been taken, and we are not going to describe an unfixed thing as a decision.
The result
74 to 92, grade A, scanned 2026-08-02 13:19 UTC. C to A. Discovery 63 to 100 and content quality 13 to 87 account for essentially all of it. Crawl access and merchant data were already at 100 and stayed there. Product schema did not move at all, and every point still missing from it sits behind the two checks we declined to fake.
Both figures are 5 page samples, the size every free scan here uses, taken 16 minutes apart on the same day against the same store.
The pattern from the first study held on a second platform. The technical work was real but small, and most of it was already right before we started. The movement was in the two things nobody installs an app for: publishing machine readable answers, and writing down what your products actually are.
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.