Insight
How to choose an agent-readiness audit
Choose an agent-readiness audit by verifying seven things: it measures the HTML your server actually delivers, reports "not verifiable" separately from "missing", treats a blocked measurement as a finding, walks complete buying paths rather than scanning the homepage, checks that your policies resolve to one version, delivers prioritized tasks with pass criteria rather than a score, and leaves you a test you can rerun yourself. In our June 2026 measurement, 21 of 89 German shops (23.6%) blocked the measurement agent outright.
How we know this: methodology behind this guide
Written by Stephan Lucka, founder of agenticux.de, based on two measurement runs I ran and published.
June 2026 run (published June 30, 2026): 89 German online shops across several industries, measured with an agent that reads served HTML, as agents without full browser execution do. 68 were machine-reachable, 21 blocked the agent. Of the 68 reachable: 41 product schema in served HTML (60%), 53 a reachable or declared sitemap (78%), 65 a price signal in HTML (96%), 53 a machine-readable add-to-cart signal (78%), 23 an llms.txt (34%).
July 7, 2026 run: 100 mid-sized German fashion shops. 90 were reachable, 10 blocked the agent. Of the 90: 70 product schema (78%), 83 a sitemap (92%), 87 a price signal (97%), 75 an add-to-cart signal (83%), 55 an llms.txt (61%).
One measurement rule doubles as my first test for any vendor: a signal that could not be verified was never counted as missing, and blocked shops were reported separately. Full data and criteria: agenticux.de/report.
The 7 criteria for evaluating an audit vendor
1. It measures the HTML your server delivers
Why it matters: Many shopping agents and AI crawlers do not execute JavaScript, so a shop can look complete in Chrome while the served HTML is a template with no price, no variants, no product data. In our June run, 22 of 68 reachable shops could not be conclusively checked for product schema because the data appeared only after JavaScript ran; a rendered-browser audit would have marked all 22 as fine.
Test it yourself (five minutes): Open a top product page, right-click, View Page Source (the raw HTML, before JavaScript), and search for "schema.org" and your price, or paste the URL into validator.schema.org. Good looks like: a Product node with name, price, and availability in the raw source. A near-empty app shell means agents that skip JavaScript see nothing.
How to verify the vendor: Ask whether they execute JavaScript when measuring and report both states. A good answer shows served HTML and rendered DOM side by side.
Red flag: Browser screenshots as evidence. That proves the page works for humans, which you already knew.
2. It reports "not verifiable" as its own category
Why it matters: This is the honesty test. When a check cannot complete, a vendor has a commercial incentive to count it as a failure, because a bigger problem sells a bigger fix. In both published runs, inconclusive checks (22 in June, 17 in July) were disclosed as inconclusive. In June, "60% had verifiable schema" and "only 5 shops verifiably had none" are both true; a serious report gives you both.
How to verify: Ask what happens in the report when a check cannot complete. A good answer names a separate category with a count and never folds it into the failure rate.
Red flag: Dozens of checks and zero "unknown" results. Real measurement always has residue.
3. It treats a blocked measurement as a finding, not as missing data
Why it matters: In the June mix, roughly one in four shops blocked the measurement agent entirely; in July fashion, 1 in 10. A block is the most consequential audit finding, because a blocked request never loads your tag scripts, so the failure is invisible in your analytics. A WAF dashboard may show blocked bot traffic, but it cannot show which recommendation the block cost you.
Test it yourself: Load your shop from a network outside any allowlist (a mobile hotspot works), or check whether your bot-protection default blocks an "AI agents" category. Good looks like: you can name which agent categories your setup allows.
How to verify: Ask how they detect blocking and whether they test your production configuration unwhitelisted. A good answer reports a block as a headline result.
Red flag: A vendor who asks you to whitelist their crawler before measuring. That deletes the most valuable data point.
4. It walks complete buying paths end to end
Why it matters: An agent arrives with a task: find the right variant, verify the claim, check the delivery rule, move toward checkout. Each step can break independently: a shop can pass a homepage scan and still fail at the cart, where service-level rules or bundle constraints resolve only at the last step. Our worked example cartpilot ("Example - Case study" on the site, not a client result) models this class: product evidence that holds on the listing page and falls apart along the path.
How to verify: Ask which concrete buying tasks they run end to end. A good answer names tasks in your catalog's language ("find a compatible replacement part with express shipping") and shows where in the path each failure occurred.
Red flag: A deliverable organized by page type. Agents fail at decisions, not at pages.
5. It checks whether your rules resolve to one version
Why it matters: This is the failure class no signal check can catch, because every surface looks correct on its own: the product page states one delivery promise, the policy page another, the cart a third. An agent must decide which version to cite; its safe options are the most cautious version, hedging, or routing the buyer to support. Our worked example verity-goods ("Example - Case study"; illustrative, not a client result) models this break, which takes judgment across surfaces to find.
Test it yourself: Put the delivery promise from one product page, your shipping-policy page, and your cart side by side. Good looks like: one value, stated identically in all three. Two different day counts is the contradiction an agent resolves by hedging.
How to verify: Ask whether they compare claims across product page, policies, cart, FAQ, and support content. A good answer shows a claim inventory with source and consistency status per rule.
Red flag: An audit that only validates markup syntax. Schema that confidently states a contradicted value is worse than no schema.
6. The deliverable is prioritized work with pass criteria, not a score
Why it matters: A score tells you something is wrong, roughly how much, and nothing else. Your team cannot ship "62 out of 100". A usable deliverable names the break, the evidence, the task (UX, content, or schema), the owner, and the criterion that defines done, ranked by revenue exposure, because unprioritized reports get a rarely bought category fixed first.
How to verify: Ask for a sample finding. A good one reads like the sample below: evidence, mechanism, task, pass criterion. A bad one reads like a lint log.
Red flag: A 60-page PDF where every finding has the same weight. A long report can still be shallow.
7. It ends with a test you can rerun without the vendor
Why it matters: Every theme update, product launch, and policy edit rewrites the served HTML and can silently reintroduce a break. The durable output is a repeatable set of agent tasks run before every release, ideally in CI; a document alone has a shelf life of one release cycle. On Shopify or Shopware without an engineering team, a documented manual test list counts just as well; the requirement is repeatability.
How to verify: Ask what you run yourselves after the vendor leaves. A good answer is a concrete handover (suite or written checklist) with a defined pass threshold.
Red flag: A retest offer of "book us again next quarter" with nothing in between. That is a subscription dressed as an audit.
DIY checklist vs automated tool vs founder-led audit
All three are legitimate. Each has limits worth stating plainly.
| DIY checklist | Automated score / tool | Founder-led audit | |
|---|---|---|---|
| What it catches | Gaps you know to look for: missing sitemap, no llms.txt, no visible price | Machine-readable signals present or absent, at scale, over time | Path breaks, cross-surface contradictions, wrong priorities, and blocks you cannot see from inside |
| Evidence quality | Depends on your own rigor | Consistent but shallow: counts signals, cannot judge value correctness or consistency | Task-level: which step of which buying path failed, and why |
| Speed and cost | Hours; your time | Minutes per run; low, often subscription | Days to weeks; the highest of the three |
| Limits | You can only check what you know to check; served-HTML vs rendered-DOM gaps are hard to spot manually; no baseline | Ask to see an "unknown" category in a real report; distrust the trend line if they cannot. Misses contradictions where each surface is individually valid; outputs a score without a work plan | Limited capacity (one person, few slots); price excludes very small shops; a single perspective; no substitute for continuous monitoring, hence criterion 7 |
The honest sequence: a checklist to orient, an audit to find and rank the real breaks, then its repeatable test, plus optionally a tool against drift. A tool score used as an audit misses the expensive breaks: blocks, contradictions, late-resolving rules.
What a real deliverable contains
A finding you can act on has five parts: break, evidence, mechanism, task, pass criterion. The example below is modeled on our three published worked examples, cartpilot, verity-goods, and northstar, each labeled "Example - Case study" on the site. It is an illustrative scenario, not a client result.
> Finding: variants without an anchor (severity: high, affects top revenue category)
>
> Evidence: Product pages name a "Pro" version in marketing copy; the served HTML never states which SKU that is or how variants differ on voltage, fit, or capacity. In replayed tasks, agents chose between variants on shipping speed, often picking one incompatible with the buyer's system.
>
> Why an agent breaks here: The distinguishing facts exist only as prose and images. An agent that cannot disambiguate variants either guesses or abandons the recommendation.
>
> Task: Introduce ProductGroup markup with variesBy for the variant axes, plus per-variant Product nodes carrying the distinguishing properties as structured values. Owner: engineering; content supplies the per-axis facts.
>
> Pass criterion: An agent task ("find the 110V variant compatible with system X") completes without inference across the category, verified before release by the handed-over suite or manual checklist.
A full deliverable is a ranked list of findings in this shape, plus the claim inventory from criterion 5 and the test handover from criterion 7. A vendor sample that reads like a settings checklist is a tool report at consulting price.
What it costs and what drives the price
I am not publishing a price table, because scope moves the number more than any rate card. Check any quote against these drivers:
- Buying paths in scope. Each end-to-end task is measured and documented separately; three paths cost less than ten.
- Catalog complexity. Many variant axes and compatibility rules mean more evidence work, independent of SKU count.
- Surfaces in scope. Product pages only, or also policies, cart, checkout, FAQ, support content. The cross-surface work is where the hours go.
- Retest included or not. A verified retest after fixes ship costs more than measurement alone; if it is missing from a quote, ask why.
- Handover and support. Agent tasks handed over as a suite or checklist your team keeps, and findings only versus working alongside your team while fixes ship.
A cheap audit without retest and handover is often the expensive option: you pay the same engineering cost and cannot verify the fixes worked.
Decision framework
Choose a DIY checklist if you want orientation this week and accept you will only find gaps you know to look for. Start with reachability, sitemap, served-HTML price, and product schema, the signals our report measures.
Choose an automated tool if the major breaks are fixed and your problem is drift: you ship weekly and want to notice regressions cheaply. Insist it distinguishes "not verifiable" from "missing", or its trend line will mislead you.
Choose a founder-led audit if you suspect agent traffic is failing where you cannot see it, you need to know which of twenty possible fixes matter, or you face the two problem classes tools cannot catch: blocking (one in four in our June sample, one in ten in July fashion) and cross-surface contradictions.
Avoid any audit right now if you are replatforming next quarter (audit the new platform instead) or nobody has capacity to implement findings. An audit you cannot act on is a document; documents do not change what agents can cite.
FAQ
What is an agent-readiness audit?
A structured measurement of whether AI agents (shopping agents, AI search, assistants) can reach your shop, extract product facts from the served HTML, verify claims and policies, and complete a buying path without guessing. An SEO audit examines pages and rankings; an agent-readiness audit examines tasks and decisions.
Can I just test my shop with ChatGPT myself?
Yes, and you should: asking real buyer questions and reading what gets cited is a useful free signal. It cannot tell you why an answer failed, whether bot protection blocked the fetch, or what the served HTML contained. You see the symptom without the mechanism.
We block bots for good reasons. Is that a problem?
It can be both justified and costly. Bot protection that blanket-blocks agent traffic also blocks agents that would recommend you: in our June 2026 measurement, 21 of 89 shops were unreachable for the measurement agent. Auditing makes the trade-off deliberate; today it is usually a default nobody chose.
Why does my analytics show nothing about agent problems?
Because the failures happen before or without your tracking: a blocked request never loads your tag scripts, and an agent reading served HTML may never execute them. Dashboards can show stable human conversion while agent sessions fail at reachability or extraction. This gap is the strongest argument for an outside-in audit.
Is llms.txt enough to be agent-ready?
No. It is a voluntary convention for agent guidance. Adoption differed sharply between our samples: 34% of reachable shops in the June cross-industry mix versus 61% in July fashion. Different populations, so the gap supports no trend claim. It complements a sitemap and product schema; a blocked shop gains nothing from a perfect llms.txt.
Will optimizing for agents hurt my human conversion?
Largely no: the changes also help careful human buyers. One consistent delivery promise, visible conditions next to claims, explicit compatibility. The work lives in structured data and information architecture; your brand voice stays untouched. Be wary of a vendor who wants to strip persuasion copy; the goal is separating proof from persuasion.
Data: agenticux measurement runs, June 2026 (89 shops, cross-industry, published June 30, 2026) and July 7, 2026 (100 fashion shops): [agenticux.de/report](https://agenticux.de/report). Author: Stephan Lucka.