Agentic Browsing: PageSpeed checks for AI agents | Ighenatt

The most misleading thing about the new Lighthouse Agentic Browsing category is the word “score”. SEO teams are trained to open PageSpeed, look for a number, argue about whether 89 is good enough, and move on. This category does not work like that.

Chrome’s documentation says Agentic Browsing is experimental and based on proposed standards. It also says testing the category requires Chrome 150 or later, and that WebMCP audits require the WebMCP origin trial. That matters because this is not a mature Search Console report, not a Core Web Vitals replacement, and not a ranking signal you can safely add to a sales deck.

It is something more practical: a set of deterministic checks for whether agents can understand and interact with a page with less guesswork.

For technical SEO and development teams in Spain and Europe, that makes the audit useful in a very specific way. It can expose the same problems that already hurt users: unlabeled controls, unstable layouts, vague forms, unclear site summaries and JavaScript-driven interactions that only make sense to a human staring at the screen. The difference is that the observer is now an agent.

What Lighthouse Agentic Browsing actually measures

Chrome describes the Agentic Browsing category as a way to evaluate how well a site is constructed for machine interaction through deterministic audits. That phrase is doing a lot of work. The audit is not asking whether your content is persuasive, whether your brand is strong, or whether Google should rank you above a competitor. It is asking whether a browser-level agent can identify tools, understand forms, read the accessibility tree, find machine-readable site context and interact with the UI without elements moving under its feet.

The category groups several signals. WebMCP integration checks whether the page exposes structured tools through declarative HTML or JavaScript. WebMCP schema validity checks whether those tools are described consistently. Forms missing declarative WebMCP identifies forms that could be annotated to make agent interaction more reliable. The llms.txt audit checks the availability of a machine-readable summary at the domain root. Accessibility for agents focuses on the accessibility tree. Layout stability uses CLS because moving elements can break coordinate-based or screenshot-assisted actions.

That mix is the point. Agentic readiness is not only “AI SEO”. It sits between web speed and SEO, web accessibility, structured interaction design and content governance.

Consider a product filter page. A human can often infer that a small funnel icon opens filters, that a custom range slider controls price, and that a delayed overlay is just a newsletter modal. An agent may need labels, state, stable positioning and explicit tool metadata. If the filter button has no accessible name, the form has unnamed inputs, and a banner shifts the button 400 milliseconds after page load, the task becomes brittle.

That is what this category is trying to surface. Not popularity. Not authority. Interaction readiness.

Why it is not a normal PageSpeed score

Classic Lighthouse categories, such as Performance or Accessibility, are familiar because they reduce many audits into a weighted 0-100 score. The Agentic Browsing category is different. Chrome’s scoring documentation says it does not currently use a weighted 0-100 average because standards for the agentic web are still emerging. Instead, the report shows a fractional score, pass or fail states for specific audits, and informational counts.

That changes how teams should read it. A 6/8 pass ratio is not equivalent to a Lighthouse Performance score of 75. It simply means six of the current readiness checks passed. A failing WebMCP schema audit may matter much more on a booking form than on a static blog post. A missing llms.txt may be marked not applicable because the file is currently optional, while a server error fetching the file is a real technical problem.

The useful habit is to treat the category like a deployment checklist. Did the page register tools? Are tool names and descriptions symmetrical? Do required fields have names? Are optional fields described with labels or tool parameter descriptions? Does the accessibility tree expose what an agent needs? Does CLS move controls after the agent has identified them?

This is also why deterministic checks matter. Chrome says Lighthouse uses deterministic signals so audits are reproducible and suitable for CI/CD. A deterministic audit is not an LLM vibe check. It is closer to a unit test for page affordances. The results can still fluctuate if JavaScript registers tools late, if DOM complexity changes the accessibility tree, or if layout shifts move elements during the snapshot. But the audit target is concrete.

The contrarian take: the absence of a 0-100 score is good. It prevents teams from compressing immature standards into a vanity KPI. For now, the win is not “raise our Agentic Browsing score by 20 points”. The win is “make the contact form, filters, booking flow or product configuration understandable to browsers that can act on behalf of users”.

WebMCP: explicit tools instead of UI guesswork

WebMCP is the newest part of the stack. Chrome presents it as a proposed web standard for exposing structured tools to AI agents. The goal is to help agents interact with a site by declaring what actions exist, what inputs are expected, and what state is available, instead of forcing the agent to infer everything from buttons, labels and visual position.

Chrome’s WebMCP page names three supported ideas: discovery, JSON Schemas and state. Discovery lets pages register tools such as checkout, filter results or submit an application. JSON Schema helps define inputs and expected outputs. State gives the agent a shared understanding of what resources are available on the current page. In practical terms, that means a support flow can expose a “submit_ticket” tool instead of asking an agent to click through nested menus and guess what each field means.

There are two implementation routes. The declarative API annotates standard HTML forms with attributes such as tool names and descriptions. The imperative API uses JavaScript, including navigator.modelContext.registerTool, to register tools programmatically. Lighthouse can list registered WebMCP tools, and Chrome says that audit is informational: if no tools are registered, the list is empty.

