Lighthouse Agentic Browsing Checks: What They Actually Prove

Agentic browsing describes software navigating or acting on a website for a user. The Lighthouse category is a developer diagnostic for selected machine-interaction conditions. It is not a Google Search ranking signal, a certification across agents, or evidence that an agent completed a business task. Use it alongside browser-specific task tests, accessibility checks, security review, and real outcome measurement.

What Is Agentic Browsing?

It is useful as an engineering signal. If controls have proper names, relationships are valid, the layout holds still and tools are declared, software has less to guess at. The official documentation does not call it a search ranking factor and does not forecast adoption or commerce volume. Business investment should follow a named user journey and measurable demand, not a market projection alone.

What Google Actually Scores Today

The accessibility tree is one machine-readable view of interactive content. OpenAI also says its Atlas agent uses ARIA labels and roles to interpret structure and controls. Correct semantic HTML and accessible names therefore help people and supported agents, but do not guarantee that every agent uses the same model or that search systems quote the page.

There is a point buried in that worth saying plainly. An agent reads your page through much the same structure a screen reader uses for a blind visitor: the headings, the roles, the accessible names on your controls, the labels on your form fields. Semantic markup used to be filed under accessibility, and treated by plenty of teams as a compliance chore. It is now also the interface a machine reads your page through. That is the honest reason these checks exist, and it is why the work overlaps so heavily with things you should have been doing anyway.

It also helps to keep two different questions apart. The first is whether an agent can read and navigate your page. That is what the accessibility, layout-stability and discoverability audits look at, and those run today. The second is whether an agent can reliably act on it, submit the form, complete the purchase, change the booking. That is what WebMCP is for, and it is the part that is not settled. Almost all the confusion about this category comes from treating those two as one question.

"A dated audit result proves only what that tool checked on that page, under that recorded environment. It certifies nothing about your other pages, other browsers, other agents, other tasks, or the next version.

Does Being AI-Readable Actually Lead to Sales?

The screenshot records 25 ChatGPT-tagged orders totaling $5,149.18, one Perplexity-tagged order totaling $590, and one Claude-tagged order totaling $1,680. PandaCodeGen's owners approved publication because Panda Patches is their own brand. The image does not show the collection method, attribution window, returns, taxes, or counterfactual orders, so it is presented as an internal snapshot rather than proof of channel incrementality.

The two screenshots answer different questions and should not be joined into one success claim. The Lighthouse image records a technical audit on pandacodegen.com. The commerce image records internal referral labels on Panda Patches. Neither demonstrates autonomous agent purchasing, and the second does not show that the first caused revenue.

What Is WebMCP, and Why Is It “Not Applicable”?

It is useful to separate interpreting the interface from calling an explicitly registered tool. Accessibility-tree quality and layout stability can help the first. WebMCP experiments address the second. Neither alone proves that a specific agent can safely complete a form, purchase, or account action; those journeys also need authentication, authorization, validation, confirmation, error, privacy, and abuse testing.

Before you ship this, say which browser or agent you support, which journey it covers, what the origin trial requires, what data is exposed, who reviewed the security, what happens when it fails, who maintains it, and what acceptance test it has to pass.

For most sites, though, the practical answer is to wait, and the requirement itself is the reason. Those audits only run on Chrome 150 or later and only for origins registered in the WebMCP origin trial. A capability gated behind an origin trial is a capability that is still being changed, and building production integration against it means committing engineering time to a moving specification that almost nothing consumes yet. That is a real cost with a speculative return. Prototype it if you have a specific journey and a specific agent in mind. Otherwise the browsability layer is where the same effort pays off today, for people as well as for software.

The Honest Truth About llms.txt

Chrome's experimental audit checks llms.txt presence, but that check does not make the file a Google Search requirement or prove that another product consumes it. Add and maintain the file only when it serves a named consumer or test. Crawlable, useful, source-linked content remains important, but no structure or opening-sentence pattern guarantees retrieval or quotation.

