A price that is not in the HTML
An agent comparing you against another store on price has nothing to compare. You are not beaten; you are skipped.
An agent view is the version of a web page an AI shopping agent actually receives: the raw HTML a server returns, read as text, with no JavaScript run and none of the layout a browser draws. It is usually far sparser than the page a person sees. Where a price, a size or a stock status exists only after the page runs, the agent never gets it at all.
One page, read once, from our static egress addresses. We honour robots.txt and stop if it tells us to.
An agent comparing you against another store on price has nothing to compare. You are not beaten; you are skipped.
If the options a shopper can choose are built by a script, an agent asked for a medium in navy cannot tell whether one exists.
Without an availability field, a sold-out product and a live one read identically. An agent that recommends the wrong one stops trusting the source.
Plus robots.txt, llms.txt, your product feed, and any policy page that page links to. The number of requests is a constant. It does not grow with your catalogue, and no URL is ever discovered from another page and followed.
A published user agent and a fixed set of static addresses, on every request. Both are described on our agent page.
robots.txt is fetched and honoured before anything else, and when it stops us the page says so plainly instead of reporting the store as broken.
Every result ends with the list of things one page cannot answer. A confident all-clear that was never checked is the worst thing a tool like this can produce.
The HTML your server returns, before a browser runs any JavaScript. Most agents read the response, not a rendered page. Anything your store draws client-side is not there when the agent looks: a price injected by a script, a variant picker built at runtime, stock loaded from an API. This tool shows you that response as text.
No. This reads one page and four fixed files: robots.txt, llms.txt, your product feed, and any policy page that page links to. The scan reads your sitemap, several products, your policies and your category structure, and then drives a real browser through the buy path to the payment step. The rules that turn observations into findings are the same in both, so the two never disagree. This one just sees less, and says which parts it did not look at.
Yes, and it is checked first. If your robots.txt disallows our agent we stop and tell you we stopped, rather than reporting your store as broken. A rule that disallows one path is not treated as a defect. Plenty of stores disallow /cart or /search deliberately and correctly.
One request per surface, from a published user agent and a fixed set of static IP addresses. Our agent page lists both, and the addresses are also at /agent/ips.json. No JavaScript is run, no forms are submitted, nothing is added to a cart, and the number of requests is a fixed constant that does not grow with the size of your catalogue.
You can check any public page, the way any page-speed tool works. Everything shown comes from what that store publishes to anyone who asks, and we cap how often any one storefront can be checked, however many people ask for it.
Almost always because it is rendered by JavaScript. The tool reports separately on whether the price is in your schema.org markup, in your product feed, anywhere in the HTML at all, and in the readable text. Those four answers together usually locate the problem exactly.
What happens after the page loads: the failure modes this tool cannot see, because finding them needs a browser.
Everything above, in the order an agent hits it, with what to fix first.
The same question end to end, rather than one page at a time.
What the gaps above are plausibly worth per month, on your own revenue figure.
This tool reads one page. A scan walks the store the way an AI shopper would, through all four stages, and reports where it stalls. One free scan per store, per email address, every 30 days.