/ The Bottom Line Up Front

AI agents evaluate your site before they interact with it.

Chrome's Lighthouse agentic-browsing category scores six signals that determine whether an AI agent can understand and operate your site. Our free checker tells you exactly where you stand — and what to fix first.

The OPERABLE Framework

CITABLE for answers. OPERABLE for actions.

Most websites are readable by humans and crawlable by search engines. Very few are operable by AI agents. The OPERABLE Framework — built on our own research into agentic browsing adoption and named after W3C WCAG's Operable principle — maps 17 checks across 8 pillars: observable structure, parsable I/O, explicit guidance, readiness on load, annotated semantics, bounded autonomy, live feedback, and an executable interface. Checks run via Google Lighthouse, the WebMCP W3C draft spec, and the llmstxt.org standard.

What is the agentic browsing checker?

The agentic browsing checker runs Google's Lighthouse agentic-browsing audit category against your domain and emails you the full results. It's the same battery of checks that Chrome DevTools and the WebMCP origin trial use to evaluate site readiness for AI agent interaction.

WebMCP is a W3C draft API that lets web apps expose tools to AI agents via navigator.modelContext. As Gemini in Chrome and other agents adopt this protocol, sites that register tools correctly will be preferred. The Lighthouse audits measure whether your tools are discoverable, your schemas are valid, your forms have agent-readable annotations, and your layout is stable enough for agents to operate reliably.

The checker runs 17 checks across 8 OPERABLE pillars. The browser layer (Puppeteer + Lighthouse) covers WebMCP tool registration, form annotation coverage, schema validity, accessibility tree quality, layout stability (CLS), llms.txt presence, tool registration timing, tool description quality, and return value structure. The HTTP layer covers ARIA live region coverage, button keyboard operability, llms.txt content validity, toolparamtitle coverage, toolautosubmit safety, AI crawler access via robots.txt, ai-plugin.json manifest, and MCP discovery manifest. Results are delivered as a structured report with per-check scores, failing elements, and prioritised fixes.

17 checks across 8 OPERABLE pillars

Each check maps to a pillar of the OPERABLE Framework. Browser-side checks run via Puppeteer for accurate JavaScript evaluation. WebMCP checks evaluate the W3C draft API for agent tool registration.

O

Observable structure

Agent accessibility tree

Counts native semantic landmarks (nav, main, article, aside, header, footer) and ARIA role equivalents. Penalises duplicate unique elements and unlabelled duplicate landmarks. Agents that navigate by DOM structure rely entirely on these signals.

WebMCP tool registration

Calls navigator.modelContext.getTools() and evaluates each tool for completeness across five fields: name, description, parameters, return type, and namespacing. High-value tool types (search, checkout, auth) add to the score.

Form annotation coverage

Inspects every form for toolname, toolschema, and per-input toolparamtitle coverage. Score is coverage ratio multiplied by per-form completeness — partial annotation counts as partial credit.

P

Parsable I/O

Tool schema validity

Parses toolschema JSON and validates structure: type must be "object", a properties object must be present, and property keys must match actual input[name] values in the form. Raw JSON validity alone is not sufficient.

Return value structure

Checks whether each registered tool defines a return schema (returnType, outputSchema, returns, or returnSchema). Validates that type values are standard JSON Schema types and that object types include a properties field.

E

Explicit guidance

llms.txt presence

Fetches /llms.txt and checks for a 200 response. On success, reports line count and whether the Optional block is present. On failure, includes a starter template in the details. Follows the llmstxt.org specification.

llms.txt content validity

Validates structure: minimum 5 non-empty lines, at least one ## heading, working links (HEAD-checked), and title consistency between the file's first line and the homepage <title>/<h1>. Shows the specific broken link URL and title mismatch side-by-side.

R

Ready on load

Tool registration timing

Analyses WebMCP scripts for async, defer, and type="module" attributes. Optimal: inline or src script in <head> without defer. Penalised: deferred-in-head (0.5), body-only (0.5), or module script (0.5 — modules are always deferred by the browser).

Layout stability (CLS)

Measures CLS after a 3-second wait using the Layout Instability API. Captures shifting element selectors from attributedTo for diagnosis. Also counts images without explicit width/height attributes — the most common CLS root cause.

