How we score agent-readiness.

What we validate

5 categories. 31 validations. Each category is weighted by how material it is to an agent's ability to find, understand, and transact with your store.

Why it matters now

AI agents — ChatGPT's commerce surface, Google's Gemini for shopping, Perplexity's Comet, and a growing list of vertical agents — are starting to make purchase decisions on behalf of users. The signals those agents read are still settling. Sites that meet ACP, UCP, MCP, and schema.org conventions today will be discoverable, comparable, and transactable when those agents scale. Sites that don't will be invisible.

None of this is a crystal ball. ACP and UCP are early specifications and may change. We follow them as they evolve and update this methodology monthly.

How scoring works

Each validation returns pass, partial, or fail. Partial credits 0.5. Each category is normalized to 0–100 and combined into the headline score using the weights above. Tier bands:

• 0–39 Hostile Fundamental signals are missing. Agents struggle to read or trust the store.
• 40–59 Visible Agents can find the store but not yet transact through it.
• 60–79 Ready Most signals are in place. Closing a few gaps would make it agent-native.
• 80–100 Native Built for the agentic web. The signals agents need are present and machine-readable.

Robots.txt and AI bot posture. AI bots split into two groups: training crawlers (GPTBot, Google-Extended, ClaudeBot, and similar) that build model corpora, and live-fetch agents (ChatGPT-User, Claude-User, PerplexityBot) that browse on a user's behalf at request time. Only sites that allow both groups earn pass. Sites that block training crawlers but allow live-fetch get partial with a positive note — training opt-out is an editorial choice that does not impact live agent capability, but it isn't a full pass either. Sites that block everything fail.

ACP, UCP, and MCP manifests. Serving a JSON file at the canonical well-known path is the starting point, not the finish line. To pass, a manifest must be a JSON object with the required fields from the published spec (version + endpoints for ACP and UCP; name, version, and transport for MCP) and must advertise at least one endpoint we can reach via HEAD or a single-byte GET. Manifests that are empty, missing required fields, or advertise endpoints that do not respond get partial — the discovery surface is present but not usable in practice.

Sitemap quality. Returning 200 isn't enough. We parse the XML structurally, decompress .xml.gz files and gzip-encoded responses, sample one entry to verify it isn't a dead URL, and read the <lastmod> distribution. Sitemaps where every entry is over a year old drop to partial — stale catalogs lead to stale agent recommendations. Sitemaps that list a dead URL in the sample also drop to partial.

HTTPS canonical posture. A clean pass means apex and www resolve to the same final URL and the http:// version redirects up to HTTPS. Apex-only sites (no www variant configured) pass with a note — increasingly common and not a problem an agent can't handle. HSTS is surfaced as a positive signal but its absence does not penalize. Sites that don't redirect HTTP to HTTPS drop to partial only — a borderline general-web signal, light penalty.

Catalog sampling. We discover product pages through the sitemap and verify each one semantically — a page is treated as a PDP only if its JSON-LD declares schema.org/Product. Non-English and slug-only product URLs are sampled the same as English ones. Sampling is adaptive: start with five candidates, grow by five if fewer than two verify, cap at fifteen.

Catalog signals. On the sampled PDPs we check structured pricing (Product.offers.price + priceCurrency on a majority), Open Graph product fields (og:type=product with title, price, and currency together), Product.brand, and Product.offers.availability against the 12-member schema.org/ItemAvailability enum. Brand and availability are the newest signals — sites with full Product schema but no brand or no stock state see honest fails in Catalog Quality. Agents cannot resolve cross-merchant queries without brand, and cannot recommend purchases without stock data.

SPA shell detection. We scan the homepage's first HTTP response for common Single-Page-App shell patterns — the Create React App default noscript, empty React / Vue / Angular / Next.js root containers (<div id="root"></div>, <app-root></app-root>), and low-content bodies with framework loading placeholders. When two or more high-confidence markers fire, we report fail — agents without a browser receive no usable content from that page. Sites whose homepage cannot be fetched at all also fail, with the HTTP status or network-error reason in the message.

Scope, stated honestly: this check does not execute JavaScript or simulate a browser. Sites with subtle JS-dependency issues — broken server-side rendering, partial hydration, JS-driven catalog pagination — may pass SPA shell detection despite being agent-unfriendly in practice. A future version of this check using Cloudflare Browser Rendering would catch those cases; it's deferred pending an economic model decision. What we ship today catches the unambiguous empty-shell cases at zero cost per scan.

Policy and FAQ page discovery. Returns, shipping, privacy, and FAQ pages are reached through a 4-level cascade. We try them in order, top to bottom, and stop at the first level that produces a real page:

• Level C — schema We look for MerchantReturnPolicy, OfferShippingDetails, Organization.privacyPolicy, or FAQPage in the JSON-LD on your homepage. Machine-readable; the strongest signal an agent can consume. An FAQPage whose mainEntity has no valid Q&A pairs — empty array, Questions without name, or Answers without acceptedAnswer.text — drops to partial. Schema present but unanswered is theatrical compliance.
• Level B — homepage link We read every anchor on the homepage and match its text, URL, aria-label, title, and nested <img> alt against keywords in six languages (EN, PT, ES, FR, DE, IT). A real agent would navigate the same way.
• Level D — sitemap We scan your sitemap URLs for keyword hits. Catches policies that exist on the site but aren't linked from the homepage — a sign navigation-reliant agents may miss them.
• Level A — well-known path Last resort: we try common policy paths ( /returns, /devolucoes, /datenschutz, and so on). Reaching a page here means none of the higher-level signals were present.

Every level requires the destination to look like a real policy page: minimum body size and at least one policy keyword in the body. Pages that return 200 but redirect to the homepage, or that are placeholder shells, do not pass.

The pass message names the level reached. via schema beats via homepage link beats via sitemap beats via well-known path — same pass state, but the wording tells you exactly which higher-level signal would make your policy easier for an agent to find.

What we don't validate

Synthetic checkout, login-walled content, page performance, and qualitative UX. We measure the agent-readable surface, not the buying experience. We also don't follow links offsite, scrape the full catalog, or hold any data after the scan finishes — see the privacy notice for details.

Who built this

KODLY is an enterprise eCommerce + AI consultancy based in Lisbon. We work with European retailers on agent-readiness, structured commerce, and platform migrations. This tool is free because we want a baseline that's transparent and shared.

Feedback

See something we got wrong, or a validation we should add? Email hello@kodly.io. The methodology updates monthly; large enough corrections cut a fresh version.