PageSpeed Insights Agentic Browsing Explained: Why WebMCP Shows N/A (and How We Got 6/6)
The short answer: PageSpeed Insights shows the WebMCP checks as “not applicable” when the browser it tests with has no WebMCP support switched on for your page. Lighthouse, the engine behind PageSpeed, looks for document.modelContext first. If it is missing, all the WebMCP checks are skipped, whatever your forms look like. On our site the cause was an origin trial token that Chrome silently rejected. Once we loaded the token the right way, our quote page scored 6/6 for Agentic Browsing on mobile and desktop, and it still did when we re-ran it on 1 October 2026.
This article walks through the category audit by audit, explains the “not applicable” result in more depth than we could fit into our WebMCP guide, and lists the smaller things that cost us points along the way. It is written for developers and agencies, but we explain each term as we go.
What the Agentic Browsing category is
Agentic Browsing is a newer section of a Lighthouse report, sitting alongside Performance, Accessibility, Best Practices and SEO. Its own description in PageSpeed reads: “These checks ensure high-quality, browsable websites for AI agents and validate the correctness of WebMCP integrations. This category is still under development and subject to change.”
Two things make it different from the other categories:
- It shows a pass count, not a score out of 100. You will see something like 4/4 or 6/6. The total changes from page to page, because audits that do not apply are left out of the count.
- Some audits are informative only. They list what was found but never pass or fail.
When it arrived, and which version PageSpeed runs today
You will find different dates for this category online, and they are all partly right, because it came in stages. According to the Lighthouse release notes on GitHub:
| Lighthouse version | Released | What changed for this category |
|---|---|---|
| 13.2.0 | 1 May 2026 | ”agentic: add new agentic browsing category”, plus the llms.txt check and the three WebMCP audits |
| 13.3.0 | 7 May 2026 | ”New agentic browsing category added to default config” |
| 13.4.1 | 20 July 2026 | ”Enabled Agentic Browsing category via PSI API”, and the WebMCP gatherers now check document.modelContext |
| 13.5.0 | 18 September 2026 | Adds the ai-catalog.json (ARD) audit, and form coverage now passes instead of showing N/A when every form is covered |
So the category first appeared in Lighthouse 13.2.0 and became part of the standard run in 13.3.0, which is the version DebugBear wrote about in May. PageSpeed Insights showed it to us from September 2026. When we ran PageSpeed on our quote page on 1 October 2026, the report footer said “Lighthouse 13.5.0” and “HeadlessChromium 153.0.8010.36”. If you are reading this later, check the footer of your own report, because the version PageSpeed runs moves on with each Lighthouse release.
The audits, one by one
This is what PageSpeed showed for https://www.jwd.co.za/quote-request/ on 1 October 2026, with the audit names exactly as they appear in the report.
| Audit (as PageSpeed names it) | What it checks | Counted in the score? | Our result, and why |
|---|---|---|---|
| WebMCP tools registered | Lists every WebMCP tool the page registered, with its description and input schema | No, informative only | Always a grey circle. Ours listed get_jwd_packages, check_domain_availability and request_website_quote |
| WebMCP form coverage | Whether each <form> on the page is annotated as a WebMCP tool | Yes | Passed. Our only form has toolname and tooldescription. Shows N/A if WebMCP is off or the page has no forms |
| WebMCP schemas are valid | Whether the input schema of each tool is valid | Yes | Passed. Shows N/A if WebMCP is off |
| Accessibility tree is well-formed | A set of accessibility checks focused on how agents read the page structure | Yes | Passed, after we fixed two unlabelled dropdowns (see below) |
| Cumulative Layout Shift | Whether the page jumps around as it loads | Yes | Passed, with a value of 0 |
| llms.txt follows recommendations | Whether your /llms.txt file exists and follows the format | Yes | Passed |
| ai-catalog.json schema is valid | Whether your AI catalog file is valid | Yes | Passed, with a low severity note we chose to keep (see below) |
That is six scored audits passing, plus one informative audit, which is where 6/6 comes from. The mobile and desktop reports matched.
If you want the background on the last audit, our ai-catalog.json guide explains what the file is and who reads it.
Why WebMCP shows “not applicable”
WebMCP is a proposed standard that lets a web page describe its forms and actions to an AI agent running in the browser. Chrome is testing it through an origin trial, which is a way for a site to switch on an experimental feature for its own visitors by adding a token to its pages.
Most sites see the WebMCP audits as “not applicable”, and owners often read that as a fault. It usually is not. It comes from how Lighthouse collects the data. We read the source of the WebMCP gatherer in the Lighthouse repository (core/gather/gatherers/webmcp.js). In plain terms, it does this:
- It asks the browser whether
navigator.modelContextordocument.modelContextexists. - If neither exists, it records that WebMCP is not supported and returns an empty list of tools.
- All three WebMCP audits then return “not applicable”.
- Form coverage is also “not applicable” when the page has no
<form>elements at all.
So “not applicable” can mean any of three things: your site has no WebMCP and does not need it, your site has WebMCP but the browser never switched it on, or the page simply has no forms. Only the second one is a problem you can fix.
A useful way to tell them apart: if your page does have WebMCP attributes and PageSpeed still shows N/A, the browser never switched WebMCP on. That points at the origin trial token.
The token mistake, and the fix
This is where we lost an afternoon. Our WebMCP guide tells the full story, so here is the short version and the parts that matter for PageSpeed.
When we registered for the origin trial, the “third-party” option was ticked. We then put the token in a <meta http-equiv="origin-trial"> tag. Chrome rejected it. The Chrome DevTools Protocol command Page.getOriginTrials reported the token as WrongOrigin and the trial as ValidTokenNotProvided, even though the domain in the token was correct. A third-party token is only accepted when a script served from the token’s own origin adds it to the page.
The fix that worked for us:
- A small script on our own domain adds the token. It is loaded in the
<head>of every page as a normal, blocking script. After that, the same command reported the token asSuccessand the trial asEnabled, in plain Chrome 153 with no flags. - Do not add
deferorasyncto that script. We tried. The trial was enabled, but the forms were already parsed by then, so the form tools never registered. - The same script registers two read-only tools in code.
get_jwd_packagesreturns our published prices, andcheck_domain_availabilityruns our domain lookup. These are what PageSpeed lists under “Imperative Tools”, with our script as the source location. - The script URL carries a hash of its content. Our scripts are cached for a long time, so a new version must have a new URL or browsers keep the old one.
If you are registering a token today, leave the third-party box unticked unless you need it. We have not tested a first-party token in a meta tag ourselves, so treat that as the documented route rather than one we have proven.
To check your own token, open DevTools in Chrome, go to the Application panel, then Frames, and look at the origin trials for the top frame.
Why our homepage showed 5/5
After the token fix, our form pages passed 6/6, but the homepage showed 5/5 on mobile and desktop. Nothing was broken. The homepage had no <form> element, so “WebMCP form coverage” was not applicable and dropped out of the count. The informative audit still listed our two code-registered tools.
We did not want a fake form to tick a box, and you should not either. Instead we added something genuinely useful: a domain name search below the homepage hero, built as a declarative WebMCP tool that shows its results on the page. Because the homepage form now registers check_domain_availability itself, the site-wide script skips registering a second tool with the same name there. The homepage then passed 6/6, with form coverage passing.
That is the honest rule: the count reflects what is on the page. A page with no forms will show one fewer audit, and that is fine.
Other things that cost us points
Dropdowns with only a placeholder. Our quote form had two <select> fields that relied on a placeholder option instead of a proper label. That failed “Accessibility tree is well-formed”, dropped the quote page’s Agentic count to 3/4 (only four checks counted then, because WebMCP was not yet working), and pulled its Accessibility score down to 95. Adding an aria-label to each select fixed both. AI agents read a page through its accessibility tree, much as a screen reader does, so this is not just about the score.
Our live-chat widget blocked headless browsers. PageSpeed tests with a headless browser, and our chat provider’s server returned a 403 error to it. Chrome logged that as an error in the console, which cost a Best Practices point on every page. We now load the widget on the visitor’s first interaction, such as a scroll, tap, mouse movement or key press, so a page-load test does not request it. With a normal browser, the chat loads and works as before. The lesson: test third-party widgets with a normal browser as well, because a headless test can show problems a visitor never sees, and the other way round.
The ai-catalog.json note. “ai-catalog.json schema is valid” passes, but each of our catalog entries carries a low severity note: “Media type ‘application/vnd.oai.openapi+json’ is not one of standard discovery types”. When we ran Lighthouse ourselves, that audit scored 0.9 rather than 1. We kept the OpenAPI type, because it truthfully describes a normal web API and the ARD spec allows any media type. PageSpeed still shows the audit as passed.
A robots.txt line that broke SEO. The ARD spec mentions an Agentmap: line in robots.txt. We added it, and Lighthouse’s own SEO audit flagged it as an unknown directive and marked robots.txt invalid. We removed it. Run the full report after every change, not only the category you are working on.
Does any of this help Google rankings?
We have no evidence that it does. We have not seen Google say the Agentic Browsing category feeds into search rankings, and the category describes itself as under development. Some of its checks overlap with things that matter anyway, such as a stable layout and an accessible page. Treat the rest as preparation for AI agents that act in the browser, not as an SEO lever.
It is also worth being clear about who uses WebMCP today. When we asked ChatGPT to fill in our quote form, it read the page but could not operate the form. WebMCP is for agents running inside Chrome with the feature switched on. If you want to know whether AI assistants can reach and read your site at all, start with our agent-ready website checklist, which begins with whether your server lets AI crawlers in.
Need it done for your site, or white-labelled?
If you own a business website and want it reachable, readable and usable by AI search and agents, our AI search visibility and agent-ready websites service is where we do this work, including the server log checks most audits skip. If you run an agency and want this built for your clients under your name, see our white label web design page. Either way, request a quote and tell us about the site. We cannot promise an AI assistant will recommend anyone, but we can remove the reasons it would not.
Related reading: what these checks mean for a real enquiry form, in can ChatGPT fill in your contact form?, and the access problem no PageSpeed audit can see, in is your web host blocking ChatGPT?.
Frequently Asked Questions
Why does PageSpeed Insights show WebMCP as not applicable?
Lighthouse first checks whether document.modelContext or navigator.modelContext exists. If WebMCP is not switched on for the page, all three WebMCP audits are marked not applicable. Form coverage is also not applicable on a page with no forms.
Is a “not applicable” result bad for my site?
No. Most sites have no WebMCP, and not applicable audits are left out of the pass count. It only signals a problem if your page has WebMCP attributes and an origin trial token, and the audits still show N/A.
Why is “WebMCP tools registered” always grey?
It is an informative audit. It lists the tools Lighthouse found, with their descriptions and schemas, but it never passes or fails. Expand it to see whether your tools were detected.
Which Lighthouse version added the Agentic Browsing category?
The Lighthouse release notes show it was added in 13.2.0 and turned on by default in 13.3.0, both in May 2026. The ai-catalog.json audit came in 13.5.0. PageSpeed Insights was running Lighthouse 13.5.0 when we tested on 1 October 2026.
Does the Agentic Browsing score affect Google rankings?
There is no evidence that it does. We have not seen Google say it is used in search, and the category is marked as still under development. Some checks, such as layout stability and accessibility, are worth fixing for their own sake.
