Recent Lighthouse versions include an Agentic Browsing category that checks how well AI agents can read and use a page. It looks at the accessibility tree, WebMCP tools registered by the page, whether the site publishes an llms.txt file, layout stability, and the ai-catalog manifest if one exists. You run it like any other Lighthouse audit, and most of its failures are fixed once in a shared template.
Lighthouse has long measured performance, accessibility, best practices and SEO for people. This category asks a newer question: if an agent opens this page to do something for a user, can it understand what is there and act on it reliably?
What the category checks
| Area | What it checks |
|---|---|
| Accessibility tree | Elements have names, roles and a sensible structure |
| WebMCP | Tools registered in the page, and whether their schemas are valid |
| llms.txt | The site publishes a readable llms.txt |
| Layout stability | The page does not shift while an agent reads it |
| ai-catalog | The manifest, if present, matches its schema |
- The accessibility tree. Agents that operate a browser often read the same structure screen readers do: roles, names and states. Buttons without names, unlabeled fields and duplicate landmarks all make a page harder to operate. See how AI agents read web pages.
- WebMCP. Audits report the tools a page registers through the browser's model context API and check that their input schemas are valid. Our WebMCP guide explains the API.
- llms.txt. Whether the site publishes a readable llms.txt file.
- Layout shift. An agent that reads a page, then clicks where a button was a moment ago, fails the same way a person does. Cumulative Layout Shift is counted here too.
- The ai-catalog schema. If the site publishes
/.well-known/ai-catalog.json, it is validated against the draft specification. See agent skills and the ai-catalog.
The exact list of audits can change between releases. Treat the categories above as the current shape and check the report your version produces.
How to run it
The simplest route is the command line, which always gives you a current version:
npx lighthouse https://example.com/ --output=html --output-path=report.htmlThe report lists every category the installed version supports. To see which categories and audits your version has, run npx lighthouse --list-all-audits. Lighthouse in Chrome DevTools may lag behind the command-line release, so if the category is missing there, use the command line. Documentation for Lighthouse itself is on developer.chrome.com.
Audit on mobile settings, which is the default, and on more than the home page. Include a content page, a page with a form, and anything with a checkout.
Fix templates, not pages
When we audited this site, every issue in the SEO and agentic categories came from a shared file: the robots.txt, the header markup, or the ai-catalog generator. Fixing each once moved every page at the same time. That pattern is common, because most pages on a site share their chrome and head.
The fixes that moved our scores, all of them general:
- robots.txt validity. A non-standard directive we had added made Lighthouse mark the whole file invalid, which cost SEO points on every page. Removing it fixed it. Keep robots.txt to standard directives; see robots.txt for AI crawlers.
- ai-catalog schema. Our manifest had host fields and entry types the schema does not allow. We kept the host block to its allowed fields and listed only agent skills, with the standard skills media type.
- Duplicate landmark names. The header menu and the mobile menu were both named "Primary". Giving the mobile menu its own name cleared it.
- Decorative icons. An icon inside a button that already had a text label was exposed to the accessibility tree. Marking it
aria-hiddenfixed it. - Endless animations. Decorative diagram animations that looped forever used a property the browser cannot hand off to the graphics layer, which blocked the main thread on mobile. Running them a few times and stopping fixed the performance score as well.
Read the accessibility tree yourself
The audit tells you whether the tree is sound. To see what an agent sees, open Chrome DevTools, go to the Elements panel and switch on the accessibility tree view. Walk through your header, main content and forms. Every control should have a name that says what it does, every image should either have useful alternative text or be hidden as decorative, and the landmarks (header, navigation, main, footer) should each appear once with a distinct name. If a button reads as "button" with no name, an agent has no idea what it does.
Where performance comes in
Agents load pages in real browsers, often on limited resources, and they wait for the page to settle before acting. A page that keeps the main thread busy or keeps shifting slows every task an agent runs on it. That is why layout stability sits inside this category, and why fixing long main-thread work helps agents as well as people. Oversized images in the header, endless animations and render-blocking scripts are the usual causes, and each is fixed once in a template.
What Lighthouse does not check
Lighthouse audits one page at a time. Several agent-readiness signals live at the site level: Content Signals in robots.txt, the API catalog and Link headers, Markdown on request, and the agent skills index. Our free agent-readiness scan checks those across the whole site and explains each gap, so the two tools together cover both levels.
Keep the reports from each run. Comparing them after a release shows quickly whether a template change helped or quietly broke something for agents.
Next step
Run Lighthouse on three representative pages, group the failures by the file that causes them, and fix the shared ones first. Then run the agent-readiness scan for the site-wide checks. If you want the fixes done for you, our SEO work covers them.