How do you check your own score, and your competitor's?

Run it on the page you would want an assistant to describe, which is usually a service or product page rather than the home page. The audits run per URL, so a good home page score tells you nothing about the page that actually sells.

Then run the same test on a competitor. This is the part most people skip and it is the only part that gives the number meaning. A 1 of 3 in a field where everyone scores 1 of 3 is a different situation from a 1 of 3 where two rivals score 3 of 3. You are looking for a gap, not a grade.

What the comparison can tell you is narrow and worth stating plainly. It shows whether an assistant reading your page finds a well-formed structure, a stable layout and a machine-readable summary, and whether your competitor's page does. It does not tell you who gets recommended, how often either page is quoted, or what any of it is worth. Those are separate questions and this score answers none of them.

Why fix this one before the performance score?

Because it is the only score on the report where a competitor can be measurably ahead of you on something you can close in weeks. Performance is a spectrum and everyone argues about it. Agentic Browsing is close to binary: you pass a check or you do not, the same three checks apply to your rival, and the category is new enough that most of any given field has not looked at it yet.

Eight of the nine failed the accessibility-tree check, including Squarespace's own marketing site. That is the finding worth carrying away: the common failure is not a missing AI file, it is that the page's structure is not legible to something that is not a browser. It is also the check nobody can pass by adding a file, which is why it is the one that separates sites.

Which three checks make up the score?

Six audits exist in the category and most sites are scored on three of them. We confirmed this against the PageSpeed Insights API on 29 August 2026 rather than from other write-ups, several of which disagree about whether the denominator is three or four. It is neither, fixed: the three WebMCP audits report “not applicable” on any site that has not implemented WebMCP, which today is nearly every site, so those drop out of the count and the remaining three are what you are scored on.

This is why two sites can show different denominators and neither is broken. Implement WebMCP and the count grows; skip it, as almost everyone has, and you are scored out of three.

What does “well-formed” actually mean?

It means no violation of thirty-three named rules. We read the audit's source rather than anyone's description of it: core/audits/agentic/agent-accessibility-tree.js on the Lighthouse main branch, checked 4 September 2026. The audit takes the axe-core violations already collected for the accessibility category and filters them to a hard-coded list.

The list runs from button-name, link-name and labelthrough the ARIA family, aria-required-attr, aria-valid-attr-value,aria-required-children and the rest, to tabindex,autocomplete-valid and svg-img-alt. Thirty-three identifiers, and you can count them yourself in the file.

That changes how a failure should be read. A site with a single unnamed icon link and an otherwise clean structure fails identically to a site built entirely from unlabelled divs. Nothing in the score distinguishes them. If you are looking at a failing audit, open the table: it lists the failing rule, and Lighthouse shows only the first offending element per rule, so the visible list is shorter than the real one.

Worth pinning the version if you quote the count. We read the main branch on 4 September 2026; write-ups elsewhere say thirty-eight, and the build running inside PageSpeed Insights on the day you test may not match either.

What the standard says, as opposed to the audit

The phrase “well-formed accessibility tree” is Lighthouse's own. It is the audit's title string, sitting in that same file astitle: 'Accessibility tree is well-formed'. WAI-ARIA defines the tree itself without ever using the word.

WAI-ARIA 1.2, a W3C Recommendation since 6 June 2023, defines an accessibility tree in its glossary as a “tree of accessible objects that represents the structure of the user interface”. Each node is an element as exposed through a platform accessibility API. That definition sits in a section marked non-normative; the requirements about which elements must and must not become accessible objects are in Section 7.

Who reads the tree, besides screen readers?

Five of the six assistive technologies the specification names are not screen readers. WAI-ARIA 1.2 lists screen magnifiers, screen readers, text-to-speech software, speech recognition software, alternate input technologies such as head pointers, on-screen keyboards, single switches and sip-and-puff devices, and alternate pointing devices.

