Agent-friendly websites: the accessibility tree that ChatGPT, Claude and Gemini read

A website is agent-friendly when an AI assistant acting for someone, such as the agents in ChatGPT, Claude or Gemini, can tell what every button, link and form field is and use it. To do that, agents read the accessibility tree, the same structure screen readers use. Since May 2026, Lighthouse has checked it with 33 automated rules.

To check it on your own site: AI visibility audit

Until recently, preparing a site for AI was mostly about being read and cited, which is what our guide to AI search optimization covers. Agents add a new question. They do not just read a page: they book, compare, fill in forms and press buttons on someone's behalf. If an agent cannot tell what a button does, it will not press it, or it will press the wrong one.

What is the accessibility tree?

The accessibility tree is the summary the browser builds from your HTML: every element with its role (button, link, text field), its name and its state, stripped of styling. That is how web.dev, Google's site for web developers, describes it, adding that you can inspect it in Chrome's developer tools1.

Take this snippet from a product page:

<h1>Stainless steel stovetop espresso maker, 6 cups</h1>
<label for="quantity">Quantity</label>
<input id="quantity" type="number" value="1">
<button type="submit">Add to basket</button>
<a href="/delivery/">Delivery times and costs</a>

An agent receives something close to this, one line per element:

heading "Stainless steel stovetop espresso maker, 6 cups"
spinbutton "Quantity" 1
button "Add to basket"
link "Delivery times and costs"

No colours, fonts or positions: just what each thing is and what it is called. If the button were a <div> with an icon and no text, there would be nothing in that list to press.

How do AI agents see a page?

According to web.dev, an agent can perceive a page in three ways: a screenshot analysed by a vision model, the HTML and its structure, or the accessibility tree. Screenshots are slow and expensive in tokens, so they work best as a fallback. Current agents cross-reference the HTML and the tree, which give them a clean list of interactive elements, with the rendered image to understand the layout1.

The official sources agree on the role of the tree:

• Chrome. The Chrome team wrote in June 2026 that agents rely on the accessibility tree, derived from the DOM, as their primary data model, and that a well-formed tree is the main way they understand a page2.
• Google Search. Its guide to generative AI features says browser agents may analyse screenshots, inspect the DOM and interpret the accessibility tree to complete a task3.
• Anthropic. Claude's browser use tool in the API has a read_page function that returns the accessibility tree as text, with a reference for each element, so Claude can click by reference instead of by coordinates. The documentation recommends references whenever the page has a usable tree and keeps screenshots for what has none, such as a <canvas>. It also notes that reading the tree usually costs fewer tokens than a screenshot4.
• OpenAI. Its publisher FAQ, discussing the agent in its ChatGPT Atlas browser, explains that it uses ARIA tags, the same labels and roles screen readers rely on, to interpret page structure and interactive elements, and asks developers to give buttons, menus and forms descriptive roles, labels and states5.

The practical takeaway is simple: the tree is the cheapest, most reliable input an agent has. When it is broken, the agent has to guess from the picture.

What does Lighthouse check for agents?

Lighthouse 13.3.0, released on 7 May 2026, added a new Agentic Browsing category to its default configuration.6 Unlike the other categories, it does not give a 0–100 score: it shows how many audits pass out of the total. It covers the accessibility tree, visual stability (CLS), the llms.txt file and several WebMCP audits7.

The tree audit is called Accessibility tree is well-formed. Its source code is short: it takes 33 rules from the axe accessibility engine and passes the page only if none of them fails. There are no degrees: one failing rule is enough8. Grouped by what they ask for, here they are9:

Nearly all of them are long-standing accessibility rules. Chrome says as much: the audit is a subset of the accessibility checks2.

How to fix the most common failures

Most failures are fixed once, in the template, with ordinary HTML. The W3C's ARIA Authoring Practices Guide sets the order: bad ARIA is worse than none, because it misrepresents the interface, and an ARIA role does not give an element the keyboard behaviour a native one has10. Native HTML first; ARIA only where HTML falls short.

Icon buttons without a name (button-name). The classic case: the magnifying glass, the hamburger menu, the close icon.

<!-- Bad: the agent sees an unnamed "button" -->
<button class="icon-search"><svg>…</svg></button>

<!-- Good: the name is in the tree even though it is not visible -->
<button aria-label="Search"><svg aria-hidden="true">…</svg></button>

Things that look like buttons but are not. A <div> with a click handler does not appear in the tree as a button. web.dev uses it as an example of something an agent may not recognise as actionable1.

<!-- Bad -->
<div class="btn" onclick="book()">Book a table</div>

<!-- Good -->
<button type="button" onclick="book()">Book a table</button>

Fields without a label (label). Text next to a field is not its label unless it is associated with it: in the tree, the field has no name. Placeholder text counts as a name for the rule, but it disappears as soon as someone types, so use a real label.