The schema validity audit is stricter. It fails when a form has tooldescription without toolname, when it has toolname without tooldescription, or when a required form field is missing a name attribute. It can also warn when optional fields are named but lack either a parameter description or an associated label. That is not exotic. Many forms fail this kind of discipline already.

A useful first target for a European B2B site is not the whole website. Start with forms that create commercial or operational value: contact, quote request, demo request, booking, support, search, lead qualification and product filters. If an agent cannot distinguish “company legal name” from “contact person”, or “VAT number” from “order reference”, the problem is not AI. The form was underspecified.

For JavaScript performance, there is another angle: if tool registration depends on late hydration, heavy bundles or fragile client state, Lighthouse may miss the tool during the snapshot. WebMCP makes interaction explicit, but it does not excuse slow, unstable or overcomplicated front-end architecture.

Accessibility is becoming the agent’s map

Chrome’s accessibility-for-agents documentation makes a simple point: agents review the accessibility tree to identify interactive elements. Accessibility standards are written for humans, but many of the same design principles help agents understand a website. Missing labels can block both users with visual disabilities and agents trying to complete a task.

That should feel familiar to anyone who has done a serious technical SEO audit. The accessibility tree is not a decorative layer. It is the machine-readable model of the interface. If a button’s visible text is replaced by an icon with no accessible name, the DOM might look fine to a designer and opaque to an agent. A modal that traps focus badly can leave the agent stuck in the same way a keyboard user gets stuck. When a custom select recreates native browser behavior poorly, the browser has less semantics to expose.

This is where SEO teams should be careful with ownership. Agentic Browsing is not only a developer issue. It crosses design system decisions, content labels, component APIs and QA. A reusable button component without a reliable accessible name rule can create hundreds of weak interaction points. A form builder that allows empty labels can quietly break conversion flows across languages. In multilingual sites, English, Spanish and Catalan labels need the same semantic care, not only translated visible copy.

There is a practical review pattern that works well. Open the page with Chrome DevTools, inspect the accessibility tree, then compare it with the user journey you expect an agent to complete. Can the agent identify the search box? The submit button? The required fields? The error messages? The current selected filter? If not, fix the semantics before writing any WebMCP layer.

This connects directly with AI Mode and conversational search. As search and browsing interfaces become more conversational, sites that express their structure cleanly will be easier to interpret. That is not the same as ranking impact. It is technical legibility.

Layout stability matters because agents can misclick too

CLS is usually discussed as a user experience metric: content jumps, users lose their place, and someone taps the wrong button. Chrome’s Agentic Browsing layout stability audit reframes the same issue for agents. Agents often rely on screenshots or coordinate-based interaction. If a button moves after the agent identifies it, the interaction can fail.

The cause list is familiar: images without dimensions, injected banners, late-loading ads, embeds, web fonts, hydration changes and UI components that reserve too little space. The difference is the failure mode. A human may compensate by looking again. An automated agent may click the old coordinate, type into the wrong input or abandon the flow.

For teams already working on Core Web Vitals 2026, this is useful alignment. CLS improvement is not only about the Page Experience report. It also reduces interaction uncertainty. The same remediation still applies: declare dimensions, reserve space for dynamic components, avoid layout-changing animations, handle cookie banners without pushing primary controls, and test forms after third-party scripts load.

A Spanish ecommerce example makes this concrete. Imagine a checkout page where a financing widget loads above the payment button after one second. The user sees a small jump. An agent that selected the payment button by position may now be pointing at a different element. The layout shift is no longer just annoying; it corrupts the action path.

This is why Agentic Browsing belongs in QA for high-value flows. Run it on templates, not only the homepage. Category pages, product detail pages, lead forms, booking pages and support forms are more important than a polished marketing hero. If an agent can browse your homepage but cannot complete a quote request, the implementation is mostly theatre.

llms.txt is optional, but server errors are not

Chrome’s llms.txt audit is deliberately cautious. It describes llms.txt as an emerging convention for providing a machine-readable summary of a website’s content for LLMs and AI agents. The audit attempts to retrieve the file from the domain root. If the server returns a 404, the audit is marked not applicable because providing the file is currently optional. If a server error occurs, Lighthouse flags the page.

That is the right level of pressure. A missing llms.txt should not be treated as a catastrophe. A broken endpoint at /llms.txt is different because it suggests misconfiguration: routing, deployment, headers, file generation or CDN behavior.

For SEO teams, llms.txt is most useful as editorial governance. It should explain the site’s purpose and link to key resources in concise Markdown. It should not be a second sitemap with every URL. On a technical SEO site, a good file might point agents to canonical guides on llms.txt and AI SEO, Core Web Vitals, accessibility, AI visibility and service pages. Each link should have a reason to exist.

