How the agent readiness test measures
The free test reads your store’s public pages the way a shopping agent does: access, product data, policies, consistency and the path to the cart. This page lists the checks, weights and rules openly.
How the score works
- Every check carries a weight; the five categories add up to 100: access 25, product data 25, policies and trust 20, consistency 15, action 15.
- A passed check earns full points; a partial pass earns points in proportion to how complete it is (e.g. three of four offer fields = 75%).
- A check that can’t be seen from outside, or can’t be measured because of a security layer, is “not verifiable” and drops out of the calculation; it doesn’t lower your score.
- Access has three outcomes: a hard refusal (e.g. HTTP 403) is a critical blocker; a challenge page or CAPTCHA is a “possible block”, a partial pass that isn’t critical; a rate limit (HTTP 429) isn’t a block: we retry after the Retry-After wait, and if it’s still limited the affected checks are not verifiable.
- A critical blocker (an agent can’t read the store at all, or reads it wrongly) caps the score: at most 59 with one blocker, at most 39 with two or more.
- “Agent-ready” is given only with no critical blocker, a score of 80 or more and when the simulation doesn’t eliminate the store. Below 40 is “hard for agents to read”.
- The simulation is built from your real product page (product, price, currency); the store is only eliminated for a reason tied to a check, so score and simulation can’t contradict each other. The simulation isn’t a real agent.
Checks
A detailed page for every check →
Access · 25
| Weight | |
|---|---|
| Search and user agents allowed (robots.txt) Can be a critical blocker Search and user agents are explicitly allowed. You can still block training bots (GPTBot, ClaudeBot, Google-Extended); that doesn’t cut visibility. | 8 |
| Is bot protection open to agents? Can be a critical blocker Bot protection stops only malicious traffic; verified search and user agents get the normal page (HTTP 200). Risk-based checks and rate limits (HTTP 429 + Retry-After) replace a CAPTCHA at every step. | 8 |
| Product name and price readable without JavaScript Can be a critical blocker Product name, price, currency and stock are in the initial HTML (server-side rendering or static generation). | 5 |
| Sitemap An up-to-date sitemap lists your product pages and is referenced from robots.txt. | 2 |
| Can the product page be indexed? Product pages are indexable and their canonical points to themselves. | 2 |
Product data · 25
| Weight | |
|---|---|
| Product structured data (schema.org) Can be a critical blocker Every product page carries Product data as JSON-LD; products with variants use ProductGroup + hasVariant. | 7 |
| Price, currency, availability and URL The offer carries price, an ISO currency code, availability and the product URL together. | 6 |
| Product identity (GTIN/MPN, brand, SKU) Brand and a valid GTIN (barcode) or MPN are defined; the SKU is there too. | 5 |
| Images and description JSON-LD carries a stable https image URL and an original description; og:image is set as well. | 2 |
| Reviews and rating The stars and review count on the page are marked up as AggregateRating too. | 3 |
| Can variants (size, color) be addressed? Every variant opens at its own URL; structured data uses ProductGroup + hasVariant and variesBy. | 2 |
Policies and trust · 20
| Weight | |
|---|---|
| Machine-readable return policy The return policy is defined once at organization level (OnlineStore → hasMerchantReturnPolicy) or on the product offer, with the same values as your returns page. | 5 |
| Returns page and window The homepage links to an HTML returns page that states the window, fees and method clearly. | 4 |
| Machine-readable shipping information Shipping rate, handling and transit times are defined with OfferShippingDetails. | 4 |
| Shipping cost and time on the page The product page shows shipping cost, the free-shipping threshold and delivery time before the cart. | 3 |
| Business identity The homepage carries OnlineStore data with name, address, contact details and social profiles. | 2 |
| Legal pages (distance selling, Türkiye) The footer links to the distance sales contract, the pre-information form and the privacy notice. | 2 |
Consistency · 15
| Weight | |
|---|---|
| Price consistency Can be a critical blocker Visible price = structured-data price = feed price (taxes included, same currency). | 6 |
| Stock consistency Availability is real-time and machine-readable (InStock, OutOfStock, PreOrder). | 3 |
| Currency and language priceCurrency is an ISO 4217 code ({currency}) and <html lang> matches the page language. | 2 |
| Return window consistency The return window in structured data equals the one on the returns page. | 2 |
| Taxes-included wording The price states that taxes are included, and shipping cost is visible before the cart. | 2 |
Action (cart and orders) · 15
| Weight | |
|---|---|
| Add-to-cart button in the initial HTML Add to cart is a real <button> or form in the initial HTML. | 5 |
| Is the cart button accessible? The button is a <button> or form submit with visible text or an aria-label. | 3 |
| Buying without an account Guest checkout is on; few steps, no pop-ups or forced newsletter sign-ups. | 4 |
| Order tracking A guest order tracking page (order number + email) and a carrier tracking link are available. | 2 |
| Site search that works by URL Search submits a GET form to a URL parameter; WebSite data declares a SearchAction. | 1 |
Information rows (no effect on score)
The rows below are shown as information in the result. The agent protocols row only checks that discovery files exist and are well-formed (UCP, MCP, A2A agent card, ai-catalog, API Catalog / RFC 9727, Web Bot Auth directory, an ACP hint, WebMCP markers, OpenAI domain verification); no endpoint is called and no session is opened. llms.txt isn’t scored because independent studies show AI bots rarely read it.
- Catalog from abroad
- Training bots
- Other AI bots
- robots.txt group precedence
- Content signals · Content-Signal
- Access with a bot identity (possible block)
- Cloudflare
- llms.txt
- llms.txt structure
- Agent protocols and discovery files
- Product and search endpoints
- Policy and contact links
- Merchant Center / Search Console
- Payment providers
- Online return request
- Pop-ups and newsletter
- Review and Q&A tools
- Buy controls
- Product question coverage
- Possible hidden constraints
- Agent safety
Hotels and service businesses
- The test first recognises the site type from the home page: e-commerce, hotel / lodging or service business. No extra request is made; it looks at structured data (Hotel, LodgingBusiness, ProfessionalService …), booking engines, cart signals and contact forms. If it isn’t sure, the site is measured as e-commerce.
- On hotel and service sites, checks that only make sense for a store (cart, checkout, product offer, GTIN, variants, return and shipping policies) are “not applicable” and don’t count. The score is computed over applicable checks only; every type still adds up to 100.
- The common checks are measured for every type; reading without JavaScript is measured on the home page for hotels and services. Each type adds its own five checks.
- “Agent-ready” isn’t given to a hotel unless the booking-entry check passes, or to a service business unless the contact or quote form check passes.
- Sector checks are measured from the home page only: a linked page (e.g. a contact page) isn’t opened and nothing is claimed about it; a booking window that only opens via script counts as a partial pass. The agent simulator tries these flows in a real browser and stops without typing anything into the form.
Common checks measured for every type
Hotel and lodging checks
| Weight | |
|---|---|
| Hotel structured data (Hotel / LodgingBusiness) The homepage carries one Hotel (or Resort, BedAndBreakfast…) node with name, address, geo coordinates, phone, star rating and check-in/check-out times. | 18 |
| Amenities in structured data Every amenity a guest might filter on is listed as a LocationFeatureSpecification (name + value: true). | 8 |
| Rooms and prices readable Each room type is a HotelRoom with occupancy and bed details, offered through an Offer with a “from” price and currency. | 15 |
| Cancellation policy discoverable A plain-text cancellation policy page (deadline, fees, no-show) linked from every page. | 12 |
| Booking entry point reachable A plain <a href> to the booking engine (with dates as URL parameters if possible) or a GET form with check-in/check-out fields. | 20 |
Service business checks
| Weight | |
|---|---|
| Business structured data (Organization / ProfessionalService) One ProfessionalService (or Organization / LocalBusiness) node with name, contact details, address and the area served. | 18 |
| Services described One page per service, linked from the homepage, each with Service data pointing to your organization. | 15 |
| Pricing or “how it works” discoverable A pricing or packages page (starting prices are enough) and a short “how it works” section, both linked from the homepage. | 10 |
| Contact details readable Email and phone are plain text with mailto:/tel: links in the header or footer of every page. | 12 |
| Contact or quote form within one click A plain HTML form (name, email, message) reachable in one click from the homepage, with clearly labelled fields. | 18 |
What this test can’t do
- Adding to cart and guest checkout aren’t tried with a real browser; the deep audit report measures them.
- Shipping and return settings in Google Merchant Center and Search Console can’t be seen from outside; if set there, they apply on Google surfaces.
- A request with a bot identity isn’t a verified bot IP, so the result is reported as a “possible block”.
- One product page is read per store; price and stock consistency are judged on that sample.
- Real agent answers (whether the store gets recommended) aren’t measured in this test.
What the automated scan can’t see
The free test reads public pages without a browser; the agent simulator shops in a real browser. Neither sees everything. What each one covers, and how much:
| Area | Free test | Agent simulator |
|---|---|---|
| Agent access (robots.txt, bot protection) | Partial Measures robots.txt and how the homepage and product page respond; can’t send requests from OpenAI’s or Google’s verified IPs. | Partial The real browser comes from Cloudflare’s network; a block is reported as a finding. |
| Product data (structured data, offer, identity) | Partial One product page is read; the deep audit looks at up to 12 product pages. | Not covered The agent shops; it doesn’t grade product data. |
| Policies (returns, shipping) | Partial Public pages and structured data; Merchant Center and Search Console settings can’t be seen from outside. | Partial In the policy-reading scenario the agent looks for the return window and the shipping fee. |
| Price and stock consistency | Partial Structured data, the meta tag and the visible text are compared on one product page. | Partial The price-change scenario compares the product page price with the price in the cart. |
| Cart and checkout step | Partial Only signals in the initial HTML; guest checkout isn’t verifiable (the deep audit tries it in a real browser). | Partial Adds to cart, goes as far as checkout and stops there. |
| Payment and completing the order | Not covered No order is placed and no payment details are entered. | Not covered No order is placed; no personal or card details are typed. |
| After purchase (order tracking, returns process) | Partial Only looks for an order-tracking link without sign-in and an online return-request link. | Not covered No order is placed, so after-purchase steps aren’t tried. |
| AI answers (do they recommend you?) | Not covered Measured separately by the visibility measurement on paid plans (above). | Not covered The simulator shows whether an agent can shop on your site, not whether it recommends you. |
| Agent protocols | Partial Protocol discovery files are read and shown as information rows; they don’t affect the score. | Not covered The simulator browses your site like a customer; it doesn’t call protocol endpoints. |
| Hotel and service flows | Partial Homepage only; linked pages aren’t opened. | Partial Tries the booking or contact flow in a real browser; never types into the form. |
How AI visibility is measured
- Visibility is measured on paid plans; the free test doesn’t measure AI answers.
- By default we use ChatGPT, Perplexity and Gemini (at most 3 answer engines). Questions go to the models’ APIs with web search turned on; calls are routed through OpenRouter.
- The default 8 shopping questions are generated from your store’s product names and market with rule-based templates (no AI in this step). You or our team can add up to 10 custom questions.
- Each question is asked 3 times per engine in a measurement (repeated sampling). AI answers vary from run to run, so the report shows in how many runs you were mentioned (for example 2 of 3) and how consistent the runs were. Still, read a single measurement as one point on a trend, not as a definitive result.
- For each answer we record whether your brand is mentioned, whether your site is cited, your position and the competitors named.
- An API answer isn’t the consumer app: product cards in the ChatGPT app, personalisation, location and memory can give different results. We don’t scrape the apps or user sessions.
- It runs monthly and can be repeated on request. Before every call your plan’s spending cap is checked: if all runs don’t fit under the cap, the number of runs is lowered first and the report says so; if even one run doesn’t fit, the measurement stops at the cap.
The 196-criteria framework
The free test measures 27 checks. The full table in our panel rests on a wider framework: 196 criteria. 189 come from the Webtures SI Agent Readiness list (12 sections); 7 are our own shopping-flow checks with no counterpart in that list (add to cart, guest checkout, site search…).
The free test’s checks give direct evidence for 27 of these criteria; each check’s page says which item it maps to. The rest are settled in the deep audit, by the scan’s extra probes or by expert verification.
An unverified criterion never counts as passed and isn’t shared out: it stays in the denominator and shows as “not verified”.
Source: Webtures SI Agent Readiness ↗ · · 189 + 7
We ran the free test on our own site
If we ask stores to pass these checks, we should publish our own result, even when it isn’t flattering. This is the unedited result for specoria.com.
specoria.com · free test
75/100 Partly ready
11 checks measured · 14 couldn’t be verified · 2 not applicable
Source: Specoria free test on specoria.com ·
Why so much is unverified: Specoria is a software service, not an online store, and the test has no site type for that. It measured us as a store (it saw “add to cart” on our home page, low confidence), found no product page, and so every product check shows as “couldn’t verify”, which leaves the score rather than counting as zero. We publish it as it came out instead of tuning the test for ourselves.
What the test flagged
Some of these only make sense for a store; we list them anyway.
- Machine-readable return policy · Failed: Your return policy isn’t in structured data, so an agent can’t verify a condition like “14-day returns”.
- Shipping cost and time on the page · Partial: Shipping is mentioned, but no free-shipping threshold or delivery time is stated.
- Business identity · Partial: Organization data is present but missing: social profile links (sameAs).
- Order tracking · Failed: No order tracking link was found.
- Site search that works by URL · Partial: There’s a search box, but it only works with script and can’t be queried by URL.
Run on October 8, 2026 with the same code as the live test (commit 89c43e1), from our own machine, without the optional AI step; it took 2.1 seconds. Download the result as JSON