<!-- Bad: the text sits next to the field but is not tied to it -->
<span>Email address</span>
<input type="email">

<!-- Good -->
<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email">

autocomplete must use the standard values (email, name, tel, postal-code and so on). A made-up value such as autocomplete="e-mail" fails autocomplete-valid.

Hidden content that can still take focus (aria-hidden-focus). This happens with closed menus and dialogs hidden with aria-hidden that leave their links active: the agent cannot see them in the tree, but the keyboard can still reach them.

<!-- Bad: hidden from the tree, reachable by keyboard -->
<nav aria-hidden="true"><a href="/shop/">Shop</a></nav>

<!-- Good: inert removes it from the tree and from keyboard focus -->
<nav inert><a href="/shop/">Shop</a></nav>

Duplicate IDs (duplicate-id-aria). If two fields use aria-labelledby="title" and two elements have id="title", the agent may get the wrong name. It often happens when one component is repeated several times on the same page.

tabindex greater than zero (tabindex). A tabindex="3" overrides the natural order of the page. Use 0 to make something focusable that is not, or better still, use the native element.

How to check your site

1. Chrome DevTools. From Chrome 150, the Lighthouse panel includes the Agentic Browsing category7. The tree audit lists the rules that fail with an example element for each one.
2. The DevTools Accessibility pane. In the Elements panel, the Accessibility pane shows the role and name of any element. It is the quickest way to see what an agent will see on a specific button.
3. Lighthouse on the command line, to check several templates or run it in an automated pipeline:

npx lighthouse https://www.example.com/booking/ \
  --only-categories=agentic-browsing --view

Check the templates where something gets done: product page, basket, contact form, booking, site search. Those are the pages where an agent needs to press things.

What this audit does not tell you

Read it with three clear limits in mind.

It is under development. The category's own description in Lighthouse says it is still under development and subject to change11, and Chrome calls it experimental and based on proposed standards7. It has already changed: version 13.5.0, released on 18 September 2026, added another audit and grouped it with the llms.txt one12.

It is not a ranking factor. No Google documentation presents it as one. Chrome describes it as informational and unbenchmarked2, and Google Search's guide treats agents as something to explore if they matter to your business and you have time3.

Passing does not guarantee an agent will finish the task. Agents also look at the screen and sometimes find an unnamed button by its appearance. And a perfect tree will not fix a confusing checkout.

Nor is it a full accessibility audit: it does not check contrast, text size or whether everything works with a keyboard. For that, see our guide to web accessibility and SEO. The good news is that what you fix for agents you also fix for people who use screen readers.

What about WebMCP and llms.txt?

They are related, but they answer different questions:

WebMCP can save an agent a lot of clicks, but only with agents that support it; every agent uses the tree. For what llms.txt is and what the data says about whether anything reads it, see our llms.txt guide.

What SmoothSeen checks

This blog belongs to SmoothSeen, so here is what the tool does. SmoothSeen runs the same 33 rules on every page it analyses, in its Lighthouse pass, and shows the result in the AI search half of the analysis as "Navigable by AI agents": a pass if none fails and, if any does, which rules fail with the affected HTML snippet. It also appears in the PDF report.

It does not replace testing your form with a real agent, but it tells you which template to start with. Getting an assistant to cite you, beyond operating the page, is a separate matter: the text has to arrive in the HTML, as explained in JavaScript SEO for AI crawlers.

Frequently asked questions

What does it mean for a website to be agent-friendly?

It means an AI agent acting for a person can understand what each element on the page is and use it: press the right button, fill in each field and follow the links. That requires buttons, links and fields with names, a page title and valid ARIA, because what the agent reads is the accessibility tree.

Does Lighthouse's Agentic Browsing category affect Google rankings?

No Google documentation says it does. Lighthouse labels the category as under development, Chrome describes it as informational, and Google Search's guide presents agents as an optional area to explore. Its value lies elsewhere: making sure the agents that book or buy on your customers' behalf can actually do it on your site.

Is it the same as meeting the WCAG accessibility guidelines?

No. The 33 rules are a subset of automated accessibility tests, focused on names, ARIA and IDs. WCAG also asks for sufficient contrast, full keyboard operation, resizable text and much more that no automated test can verify. Passing this audit is a good start, but it does not mean your site is accessible.

Do I need WebMCP or an llms.txt for agents to use my site?

No. Browser agents work with the HTML and the accessibility tree of any page. WebMCP is a proposed standard for declaring tasks to agents that support it, and llms.txt is a summary that no AI search engine has documented reading. The first step, and the one that helps every agent, is a well-formed tree.

What to do next

Run Lighthouse's Agentic Browsing category on your booking, contact or product page and fix unnamed buttons and fields first: there are usually only a few, and they live in a single template. Then work through the rest of our guide to AI search optimization.