Section 3.3 is normative and it is the part that matters here. It states that speech recognition systems and alternate input devices require the ability to control a web application device-independently, and that user agents must provide a way to notify the application when a state or property changes through the accessibility API. Microsoft's own UI Automation documentation says the same API lets automated test scripts interact with an interface, and its Win32 accessibility page lists the expected clients as screen readers, magnifiers, speech recognisers and eye trackers.

How do you fix each of the three?

Read which audit failed before touching anything, because the three have nothing in common and the wrong fix costs a week. Below is what each failure means and where the work actually sits.

Accessibility tree is well-formed

This fails when controls have no accessible name, headings skip levels, landmarks are missing, or interactive elements are built from divs with click handlers rather than buttons and links. An assistant reads your page through roughly the structure a screen reader uses, so the fix is ordinary semantic HTML: real buttons, labelled form fields, headings in order, alt text that describes the image. There is no AI-specific markup to add. A page-builder site fails this most often because the builder emits nested divs where elements should be, which is also why the fix is sometimes the template rather than the page.

Cumulative Layout Shift

The threshold is 0.1 or below. One site we measured returned 0.906, roughly nine times over. Layout shift comes from images and embeds without dimensions, fonts that swap after paint, cookie banners and chat widgets injected late, and ads that reserve no space. It is the most mechanical of the three to fix and the most commonly ignored, because it looks like a design nuisance rather than a machine-readability problem. Set explicit width and height on media, reserve space for anything injected, and load fonts so they do not reflow the page.

llms.txt follows recommendations

This one is a single file at the root of your domain, and it is the cheapest point on the board. The most common failure is not a malformed file but no file at all; on one site we tested the audit reported the fetch had timed out, which counts the same as absent.

Be clear about what you are buying, though. We have written separately about how rarely answer engines request this file. Passing this audit earns a Lighthouse point and does not, on the evidence we have, meaningfully change whether an assistant quotes you. Add it because it is ten minutes of work and a check on a report someone will run, not because it is the thing that gets you cited. Anyone selling llms.txt as an AI visibility strategy is selling you the easiest third of an experimental score.

How to Test and Resolve the Current Checks

Diagnose before choosing a fix. A missing accessible name may be a component defect; layout movement may come from dimensions, fonts, ads, consent tools, or injected content; a tool-registration failure may be configuration or timing. Some sites need targeted repairs. A migration is appropriate when the current platform or architecture blocks the agreed controls, not merely because one experimental audit failed.

What to Do Now

The trap with anything labeled “the future of the web” is overbuilding for a standard that has not landed. So here is the honest sequence, in order.

• ✓
  Record the current Chrome and Lighthouse versions, URL, page state, consent state, viewport, and individual audit output.
• ✓
  Fix semantic and accessibility defects because they affect people and supported agents, then regression-test the actual controls.
• ✓
  Treat llms.txt as a maintainable discovery file for named consumers, not a ranking or citation lever.
• ✓
  Prototype WebMCP only for a defined journey with security, privacy, fallback, origin-trial, and acceptance requirements.
• ✓
  Measure agent task completion, referrals, and sales separately from the Lighthouse pass ratio.
• ✓
  Watch for one specific trigger: the point at which the WebMCP audits stop reporting Not Applicable for ordinary sites and start being scored. That is the signal that the action layer is worth building, and it costs nothing to wait for.

The Bottom Line

Lighthouse's experimental category is useful when treated as a versioned diagnostic. It highlights selected accessibility, stability, discoverability, and tool-registration conditions. It does not rank your site, certify every agent, or forecast business results.

If these checks are relevant to a migration, we can put the supported pages, environment, audit version, pass criteria, and exclusions into the accepted scope. The primary deliverable is a tested migration plan, not an open-ended promise that every future audit or agent will pass.

Frequently Asked Questions