The trap is overclaiming. Chrome’s audit checking for llms.txt does not prove that Google Search uses the file for ranking. It does not prove that ChatGPT, Claude, Perplexity or Gemini will cite you. It proves that the file can help compatible agents understand the site faster, and that Lighthouse can check whether the root file behaves cleanly.

Use the file as a public index of what you want machines to read first. Keep it short, canonical and reviewed. If you publish in multiple languages, do not blend language versions randomly. Declare sections clearly, use canonical URLs, and review it after migrations, service changes, major content updates and changes to robots.txt.

How to use the audit without overreacting

A sensible rollout starts with page types. Do not run Agentic Browsing once on the homepage and call the site “ready for agents”. Select a representative set: homepage, service page, blog post, category page, internal search, contact form, lead form, ecommerce filter, product page and checkout if relevant. For each page type, record the pass ratio, failing audits and informational results.

Then classify issues by user value. Accessibility labels and CLS problems should move to the normal web quality backlog because they help humans and agents. WebMCP should be prioritized where structured agent actions make sense. A newsletter form may only need basic declarative metadata. A travel booking flow, diagnostics dashboard or product configurator may need imperative tools, state handling and stronger security review.

Chrome also documents WebMCP limitations. Tool calls require a browser tab or webview with visible context; there is no headless tool-calling support. Complex sites may need extra JavaScript or refactoring to manage interface state. Clients and browsers must visit the site to discover callable tools. WebMCP APIs are also gated by origin isolation and permissions policy. Those constraints make it a progressive enhancement, not a universal layer to bolt onto every page overnight.

Security deserves a separate pass. If a tool can submit a form, change account settings, book an appointment or start a purchase, the user should stay in control. Chrome’s WebMCP overview notes that sensitive actions can include a command that requests user interaction with a confirmation dialog. In European contexts, add privacy review too: consent flows, personal data fields, retention wording and analytics should remain understandable to the user.

The working rule is simple: fix the boring fundamentals first. Semantic HTML, labels, stable layouts, clean forms, accessible errors and clear content hierarchy will improve Agentic Browsing results and normal user experience at the same time. WebMCP comes after that, where explicit tools create measurable reliability.

A practical checklist for SEO and dev teams

Use this checklist in the first audit pass:

• Confirm the test environment uses Chrome 150 or later for the Agentic Browsing category.
• Treat WebMCP-related audits as experimental and check whether the WebMCP origin trial applies to the test.
• Run the audit on important templates, not only the homepage.
• Record fractional pass ratio, pass-fail results and informational counts separately.
• For forms, check toolname, tooldescription, input name attributes, labels and field-level context.
• Inspect the accessibility tree for primary actions, required fields, errors, navigation and filters.
• Check CLS on the same pages with Lighthouse and your existing Core Web Vitals workflow.
• Fetch /llms.txt directly and verify whether it returns 200, 404 or a server error.
• Do not report Agentic Browsing findings as ranking improvements unless Chrome or Google Search documentation explicitly says so in the future.
• Add repeatable checks to CI only after the team agrees which page types and failures matter.

The first commercial win is likely not an abstract “agentic score”. It is a form that agents and assistive technologies can understand, a checkout that does not move controls mid-action, or a support page that exposes the right task clearly. That is useful even if the standards change.

Run the audit, but keep your head. The category is experimental. The browser requirements are specific. WebMCP is still in an origin-trial world. The scoring model is intentionally not the classic 0-100 Lighthouse number.

What is stable is the direction of travel: browsers are starting to evaluate whether websites can be acted on by software, not only rendered for people. Sites with clear semantics, stable layouts, well-described forms and curated machine-readable context will be easier to operate. That is worth fixing now, without pretending it is already a ranking lever.

Frequently asked questions about Lighthouse Agentic Browsing

Is Lighthouse Agentic Browsing part of PageSpeed Insights?

It is a Lighthouse category documented by Chrome for agentic browsing audits. Availability in a given PageSpeed or Lighthouse workflow may depend on Chrome version, experimental support and WebMCP origin trial requirements. For reliable testing, follow Chrome’s current requirement: Chrome 150 or later for the category and origin trial registration for WebMCP audits.

Is a low Agentic Browsing pass ratio bad for SEO?

Not directly based on current Chrome documentation. The docs describe technical readiness for machine interaction, not a Google Search ranking factor. Treat failures as engineering and UX signals. Accessibility, CLS and form clarity may already matter to users and conversions, but do not claim a direct ranking impact from this category.

What should content-heavy sites do first?

Start with llms.txt, semantic HTML, heading clarity, accessible links and stable page layouts. WebMCP is more useful when the page exposes actions. A blog post does not need the same agent tooling as a booking engine, but it should still be readable, well structured, internally linked and easy to summarize.

What should transactional sites do first?

Audit the flows where an agent would act: search, filters, product options, cart, checkout, quote requests, demos, booking and support. These pages need labels, stable controls, clear validation errors, predictable state and possibly WebMCP tools. Test after cookie banners, personalization scripts and third-party widgets load, because that is where many layout and interaction failures appear.