# Four agent readiness checks, six sites, and why the results disagree

One site passed every applicable Lighthouse agent audit but scored 33 in Cloudflare. We ran four checks on six sites and read the evidence behind their disagreements.

Author: J.A. Watte
Published: October 21, 2026
Source: https://jwatte.com/blog/lighthouse-agentic-browsing-vs-isitagentready-vs-agent-inspector/

---

A laundry website passed every applicable Lighthouse Agentic Browsing audit in our test. Cloudflare's scanner gave the same home page 33 out of 100. Our Agent Endpoint Inspector called its inspection inconclusive.

Those answers sound contradictory. They become useful once we ask what each tool actually measured.

We tested Google Lighthouse, Cloudflare's isitagentready.com, our Agent Endpoint Inspector and our Mega Analyzer against the same six home pages on October 21, 2026. Then we fetched the files behind the important differences ourselves. We found different scopes, different definitions of a pass, and a warning in our own inspector that deserved a more cautious label.

We built two of these tools. That is a conflict of interest. This comparison includes their limits and gives the other tools credit where the evidence supports them.

## Three questions hiding inside one phrase

An agent using a browser needs understandable controls, a useful accessibility tree and a page that stays put while it works. An agent connecting to a service needs discovery documents, an endpoint and a protocol it can speak. An agent retrieving information needs readable, accurate content and permission to access it.

These overlap, but passing one does not establish the others. A good browser page can have no MCP server. A valid server card can advertise an endpoint that never answers. A working endpoint can return outdated business information.

That is why we separate **present**, **valid** and **observed working**. We also keep unknown results separate. A timeout is evidence about the attempted measurement. It does not establish that a link is broken.

Our earlier [endpoint evidence article](/blog/agent-endpoint-evidence-before-verdicts/) explains those boundaries. Here we wanted to see how they affect an actual comparison.

## Google Lighthouse: can an agent use this browser page?

