# Get your site ready for AI agents: Lighthouse Agentic Browsing

> Lighthouse's beta Agentic Browsing category checks if AI agents can use your pages: accessibility tree, llms.txt, ARD manifest and WebMCP tools.

Published: 2026-11-15 · Author: AiroPages

Lighthouse's **Agentic Browsing** category checks whether AI agents, such as browser agents that read pages and fill in forms for a user, can understand and use your site. It was added in Lighthouse 13.3, is labeled as still under development, and focuses on the accessibility tree, layout stability and a few optional machine-readable files. The good news is that most of the work it asks for is ordinary accessibility and structure work you may already be doing.

## What the Agentic Browsing category is

Agentic Browsing is a fifth Lighthouse category, shown next to Performance, Accessibility, Best Practices and SEO. Google labels it as beta, so its checks and their details may change between versions. Treat it as an early signal, not a fixed standard.

It also scores differently. Instead of a 0 to 100 score like the other categories, Lighthouse shows Agentic Browsing as a **fraction of checks passed**, for example 3/4. Checks that do not apply to a page are left out. A site with no WebMCP tools, for example, is not marked down for the WebMCP checks; they simply do not appear. See the [Agentic Browsing glossary entry](/glossary/agentic-browsing) and [Lighthouse score](/glossary/lighthouse-score) for how it sits alongside the other categories.

## What it checks

The category has six checks. Two apply to almost every page; the rest only apply if your site uses the technology they test.

| Check | Applies to | What passes |
|---|---|---|
| Accessibility tree | Every page | A well-formed accessibility tree: semantic landmarks, headings, and named buttons, links and form fields |
| Layout stability | Every page | Low [Cumulative Layout Shift](/glossary/cls), so elements do not move while an agent acts on them |
| llms.txt | Sites that serve /llms.txt | The file follows the recommended format: a title, a short summary and lists of links |
| Agent resource discovery (ARD) | Sites that publish an ARD manifest | The manifest describing resources for agents is valid |
| WebMCP schemas | Pages that register WebMCP tools | The tools' input schemas are valid |
| WebMCP form coverage | Pages with forms | Lists forms that could get WebMCP annotations (informational only) |

### Accessibility tree

The accessibility tree is the structured view of a page that browsers build for assistive technology. It lists landmarks such as the header, navigation and main content, the headings, and every interactive element with its role and name. An agent that wants to "click the Add to cart button" needs that button to exist in the tree as a button, with a name.

### Layout stability

If elements shift while a page loads, an agent can click the wrong thing, just as a person can. This check uses the same CLS measurement as the Performance category, so fixing [common causes of layout shift](/blog/common-causes-of-layout-shift) helps here too.

### llms.txt, ARD and WebMCP

These three are optional. **llms.txt** is a plain-text file at the root of your site that summarizes it and links to the pages you most want AI tools to find. An **agent resource discovery (ARD) manifest** describes resources a site offers to agents. **WebMCP** lets a page register tools, each with an input schema, that an agent can call. Lighthouse only checks these if you publish them, and the checks are about validity: if you have one, is it well formed?

## Why accessible, well-structured HTML helps AI agents

AI agents that operate a browser need to work out what is on a page and what they can do with it. Clear structure makes that much easier. Many of the same signals a screen reader depends on, such as roles, names, labels and headings, also tell an agent what each part of the page is for.

Consider a checkout form built two ways:

- **Version A** uses `<label>` elements tied to each input, a real `<button>` that says "Place order", and a `<main>` landmark around the form.
- **Version B** uses placeholder text instead of labels, and a `<div>` with a click handler styled to look like a button.

A person with a mouse can use both. A screen reader user, or an agent reading the accessibility tree, sees a clear form in Version A and a set of unnamed fields plus some text in Version B. This is why the Agentic Browsing checks start with the accessibility tree, and why the fixes overlap so much with [accessibility at scale](/blog/accessibility-at-scale).

Well-structured HTML also helps AI assistants that read your content to answer questions. Descriptive headings, meaningful link text and clean titles make it easier for any system to work out what a page covers, which overlaps with the [technical SEO checks Lighthouse runs](/blog/technical-seo-checks-lighthouse-runs).

## Practical steps to get your site ready

Start with the changes that help everyone, then add the optional files only if they fit your site.

1. **Use semantic HTML.** Wrap content in landmarks (`<header>`, `<nav>`, `<main>`, `<footer>`). Use real `<button>` and `<a>` elements instead of clickable `<div>`s. Use headings in order.
2. **Name every control.** Icon-only buttons need an `aria-label` or visually hidden text. Linked images need alt text.
3. **Label every form field.** Use a `<label>` for each input. Placeholders are not labels, and they disappear once someone types.
4. **Keep the layout stable.** Reserve space for images, ads, embeds and banners, so nothing moves after the page renders.
5. **Publish an llms.txt if you want AI tools to find your key pages.** Keep it short: a title, a one-paragraph summary, and lists of links to your most useful pages, such as docs, pricing and guides.
6. **Add structured data.** Schema.org markup in JSON-LD describes products, articles, FAQs and organizations in a machine-readable way. It is not part of the Agentic Browsing checks, but it helps search engines and other systems understand your content.
7. **Consider Markdown versions of key pages.** Some sites publish plain Markdown copies of docs or guides, linked from llms.txt, so AI tools can read the content without the page chrome. This is optional and not something Lighthouse checks.
8. **Only add WebMCP or an ARD manifest if you use them.** If you do, validate them, because an invalid schema or manifest fails the check.

A minimal llms.txt might look like this:

```markdown
# Example Store

> Example Store sells refurbished office furniture in the US, with free delivery on orders over $500.

## Key pages

- [Pricing and delivery](https://example.com/delivery): Delivery areas, costs and times
- [Returns](https://example.com/returns): 30-day return policy
- [Product catalog](https://example.com/products): All chairs, desks and storage
```

## Common reasons pages fail

Most failures in this category trace back to a few familiar patterns, usually in shared components:

- **Icon-only buttons with no name**, such as menu, search, cart and close buttons in the header.
- **Custom controls built from `<div>` or `<span>`**, such as dropdowns, tabs and "buttons" that only work with a mouse handler.
- **Form fields without labels**, especially newsletter, search and checkout fields that rely on placeholder text.
- **Missing landmarks**, where the whole page sits in generic containers with no `<main>` or `<nav>`.
- **Late-loading banners and embeds** that push content down and raise CLS.
- **A malformed llms.txt**, for example one with no title or with links that are not in list form.

Because these live in templates, one fix usually clears the failure on every page that uses the component.

## How to check this across your whole site

The manual way is to run Lighthouse 13.3 or later in Chrome DevTools or with the CLI on each of your key templates, and read the Agentic Browsing section of each report. The accessibility tree and layout stability results will differ between templates, so test one page of each type at a minimum, and ideally every page, since a form or component that fails may only appear on some of them. The pillar post on why [Lighthouse only tests one page](/blog/lighthouse-only-tests-one-page) explains why a homepage test is not enough.

AiroPages runs the Agentic Browsing checks on every scan and shows the result for each site next to the four classic categories, along with the accessibility issues behind it, grouped by template.

## What to expect next

Because the category is in beta, expect it to change. Checks may be added, renamed or adjusted as AI agents and the related standards mature. The parts most likely to stay relevant are the ones that are not new at all: a clear accessibility tree, labeled forms and a stable layout.

That makes this an easy category to prepare for. Fix the structure and accessibility of your templates, keep layout shift low, and add llms.txt, ARD or WebMCP only when they serve a real purpose on your site. You will help AI agents, screen reader users and search engines with the same work.