AgentReady
RUEN

AgentReady scoring methodology v0.3

AgentReady measures how usable a website is for AI agents — programs that browse sites on a person's behalf: they look for information, choose products and fill in forms. The result is a number from 0 to 100. This page explains what it is made of.

The main principle: only properties of the site itself count towards the score. Facts about the site and obstacles on the way are checked by rules, without AI, so the result does not depend on which model walks the site. An AI agent's attempt is shown in the report separately and earns no points: its outcome depends on the model, not only on the site.

Every report states its methodology version. When the rules change, the version changes, and old reports stay calculated by their own version.

Four blocks make up the score

Block Weight What we check
Access 20 The site responds, does not block AI agents, and robots.txt does not shut them out
Readability 25 schema.org markup, element labels, content without JavaScript
Scenario passability 45 Four typical scenarios: what the site offers for them and what gets in the way
Agent interfaces 10 llms.txt, sitemap.xml, WebMCP or an API description

Inside a block the score is the average of its checks: passed = 1, partly = 0.5, failed = 0. The “Semantics” check and the scenarios give a fractional score from 0 to 1.

Scoring rules:

Access (20)

Readability (25)

Scenario passability (45)

Our robot walks the same four scenarios as the AI agent, but by rules, without a language model. It clicks links and buttons the way an agent would, and records what the site offers and what got in the way.

Scenario score = share of signals present × (1 − obstacle penalty).

Signals

Scenario When it applies Signals (each is an equal share of the score)
Find contacts always the phone or e-mail is a tel: / mailto: link; contacts are in JSON-LD; the home page links to a contacts page (or shows contacts itself); the phone or e-mail is in the HTML without running JavaScript
Find a product and its price the site has prices, product markup, a cart or a pricing link the home page links to a catalog, a product or pricing; the price is in the HTML without JavaScript; a product or service with a price is in JSON-LD; for stores — a labelled search field
Cart there is a cart link or an “add to cart” button the “add to cart” button is labelled and can be clicked; there is a cart link; the cart leads on to checkout. No order is placed
Request form a contact form is found on the home page, on the contacts page or one link away from them fields have labels (label, aria-label, placeholder, autocomplete) — at least 80% of the fields; the submit button has a label; the form is not behind a captcha; the form is in the HTML without JavaScript. The form is neither filled in nor submitted

A scenario whose subject is absent from the site (no cart, no form) is “not applicable”, not zero. Search, login, sign-up and one-field subscription forms are not counted as contact forms.

Obstacles and penalties

An obstacle is whatever made the robot's click fail or cut the path short.

Obstacle Penalty
Bot-protection page 100% — the scenario cannot be walked
A consent banner that cannot be closed without consenting to tracking 50%
The element is covered by another one (pop-up, sticky header) 30%
The element is outside the visible area (carousel) 30%
The element is disabled 30%
The element does not respond to a click 30%
The element is hidden (closed menu) 20%
The path leads to another website 20%

Several obstacles in one scenario multiply (30% and 30% leave 49%); an obstacle of one kind counts once. A consent banner that closes with a neutral button (“reject”, “only necessary”, “close”) gives no penalty: the robot closes it and goes on. The robot never consents to tracking.

The penalties are expert estimates for now. They were set from the first observations: for example, scenarios where an agent met a covered element succeeded in 4 cases out of 23, against 121 out of 182 without obstacles. There are few observations, almost all from one model. After a calibration run on a large set of sites and several models, the penalties will be replaced with measured ones (“gets in agents' way in N% of cases”), and the methodology version will change.

How the AI agent did (outside the score)

Separately from the score, an AI agent gets the same tasks in plain language and sees the page as a text snapshot of the accessibility tree — without pre-written selectors. For every scenario the report shows the outcome, the model and the steps with screenshots. It is one agent's attempt on the model shown: another agent may walk the site differently, which is why it earns no points. It is there to show where an agent gets stuck in practice and to collect data for calibrating the penalties.

The agent's answer is checked, not taken on trust: the contacts and price it reports must appear on the pages it visited, and the checkout screen and the filled-in form are detected from the page itself. An unconfirmed answer is partly. The agent closes consent banners only with a neutral option; clicking “accept” is forbidden in code.

Limits for an agent scenario: 20 steps, 90 seconds of work, 40,000 input tokens (cached tokens of providers that give a discount count as half). Scenarios not checked through our fault (a limit or a failure of the AI model, not enough time) are retried; if the retry fails too, the result is “not checked”.

Agent interfaces (10)

How the bot behaves

Limitations

The score reflects the state of the site on a particular date. The robot follows a typical path: if contacts or the catalog hide behind unusual names, it may not find them — the signal then counts as missing even though a person would have found it. Sites change and serve slightly different content from request to request, so a repeat check may give a different result: in our measurement two checks of the same site in a row matched exactly in 85% of cases, and the difference was usually within 5 points. The score does not depend on any AI model.

Version history