PageSpeed Insights has scored Performance, Accessibility, Best Practices, and SEO for years. A fifth item quietly joined that row in 2026: Agentic Browsing. It answers one question that the other four categories ignore — can an AI agent actually work with this page?
This guide is about putting that check to work on your own site: running it, reading what each audit actually says, and leaving with a fix list.
What you'll finish with
Who this is for: SEOs, developers, and site owners who want to know how their pages behave when an agent browses them instead of a person.
What you'll have when you're done: a real Agentic Browsing result for your site, a check-by-check reading of what passes, fails, or doesn't apply, and a prioritized list of fixes.
Prerequisites: a publicly reachable URL, about ten minutes for the first run, and code access if you plan to fix anything the same day.
Definition of done: you can explain your fractional score audit by audit, and you can tell which failures genuinely block agents from completing a task on your page.
Where the check came from, and why now
The Agentic Browsing category did not exist a year ago. The rollout happened in three steps, all documented by Google:
- May 7, 2026: Lighthouse 13.3 adds the category to its default configuration, so it becomes part of a standard run.
- June 22, 2026: the Chrome for Developers blog announces it in "A developer toolkit to make your website agent-ready," alongside DevTools for agents and WebMCP guidance.
- July 20, 2026: Lighthouse 13.4.1 enables the category for the PageSpeed Insights API path and says the release should reach PageSpeed Insights "within 2 weeks." That puts the public rollout in early August 2026.
When I ran the check on September 11, 2026, the report footer read "Emulated Moto G Power with Lighthouse 13.4.1," and Agentic Browsing sat directly beside SEO. So the feature is live, not canary-only. It is also explicitly unfinished. The category description in the report says it plainly: "This category is still under development and subject to change."
One practical note before you start: PSI runs the category for you, on Google's side. You don't need Chrome 150 or an origin trial for the page-level checks. Local runs in Chrome DevTools are the ones with version requirements.
Run the check on your own site
- Open pagespeed.web.dev and paste your URL. Run it for mobile first, then repeat for desktop, since the two lab runs are scored separately.
- Wait for the lab data to finish. The field data at the top comes from the Chrome UX Report and loads fast. The Lighthouse run below it takes longer and is where the categories live.
- Find the score row. You'll see Performance, Accessibility, Best Practices, SEO, and then Agentic Browsing as a fraction instead of a 0–100 score.
- Expand the category. The audit list groups into Agent Accessibility, WebMCP, and the usual passed and not-applicable clumps.
- Open each failing audit. Every row expands to show the specific rule, element, or file behind the failure, which is what you need for a fix ticket.
The fifth category sits in the same row as the scores SEO teams check daily. Captured in PageSpeed Insights on September 11, 2026.
Quality check: confirm the Lighthouse version in the run details before you compare results with a teammate. PSI updates Lighthouse on its own schedule, and the category is still changing between versions.
If it fails: PSI occasionally returns an RPC timeout on heavy pages. It happened to me on a large site mid-research. Retry, or test the page in local Lighthouse instead.
Read the fractional score correctly
Agentic Browsing has no weighted 0–100 score, and that is deliberate. Lighthouse's documentation says the standards for the agentic web are still emerging, so the focus is on actionable signals rather than a ranking.
Here's the arithmetic that actually matters:
Display | What it means |
|---|---|
3/3 | Every scored check passed. Not-applicable checks are excluded. |
1/3 | One passed, two failed. The denominator is passed + failed checks only. |
0/3 | Nothing scored passed yet. Common on a first run against a heavy, ad-supported page. |
No fraction | All audits were not applicable or the category did not run. Check the run details. |
The trap is reading 1/3 as "33 percent agent-ready." It isn't a percentage of anything. It's a count: one of the three checks that could be scored on that page passed, and the audits that didn't apply were left out of the math entirely. In the report I captured, six audits ran, three were not applicable, and the remaining three produced the 1/3.
Scores also move between runs on the same page. The three causes Lighthouse names are dynamic tool registration (JavaScript-registered WebMCP tools can be captured or missed depending on timing), DOM changes that reshape the accessibility tree, and layout shifts from ads, unsized images, or injected content. If your number wobbles, that's usually why.
Walk the six audits
The current PSI build runs six audits. One more is coming: Lighthouse's development branch is already adding an ai-catalog.json check (Agent Resource Discovery) under a new Agent Discoverability group, so treat this list as version-dependent.
Audit | What it checks | What "not applicable" means |
|---|---|---|
Accessibility tree is not well-formed | A subset of accessibility rules focused on agents: programmatic names and labels, valid ARIA structure, and elements that stay interactive while hidden from the tree | Never; this always scores |
llms.txt does not follow recommendations | That | The file returned a 404. Missing llms.txt is treated as optional, not a failure |
Cumulative Layout Shift | Visual stability, so agents that act on element positions don't click the wrong thing mid-shift | Never; this always scores |
WebMCP tools registered | Whether the page registers any WebMCP tools through the declarative or imperative API | No WebMCP tooling was detected |
WebMCP form coverage | Declarative forms that are missing tool annotations | Same as above |
WebMCP schemas are valid | That registered tools publish valid input and output schemas | Same as above |
An expanded category view: two failures, one pass, and three not-applicable checks. The failing list is the shortest path to a work item.
The three WebMCP audits showing "not applicable" is normal in 2026. WebMCP is a proposed standard, in origin trial and early preview, with two APIs: a declarative one that annotates standard HTML forms, and an imperative one that registers tools from JavaScript. Most sites don't ship either yet, so most reports show three gray circles there. Gray is not red. Don't treat it as a failure.
Fix what the check flags
Four fix themes cover the six audits. The three WebMCP rows only need attention if you actually ship agent tools.
Make the accessibility tree agent-readable
Agents lean on the accessibility tree as their primary map of your page. It lists roles, names, and states. A button with no accessible name is a dead end for them, and for screen reader users.
Action: work through the failing rules from the expanded audit. The usual suspects are icon-only buttons, unlabeled form fields, links whose text is just "click here," invalid ARIA role combinations, and duplicate IDs referenced by ARIA. Prefer semantic HTML, add for attributes to labels, and give custom widgets an explicit role and tabindex when a native element isn't possible.
Expected output: the audit flips to passed, and your regular Accessibility score usually improves at the same time, because the Agentic Browsing version is a focused subset of the same checks.
Recovery path: if the fix list runs into the hundreds of elements, don't chase instances one by one. Fix the shared component, such as the icon-only button in your header, then re-run. One component often clears dozens of rows.
Ship an llms.txt that survives the format check
This one has a trap that catches careful people. The audit doesn't just check that /llms.txt exists. It checks the file's contents, and a file listing bare URLs fails, because the check looks for Markdown-style links.
Action: create /llms.txt at your root domain with an H1 heading and real Markdown links:
# Your Company
Short description of what the site covers and how it should be used.
## Key pages
- [Product overview](https://example.com/product)
- [Pricing](https://example.com/pricing)
- [Documentation](https://example.com/docs)Expected output: the audit goes green. A 404, by contrast, shows as not applicable, which is acceptable today. A 500-series response, or a fetch error, is a real failure that needs a server fix.
Quality check: fetch your own /llms.txt in a terminal and count the links. If they look like https://example.com/pricing with no brackets, the audit will fail even though the file is live and readable by humans.
One honest caveat: Google Search does not use llms.txt. Google's own AI optimization guide says the file "will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them." Write it for agent tooling that reads the convention, not for rankings.
Stabilize the layout so agents can aim
Layout shift matters more than it used to. An agent that locates a button and then clicks its coordinates will miss if an ad, banner, or late-loading image pushes the button 200 pixels down between those two moments.
Action: set explicit width and height (or aspect-ratio) on images and embeds, reserve fixed space for ad slots and consent banners, avoid inserting content above existing content after load, and animate with transform instead of properties that trigger layout.
Expected output: Cumulative Layout Shift below 0.1 in the lab run, which is the same threshold Core Web Vitals uses.
Quality check: the report's Layout shift culprits insight under Performance names the exact elements responsible. Start there rather than guessing.
Decide about WebMCP later
The three WebMCP audits only score if your site registers tools. If you run a booking flow, checkout, support form, or any structured task an agent could complete, WebMCP is worth a prototype: it tells agents exactly which tool to call instead of making them guess from the DOM. Chrome ships the feature behind an origin trial and a local testing flag, so it's a real option, not a thought experiment.
If you don't have a task worth automating, leave WebMCP alone. Nothing is wrong with three gray circles. The one thing not to do is register a decorative tool just to make the fraction look better. The category is a readiness signal, and gaming it defeats the purpose.
Verify the fix
Re-run the same URL in PSI and compare three things, not one: the fraction, the specific audit statuses, and the device type. A fix can move the fraction without fixing the thing you cared about, and mobile and desktop produce separate lab results.
For faster iteration, run Lighthouse locally instead of waiting on PSI. The category is in Lighthouse 13.3 and later, so a local install picks it up. If you want the DevTools panel version, Google's documentation notes that testing the category requires Chrome 150 or later, and the WebMCP audits need the origin trial registered as well.
Keep a short record of the before-and-after. A dated line like "2026-09-11: mobile 1/3, failing a11y tree + llms.txt" is enough. It tells you whether a later regression is real or just a run-to-run wobble.
What this check is not
Three things it does not do, because the confusion is widespread:
- It is not a ranking factor. Chrome's announcement calls the category informational and unbenchmarked. Google Search rankings are unaffected by your Agentic Browsing fraction.
- It is not an AI visibility score. It measures whether an agent can operate your page. It says nothing about whether ChatGPT or Perplexity cites you in an answer.
- It is not a pass/fail verdict on your site. A low fraction on a simple marketing page usually means there was little to score, not that agents are locked out.
The lens that helps: this category checks whether your site holds up when the visitor isn't human. Everything it rewards is worth doing anyway: semantic HTML, stable layouts, labeled controls. Google's own agent-friendly guidance closes on the same point, that what makes a site agent-ready also makes it better for humans.
Keep it on your review loop
Agent readiness is one of those areas where the platform is moving faster than the checklist. Two habits keep you current without turning it into a project:
- Re-run the check after any template, navigation, form, or checkout change. Those are the edits that move the accessibility tree and layout stability.
- Track the fraction per template, not per URL. Ten product pages that all score the same way is a template problem, and one fix resolves all ten.
The PSI check is deliberately narrow: six audits, one page at a time. If you want the wider picture, including whether your robots rules, MCP server cards, OAuth discovery, and agent commerce signals are in place, Auspia maintains a free Agent Readiness check that scans a URL against those protocol-level standards and shows a leaderboard for comparison.
FAQ
Does the Agentic Browsing score affect Google rankings? No. Google describes the category as informational, and it is not part of Search ranking systems. Treat it as a readiness check for agents, not an SEO score.
Why did my fraction change between two runs on the same page? Dynamic tool registration, DOM changes that alter the accessibility tree, and late layout shifts all cause run-to-run variance. Re-test, and compare the audit list rather than only the fraction.
Why do all three WebMCP audits show as not applicable? Because your page doesn't register WebMCP tools. That's the expected state for most sites in 2026, and it isn't a failure.
Is a missing llms.txt a problem? For this audit, no. A 404 is treated as not applicable. A file that exists but is malformed does fail, so if you publish one, publish it correctly.
Can I run this in CI? Yes, once the category is in your Lighthouse version. The audits are deterministic by design, which is what makes them suitable for pipeline checks. Keep in mind that the WebMCP portions depend on browser support and origin trial enrollment, so expect those to read as not applicable in most CI environments.
Do I need Chrome 150 to use this at all? No. PageSpeed Insights runs it server-side. The Chrome 150 requirement applies to running the category locally in DevTools.
Author: Alice Monroe, AI SEO Tools Analyst covering 150+ tools at Auspia. Alice writes about SEO and AI search tooling, which checks are worth your time, and how to fold them into a working routine.