A

Annotated semantics

Tool description quality

Scores each tool description on four criteria: length (20-300 chars), absence of boilerplate phrases ("this tool...", "a function that..."), not starting with the tool name, and presence of at least one action verb. A failing check shows the specific issue for each tool.

toolparamtitle coverage

Checks all interactive inputs (input, select, textarea — excluding hidden and submit) inside WebMCP-annotated forms for a toolparamtitle attribute. Also verifies the value is descriptive — not empty and not identical to the name attribute.

B

Bounded autonomy

toolautosubmit safety

Inspects toolautosubmit forms for three risk signals: POST method, destructive path segments in the action URL (/delete, /cancel, /remove), and destructive body keywords. Forms with any signal but no data-confirm guard are flagged with the action URL and issues listed.

L

Live feedback

ARIA live region coverage

Counts aria-live attributes and ARIA role equivalents (role=status, role=alert). Scores on presence (0.5) plus configuration quality (0.5 scaled by aria-atomic and aria-relevant coverage). Fully configured live regions score 1.0.

E

Executable interface

Button keyboard operability

Checks role="button" elements for tabindex, and detects clickable div/span elements (onclick handlers) missing role="button" entirely. Penalty scales by number of issues. Reports the count of unroled clickable elements as the primary fix target.

AI crawler access (robots.txt)

Parses robots.txt for 13 known AI user-agents categorised as crawlers (GPTBot, CCBot), agents (Claude-Web, Perplexitybot), or AI search (Google-Extended). Checks full blocks (Disallow: /), Crawl-delay throttling (>10s), and partial path blocks on significant paths (/api, /search, /docs).

Example OPERABLE Readiness Report

See what your audit report looks like. This example shows a typical B2B SaaS site with good fundamentals but no WebMCP implementation yet.

OPERABLE Readiness Report

acme-saas.com · Agentic Operability Score

Agentic Operability Score

OPERABLE Framework — 8 pillars, 17 checks

Observable structure
Parsable I/O
Explicit guidance
Ready on load
Annotated semantics
Bounded autonomy
Live feedback
Executable interface
62%

Check breakdown

OPERABLE Framework · 8 pillars

Observable structure
Parsable I/O
Explicit guidance
Ready on load
Annotated semantics
Bounded autonomy
Live feedback
Executable interface

How the OPERABLE Site Audit works

01

Enter domain and email

We accept any public domain. The audit runs against your live site — no deployment changes needed.

02

We run Lighthouse's agentic-browsing category

Six audits evaluate WebMCP tool coverage, schema validity, accessibility tree quality, llms.txt, and CLS.

03

We score each audit

Results are presented as a fraction (e.g. 4/6 passing) with per-audit details, failing elements, and severity.

04

Report lands in your inbox

Full Lighthouse JSON and a human-readable breakdown emailed to you — ready to share with your dev team.

Frequently asked questions

What is the agentic-browsing Lighthouse category?

Google added a custom agentic-browsing category to Lighthouse in 2025. It includes audits specifically for AI agent compatibility: WebMCP tool registration, schema validity, form coverage, accessibility tree quality, layout stability (CLS), and llms.txt.

Do I need to implement WebMCP for this to be useful?

No. Even without WebMCP, the audit surfaces actionable issues: poor accessibility tree quality, missing llms.txt, high CLS — all of which affect how agents interact with your site today via screen-reading and browser automation.

What is WebMCP?

WebMCP is a W3C draft API (navigator.modelContext) that lets web apps register typed tools that AI agents can discover and call. Chrome 149 opened an origin trial in May 2026. Gemini in Chrome is the first production agent to use it.

What is llms.txt?

llms.txt is an emerging standard for giving AI models a machine-readable summary of your site — similar to robots.txt but designed for LLMs rather than crawlers. The OPERABLE audit checks for its presence, link health, and structural validity.

How long does the audit take?

Typically 45-90 seconds depending on your site's load time and server location. Results are emailed as soon as the audit completes. Keep the tab open to see them inline.

How often should I rerun the audit?

After any significant site change, and whenever Lighthouse releases an agentic-browsing update. We keep the runner on the latest version automatically — rerunning always reflects the current audit definitions.