Google added Agentic Browsing in Lighthouse 13.3.0. We verified the release history and ran the newest stable package available for this test, **13.5.0**, with Chrome for Testing **155.0.8059.84**. Google's documentation describes the category as informational and still changing. Its visible result is a fraction of passed audits, rather than the familiar performance score. [Google's toolkit announcement](https://developer.chrome.com/blog/agent-ready-toolkit) and [scoring documentation](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring?hl=en) explain the distinction.

This release contains seven audits: accessibility-tree quality, WebMCP form coverage, registered WebMCP tools, WebMCP schema validity, Cumulative Layout Shift, llms.txt and AI catalog schema validation. Registered tools are informational. Other audits can become informational or not applicable, so the denominator changes between sites. We checked the [versioned category source](https://github.com/GoogleChrome/lighthouse/blob/v13.5.0/core/config/default-config.js), rather than relying on an audit count from a launch article.

The category command, abbreviated here, was:

```sh
npx -y lighthouse@13.5.0 https://example.com/ --only-categories=agentic-browsing --output=json
```

We selected the existing test browser and retained Lighthouse's default mobile settings. We added no WebMCP testing flag. Google's documentation discusses Chrome 150 or later and WebMCP origin-trial registration. Our browser detected registered tools on participating sites with the configuration we used. That observation does not mean a site can skip its trial requirements. Browser version, origin and token validity still matter; our [WebMCP trial guide](/blog/webmcp-origin-trial-small-business/) covers the setup.

Lighthouse is free and open source. The CLI needs Node and a browser; DevTools provides a browser interface. It does not establish that a remote MCP server completes a handshake, that a business transaction succeeds or that an assistant will choose your site. We attempted one PageSpeed Insights query for jwatte.com, but its API reported exhausted quota. This run cannot confirm whether PageSpeed Insights exposes the category.

## Cloudflare: what can an agent discover?

Cloudflare's free [isitagentready.com](https://isitagentready.com/) asks about discovery, content access, bot policy and agent interfaces. Its [April 17 announcement](https://blog.cloudflare.com/agent-readiness/) explains the public scanner and its fix prompts.

We used the live form with **All Checks**, once per site, without an account. The observed checks included robots.txt, sitemap structure, useful Link headers, DNS-AID, Markdown negotiation, AI crawler rules, Content Signals, API and authentication documents, MCP cards, skills, WebMCP and ARD catalogs. Commerce results were shown separately.

The live interface and its published client code matter here. In this run, each site's displayed percentage came from **15 scored checks**. Commerce and Personal Agent Protocol did not affect it. Web Bot Auth was informational, and the default scan configuration excluded A2A and AP2. We preserved that configuration instead of silently enabling extra checks. A displayed maturity level is also distinct from the percentage.

Cloudflare validates content. It checks more than whether a URL answers successfully: its results mention robots format, sitemap structure, JSON and card fields. It also detects WebMCP tools in a rendered page. Calling the whole scanner presence-only would misdescribe what we observed.

Its MCP evidence, however, described card retrieval and validation. It did not establish a successful MCP introduction and tool listing. That is a different test. Cloudflare also documents an `agentReadiness` option in its [URL Scanner API](https://developers.cloudflare.com/api/resources/url_scanner/subresources/scans/methods/create/), which requires account authorization. We read the documentation and used the public form instead.

## Our Inspector: does the published endpoint story hold together?

The free [Agent Endpoint Inspector](/tools/agent-endpoint-inspector/) focuses on MCP and A2A discovery, cards, endpoint responses and consistency. It also checks the AI catalog and selected agent-file relationships. We reviewed its source alongside the production results.

For MCP it makes bounded, read-only protocol requests, including introduction and tool listing. It compares metadata and declared behavior, checks GET and browser preflight responses, and distinguishes access boundaries from confirmed defects. For A2A it reads the card and checks endpoint responses. It sends no agent message. It never calls an advertised tool or completes a booking.

Its output is a verdict, individual findings and dimensions with coverage. There is no single universal readiness percentage. A clean endpoint inspection says little about the accessibility tree of the home page.

There is also a measurement limit in this comparison. The backend performs concurrent requests internally. To keep our public-reference measurements within the brief's request pacing, we withheld that backend probe for Chrome Developers and isitagentready.com. Those two Inspector cells are unmeasured. We did not change the tool to manufacture comparable results.

## Our Mega Analyzer: a broader audit with separate scores

The free [Mega Analyzer](/tools/mega-analyzer/) combines agent signals with SEO, schema, accessibility, security and publishing checks. Its overall grade and its separate Agent Readiness comparison score answer different questions. We report the latter below.

Its comparison model still penalizes absent authentication metadata, including on our public site. It also counts A2A, which Cloudflare excluded in this run. The numbers are not current replicas of each other.

Its current source validates published agent documents, checks required fields and content types, and follows a bounded selection of their declared links. It shares endpoint checks with the Inspector. The normal scan allows 12 additional verification lookups; the expanded option allows more. We used the normal scope consistently.

A passed file also does not mean every link was tested. On jwatte.com, Mega passed the llms.txt row after checking nine of its 50 links. The visible row disclosed the sample, but the summary did not count the unvisited links as incomplete. We would read that summary cautiously.

Those detailed verification rows are unscored. They can identify a bad published file without necessarily changing the older comparison score. The overall audit uses weighted checks within buckets and an average of bucket scores. Neither number should replace reading the findings.

Mega reads fetched HTML rather than executing the target's application as Lighthouse does. A source-based accessibility check cannot reproduce every runtime tree problem. Its FAQ's claim that it validates content and checks live addresses is supported by the implementation, within those limits. Public-reference runs also withheld the concurrent endpoint probe and paced other requests, reducing their coverage.

## The six-site result

These are home-page measurements, not site-wide certifications. Lighthouse and Cloudflare ran between 03:33 and 03:35 UTC. Our production-tool measurements overlapped those runs and continued in the same session. The first four sites are sites we operate or maintain; the last two are public references.

| Home page | Lighthouse passes | Cloudflare score | Inspector | Mega Agent Readiness |
|---|---:|---:|---|---:|
| jwatte.com | 5/6 | 73 | All clear | 75 |
| A laundry site we manage | 3/3 | 33 | Inconclusive | 31 |
| A self-storage site we manage | 6/6 | 73 | All clear | 80 |
| apprised.news | 4/6 | 73 | 1 warning | 80 |
| developer.chrome.com | 1/2 | 20 | Unmeasured | Unmeasured |
| isitagentready.com | 2/4 | 67 | Unmeasured | 56 |

Lighthouse excludes informational and not-applicable audits from these fractions. Apprised's WebMCP schema result was a warning worth 0.5 internally, not a full pass. Cloudflare percentages are its displayed results, not conversions of Lighthouse fractions. The paced Chrome Developers Mega run timed out without a result. Any completed public-reference Mega result has reduced endpoint coverage. Mega excludes one DNS-host capability check for the storage site and Apprised; their separate comparison numbers without that exception were both 75. These are scoring-policy differences. An independent DNS lookup found no entry at the storage site's DNS-AID name; Mega's exception does not establish a record.

## What the disagreements taught us

**The laundry site had fewer applicable browser audits.** Lighthouse passed its accessibility tree, layout shift and llms.txt. Its catalog audit was not applicable. Our independent requests found a real llms.txt, served as text with status 200, and status 404 at both catalog addresses. A Markdown request to the home page still returned HTML with status 200. Cloudflare correctly found that Markdown negotiation missing. Its broader discovery checklist asks questions Lighthouse leaves outside that site's denominator.

Mega also failed isitagentready.com's AI-bot rule check despite its [robots.txt](https://isitagentready.com/robots.txt) allowing the wildcard user agent. Cloudflare recognized that rule. Mega's older comparison test was narrower.

**A browser problem survived good discovery scores on our own site.** Lighthouse flagged an empty-alt book image that also declares button behavior and keyboard focus. We independently found those attributes in the status-200 HTML. A separate accessibility-tree inspection exposed it as a named, focusable button. That supports reviewing the conflicting semantics; it does not establish that every agent is unable to operate it. Neither a valid catalog nor an Inspector all-clear resolves this browser finding. [Our home page](https://jwatte.com/).

**Authentication-template failure is not proof that accounts are needed.** Cloudflare failed our auth.md registration check. The file answered 200 as Markdown and explicitly said, "No authentication is required, and there is nothing to register for." Both OAuth discovery addresses answered 404. We then sent MCP `initialize` and `tools/list` requests without credentials. Both returned 200 JSON, with server identity and a tool list. Cloudflare's stricter registration template explains its result; the evidence does not support adding an imaginary OAuth service. [auth.md](https://jwatte.com/auth.md) and [MCP endpoint](https://jwatte.com/mcp).

**Lighthouse's llms.txt rule is stricter than the proposal's minimum.** isitagentready.com's file answered 200 as plain text. It had an H1 and API examples, but no Markdown links. Lighthouse failed it for that missing link structure. Its [13.5.0 audit](https://github.com/GoogleChrome/lighthouse/blob/v13.5.0/core/audits/agentic/llms-txt.js) requires an H1, a Markdown link and sufficient length. The [llms.txt proposal](https://llmstxt.org/) makes only the H1 required. Mega's detailed validator passed that same file. Lighthouse applied its own recommendation correctly; that is not evidence that the file was absent. [The measured file](https://isitagentready.com/llms.txt).

**Our Inspector was too noisy about a slow link.** Its Apprised warning described a failed link check whose evidence was an exhausted time budget. Our independent request to the linked digest page returned 200 HTML after about 6.5 seconds. That later success cannot prove it answered during the original attempt. It does show why a timeout should remain unresolved instead of being presented as a confirmed broken link. We recorded the issue for review and left the tool unchanged. [Digest page](https://apprised.news/digest/) and [the document linking it](https://apprised.news/llms-full.txt).

**Valid JSON is not the same as a supported schema.** Cloudflare passed the storage site's Skills index as valid JSON. Mega left its detailed validation unknown because its declared schema address differed from the one that validator supports. Our independent request found status 200, a JSON content type, a version field and a skills array. Cloudflare's narrower claim was supported; Mega's unknown did not establish a broken file.

Mega also flagged Apprised's [legacy plugin manifest](https://apprised.news/.well-known/ai-plugin.json). Our direct JSON response contained names and descriptions but lacked contact_email and an api member. Its grouped warning obscured which fields were absent. The Inspector accepted the absence of an API claim. These validators apply different contracts; neither result proves a broken API.

Apprised also received a Lighthouse WebMCP schema warning even though the fetched HTML already contained description attributes on the affected controls. We would inspect browser interpretation before prescribing more attributes. File contents, runtime interpretation and a successful user task remain separate evidence.

## How the methods compare

| Question | Lighthouse | Cloudflare | Inspector | Mega Analyzer |
|---|---|---|---|---|
| Main scope | Browser interaction | Agent discovery and access | Endpoint consistency | Broad website audit |
| Method | Runs browser audits | Server checks and rendered detection | Cards and bounded endpoint requests | Fetched HTML, files, bounded probes |
| Content validation | Selected files and schemas | Selected structures and metadata | Cards, catalog, metadata | Files, fields, types, selected links |
| Live MCP probing | No | Not established by card evidence | Yes, read-only | Yes, read-only |
| Result | Applicable-audit fraction | Percentage and maturity level | Verdict and coverage dimensions | Overall grade plus comparison score |
| Fix guidance | Audit explanations | Copyable prompts | Findings and fix prompt | Findings and fix prompt |
| Access and cost | Free CLI or DevTools | Free public form | Free web tool | Free web tool |

None of these runs completed a real business task. A listed tool is still a declaration until its behavior is tested in an authorized environment.

## Which should a small business use?

Start with Lighthouse when an assistant has to use the page, understand a form or work with WebMCP. Use Cloudflare for a quick view of discovery and access signals. If you publish an MCP or A2A interface, use the Inspector to examine the chain from card to endpoint. Use Mega when you also need to understand the surrounding website defects.

Our practical checklist is short:

1. Make the important page usable, with clear headings, labeled controls and stable layout.
2. Check that robots rules and public business facts say what you intend.
3. Read discovery-file bodies and content types. Unknown paths should have honest missing responses.
4. Publish cards only for services that exist. Verify their declared endpoints separately.
5. Fix confirmed defects, investigate unknowns and skip optional infrastructure without a business use.

The wider small-business approach is the subject of *The $20 Dollar Agency*, linked from our [books page](/books/). No score justifies building an unnecessary service.

Standards, browser support, tokens, scanner rules and cached responses change. These results describe the dated versions and scope we measured. Passing a check does not mean an agent will use your website, cite it accurately or bring you a customer.

## Fact-check notes and sources

- **Google documentation**, read October 21, 2026 at 03:33:12 and 03:34:00 UTC: [toolkit announcement](https://developer.chrome.com/blog/agent-ready-toolkit) and [scoring guide](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring?hl=en). Release history, category and file rules: [13.5.0 changelog](https://github.com/GoogleChrome/lighthouse/blob/v13.5.0/changelog.md), [configuration](https://github.com/GoogleChrome/lighthouse/blob/v13.5.0/core/config/default-config.js), [llms.txt audit](https://github.com/GoogleChrome/lighthouse/blob/v13.5.0/core/audits/agentic/llms-txt.js) and [catalog audit](https://github.com/GoogleChrome/lighthouse/blob/v13.5.0/core/audits/agentic/ard-schema.js), read 03:33:33 to 03:34:27 UTC. Six Lighthouse 13.5.0 runs: 03:33:43 to 03:35:24 UTC; Chrome for Testing 155.0.8059.84.
- **Cloudflare**, read October 21, 2026 at 03:33:13 to 03:34:42 UTC: [public scanner](https://isitagentready.com/), [announcement](https://blog.cloudflare.com/agent-readiness/) and [URL Scanner API](https://developers.cloudflare.com/api/resources/url_scanner/subresources/scans/methods/create/). Six All Checks results: 03:33:40 to 03:34:59 UTC; Chromium 156.0.8078.4. The [public client code](https://isitagentready.com/_assets/index.astro_astro_type_script_index_0_lang.ZltzupEn.js) was read at 03:34:42 UTC for score exclusions.
- **Our tools**, production measurements and source review October 21, 2026: [Inspector](https://jwatte.com/tools/agent-endpoint-inspector/), [Mega Analyzer](https://jwatte.com/tools/mega-analyzer/) and [methodology changelog](https://jwatte.com/methodology/changelog/). Inspector evidence schema: 2026.10.11e. Mega version: v2026.10.20ar. Runs: 03:34:30 to 03:48:40 UTC, with the coverage limits described above.
- **Independent evidence**, October 21, 2026: linked home-page markup, files and browser tree at 03:34:40 to 03:42:05 UTC; auth.md at 03:35:09; OAuth missing responses at 03:35:55 to 03:35:56; Markdown negotiation at 03:36:17; MCP introduction and tool list at 03:36:20 to 03:36:21; Apprised digest at 03:36:09. Each disputed finding above links its public source, except on the two sites we manage for clients, which we describe without their addresses. [llms.txt proposal](https://llmstxt.org/) read 03:35:55 UTC. Storage site Skills index read 03:42:05 UTC; DNS lookup at 03:43:01 UTC; Apprised plugin manifest at 03:44:25 UTC; scanner robots.txt at 03:49:24 UTC.

## Related reading

- [What Cloudflare's agent readiness score checks](/blog/blog-cloudflare-agent-readiness-score/)
- [Our separate Agent Ready Audit and its limits](/blog/blog-agent-ready-audit-tool/)
- [Agent discovery beyond llms.txt](/blog/agent-readiness-beyond-llms-txt/)
- [Making a small business site agent ready](/blog/agent-ready-small-business-website/)
- [The SPA shell trap behind misleading successful responses](/blog/blog-spa-shell-trap-aux-file-200-ok/)

*This post is informational, not SEO-consulting advice. Mentions of Google, Lighthouse, Chrome, Chrome for Testing, Chrome DevTools, PageSpeed Insights, Cloudflare, isitagentready.com, Node.js, MCP, A2A, WebMCP and all other named products are nominative fair use. No affiliation or endorsement is implied.*


---

Canonical HTML: https://jwatte.com/blog/lighthouse-agentic-browsing-vs-isitagentready-vs-agent-inspector/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/lighthouse-agentic-browsing-vs-isitagentready-vs-agent-inspector.webp