If you ran Google Lighthouse with the most recent version of Chrome, you might see a category sitting there that wasn’t there last month: Agentic Browsing. The audit has no green, no score, no familiar gauge, just a list of checks with fail or pass. Google added it to measure how ready your site is for AI agents, and it works nothing like the Lighthouse numbers you know.
Why does this matter? Because a growing share of visits no longer comes only from a person scrolling the page. It comes from an agent acting on someone’s behalf, booking, comparing, buying, or pulling an answer. If an agent struggles to read your site or follow your links, it will struggle with the actions that matter more, like completing a purchase, and it can move on to a competitor with a better structure.
This audit is a signal of whether your site is built for agents or not. Passing these checks is how you stay in the consideration set as agents become the front door to your site.
So let’s walk through what each check means, how to run it, and what to fix first. Lighthouse itself calls the category “still under development and subject to change,” so expect parts of this to shift.
Agentic browsing in plain terms
Agentic browsing is an AI agent loading your page and trying to use it. The visitor is something like ChatGPT, Claude, Perplexity, or Gemini, acting on a person’s behalf. As AI chat takes off, browsing through agents may be where the web is heading. Instead of visiting a site to find a flight, you might ask an agent to book it for you. Your site has to be ready for that shift.
The audit landed in Lighthouse 13.3.0 on May 7, 2026, and it ships on by default.
It answers a different question from the rest of Lighthouse. Performance asks how fast your page loads. Agentic Browsing asks whether an agent can read your page and get something done on it.
Chrome’s reason for adding it
Agents stopped being a demo and started booking flights, filling carts, and pulling answers off live sites. An agent that hits a page built for human eyes has to guess. It reads pixels, hunts for buttons, and breaks when the layout moves.
Chrome wanted a way to measure whether your page cooperates or fights back. Google is explicit that this is early. The documentation says the focus is “to gather data and provide actionable signals rather than a definitive ranking” while the standards for the agentic web settle. That is why there is no 0-to-100 score, just pass and fail checks.
The four things it checks
The audit looks at four things. Each one maps to a fix you can make this week.
llms.txt
llms.txt is a short Markdown file you drop at your root, like yoursite.com/llms.txt. It sums up what your site is and links to your key pages, written for a machine rather than a person. The audit checks that the file exists, has an H1, runs long enough to be useful, and carries links.
You’ll also run into a bigger sibling, llms-full.txt, which packs the complete text of your pages into one file rather than a curated index, so an agent can pull everything in a single request. Lighthouse scores the plain llms.txt, but you can publish both and let agents grab whichever fits the job.
Worth noting what the audit ignores. The llms.txt spec also proposes serving a clean markdown version of each page at the same URL with .md appended, like yoursite.com/about.md. Lighthouse does not check for that, nor for pages served as content-type: text/markdown. It scores the index file and nothing else, so there is room for Google to extend this audit as the spec matures.
There is one more wrinkle. Google has said you don’t need an llms.txt, and Lighthouse checks for one anyway. Both things are true, so don’t lose sleep if you skip it for now.
The accessibility tree
This check catches people off guard. Agents read the same accessibility tree your screen reader users depend on, the structured map a browser builds from your page’s roles, names, and labels. Lighthouse pulls a slice of its accessibility audits into the category, the ones about names, roles, allowed ARIA, and how elements nest, so an unnamed button or an unlabeled form field fails here the same way it fails for a screen reader.
The surprise is how little your overall score protects you. The agent check runs pass or fail on a narrow set of machine-interaction rules, so a green Accessibility number buys you nothing. We ran a site that scores 92 on Lighthouse’s Accessibility category, and it failed the agent accessibility tree outright. The culprit was one line: a search box carrying aria-expanded and aria-haspopup with no role=”combobox” to back them up, which Lighthouse flagged as “Elements must only use supported ARIA attributes.” A human visitor doesn’t notice. An agent reading the tree gets a contradiction, a searchbox that also claims a popup listbox, with no clean way to tell what the field does. One wrong attribute on one element is enough to sink the check.
Clean those up once and the work pays off in three places at once: assistive tech, search crawlers, and now agents.
This site scores a green 92 on Lighthouse accessibility, yet fails the accessibility tree check in the Agentic Browsing audit.
Layout stability (CLS)
A layout metric in an AI audit looks odd until you picture how an agent works. Many agents act on a screenshot. They study the page, pick a target, and fire a click at those coordinates a beat later. Shift the layout in that gap and the agent hits where the button used to be, then the task fails.
The part most writeups skip is the timing. Lighthouse measures Cumulative Layout Shift during page load, but an agent clicks after the page settles, the moment a menu opens or a late banner pushes everything down. A clean CLS in Lighthouse can still hide the shifts that trip an agent. So pull your field CLS from Search Console under Core Web Vitals, since that number covers the whole session, then chase the shifts your own interactions cause after load, the ones the lab test never sees. Fix those and you’ve covered agents and your Core Web Vitals in one move.
WebMCP
WebMCP is the forward-looking check, and you should keep your expectations level. The other three fixes help an agent make sense of your page. WebMCP removes the guesswork. Your site registers its actions as named tools, think a search box or an add to cart, and the agent invokes one by name. Hunting for a Book flight button across a screenshot turns into a single call to bookFlight() with the dates already filled in.
The detail most posts gloss over: those tool calls run inside the visitor’s own logged-in session. If someone’s signed into your site, the agent acts as that user through the browser, with no separate API key and no OAuth dance. You get a typed function call with defined inputs and outputs in place of a vision model reading pixels and hoping.
You can register tools two ways, an HTML form annotation or a JavaScript call through navigator.modelContext. Either way the tools stay state-aware, so an agent only sees the actions that fit the page in front of it.
It’s early. Support lives in Chrome behind a flag, few agents call these tools yet, and most sites can park it for later. Learning it still pays off, because this shows where the whole thing is heading. For the full picture of how WebMCP exposes your site’s functions to agents, read the LOCOMOTIVE WebMCP guide.
One trap to flag before you trust a WebMCP result. The checks only fire when the browser running the audit has WebMCP switched on. Audit a full WebMCP site with the flag off and all three checks read Not Applicable, the same line you’d see on a site that never touched the protocol. We watched the official flight demo jump from three Not Applicables to three clean passes the moment we added the flag, with nothing else changed. So treat Not Applicable as a sign the audit never looked, rather than proof the tools aren’t there.
What the top 1,000 sites actually do
We ran this audit, flag on, against the top 1,000 sites on the Tranco list in June 2026. 985 returned a result. 15 timed out or blocked the browser. Another 349 were CDN and infrastructure domains with no real page to score, leaving 636 sites behind the numbers below.
WebMCP has almost no presence. Three sites had registered tools: forter.com, netgear.com, and optimizely.com. That is 0.3%. The live web has still not adopted it.
llms.txt does better, but it remains a minority habit. 186 sites served a file. Only 64 were valid. The other 122 had a file with problems, so most sites that try still get it wrong. The remaining 450 had nothing, which the audit marks Not Applicable rather than failing.
The accessibility tree is where the big names fall down. Of the 636 sites with a real page, 412 failed the agent check and 224 passed. Two in three of the most popular sites on the web hand an agent a tree it cannot read. This fix carries the most leverage, since the same work also covers screen readers and search crawlers.
Running the audit yourself
- Chrome DevTools. On a recent Chrome, open DevTools, head to the Lighthouse panel, and run it. The category shows by default, though you switch on experimental web platform features at chrome://flags for the WebMCP checks to appear.
- The CLI. It ships in the stable Lighthouse package, version 13.3.0, so you skip the beta browser. Run npx lighthouse@latest <url> –only-categories=agentic-browsing –chrome-flags=”–enable-experimental-web-platform-features” –output=html –output-path=report.html, then open report.html to read the fractional score and each pass or fail.
Turning that flag on in your own Chrome takes a few seconds. Open chrome://flags, search for Experimental Web Platform features, set it to Enabled, and let Chrome relaunch. After that the WebMCP checks read live, both in the DevTools Lighthouse panel and on any demo site you open. On an older Chrome that lacks the flag, grab Chrome Canary instead.
PageSpeed Insights doesn’t surface the category yet, so the four familiar gauges are all you’ll find there. Reach for the CLI instead.
Whatever you pick, test two pages: your homepage and one page that earns money, like a product or booking page. Those are the pages an agent will try to use.
How to know if you’re agent ready
People misread this part, so read it before a red check makes you panic. There’s no weighted 0 to 100 score. You get a fractional pass ratio, something like 3 out of 4, plus a pass, fail, or warning on each check.
The standards are young, so Google would rather hand you signals than score how agent-ready your site is today. That will likely change.
One quirk to know: if you don’t have an llms.txt file, that check comes back as Not Applicable instead of a fail. The file is optional right now, so a missing one won’t drag you down. The WebMCP checks do the same thing if you haven’t flipped the flag, they read Not Applicable rather than fail, which is the trap covered above.
Try it on a real WebMCP site
Want to see WebMCP work before you build it? Google Chrome Labs runs a set of demo sites you can audit or play with: a flight search, a hotel booking, a restaurant reservation, even a maze you steer by prompting the agent. Point Lighthouse at one with the flag on and the WebMCP checks light up. The running list lives in the Awesome WebMCP repo: Awesome WebMCP.
Fix these first
Don’t try to fix all of it at once. Start with the accessibility tree, since those fixes help users, SEO, and agents together. Tighten layout stability next, because you probably have the CLS data already. Add an llms.txt when you have a spare hour, it’s quick. Leave WebMCP for when agents use it on your stack.
The work here is ordinary technical hygiene, now with a scoreboard attached to it.
Google hasn’t called it a ranking factor, so treat it as a readiness signal you want to get ahead of. The sites that cooperate with agents early will have a head start when this starts to count for more.
Your move this week
Pick your two most important pages and run the audit. Write down what fails. Fix the accessibility flags first, then the layout shifts. That’s an afternoon of work that moves you forward on agents, on search, and on the humans using your site.
