Learn
How to test if AI agents can buy from your store
Test in the order an agent meets your store: whether it can find your catalogue, read your product data as text, work out your true total, and drive your checkout to the payment step. Each test rules something out rather than proving success, because only a completed attempt proves success. Run them in order, since an early failure makes every later result meaningless.
Test your store in the order an agent meets it: discovery, then reading, then comparison, then checkout. Each test rules out a class of failure rather than proving success, and running them out of order wastes the later ones, because a store an agent cannot find is never assessed on its checkout.
Test one: can it find you
Start with your robots.txt. You are looking for a blanket disallow that catches agent user agents, which is a common accident: a rule written to stop training crawlers also removes you from assistant driven shopping. These are separate categories and deserve separate decisions, which robots blocks agent works through.
Then check that your sitemap exists, is current, and actually lists product URLs rather than only collections. If you publish a product feed, check it resolves and is fresh. A feed that has not updated since a price change is worse than no feed, because it is confidently wrong.
Then check your bot protection. This is the bluntest failure in the whole sequence: an interstitial asking the visitor to enable JavaScript and wait is unanswerable to an agent, so every other quality of your store stops mattering. See bot wall.
Test two: can it read you
Open your best selling product page with JavaScript disabled and read what is left. You are checking for four things in words rather than pictures: the price, the availability, the variant options, and the terms that decide a purchase, which means shipping cost and returns.
A price rendered by script is the most common miss, because it looks correct to everybody who checks. Availability is the second. Policies set in a graphic are the third, and they are the one merchants defend hardest, because the graphic looks better. It does look better. It is also not readable, which makes it not a policy as far as an agent is concerned.
If any of this is missing, the fix is usually structured data rather than a redesign. See how to add product schema for AI agents.
Test three: can it work out your real total
This is the test most stores have never run, because it does not feel like a defect. Take a product and work out, using only information published before checkout, what a shopper would actually pay to have it delivered. If you cannot, an agent comparing you against an alternative cannot either.
An agent that has to guess your shipping cost will guess conservatively, and a conservative guess loses comparisons. This is a ranking problem disguised as a checkout problem. How to publish shipping costs machine readably goes into the mechanics.
Test four: can it check out
Open your store signed out, on a narrow mobile viewport, in a fresh session with no cookies. Add a product that requires a variant choice. Then try to reach the payment step without creating an account and without a human resolving anything.
Stop at the payment step. There is no reason to submit a payment to test a checkout, and doing so on a live store creates an order somebody has to unpick.
The failures that show up here are mechanical and specific: a variant picker that only responds to a hover, an add to cart that needs JavaScript, a popup that fires on the cart page, a forced account creation step, a challenge at the payment step. Each one has a page in the stall library describing the mechanism and the change that removes it.
What none of this proves
Passing all four tests means you have removed the failures you know how to look for. It does not mean an agent will buy from you, because you tested the store you expected rather than the store an agent meets: your session, your viewport, your assumptions about which product it would pick.
That gap is the argument for testing with an actual purchase attempt rather than a signal check, which is the distinction drawn in agent readiness score vs purchase attempt. It is also the argument for testing more than once: see how often should you test.
Questions
Do I need special tooling to do this?
Not for the first pass. A browser with JavaScript disabled, a look at your robots.txt and sitemap, and a signed out checkout attempt on a narrow mobile viewport will find most of the blunt failures. Tooling earns its place when you want the same test run repeatedly, because the failures come back after theme and app changes.
Should I test with a real assistant?
You can, and it is worth doing once for the experience, but it is a poor regression test. You cannot control which products it picks, you cannot see why it rejected you, and a failure at discovery looks identical to a failure at comparison from the outside. It tells you the outcome without the mechanism.
What counts as passing?
Reaching the payment step with a real product in the cart, from a cold session, without a human intervening. Anything short of that is a stage passed rather than a purchase proved. Deliberately stopping before payment is the correct place to stop: there is no reason to submit a real payment to test a checkout.