Agentic browsing

It assesses whether an AI agent can independently capture and use the content, functions and forms of a page, and groups this into four signal areas: the presence of an llms.txt in the domain root, WebMCP tool registration, the integrity of the accessibility tree and Cumulative Layout Shift (CLS).

What agentic browsing in Lighthouse is exactly

With Lighthouse 13.3.0 (released on 7 May 2026), agentic browsing moved from experimental status into the default configuration. The category now runs automatically in a regular Lighthouse audit without you having to set an experimental flag. PageSpeed Insights has also inherited the category, so the audit is visible both in a local Lighthouse instance and in Google's public tool.

The decisive difference to the classic Lighthouse categories such as Performance, Accessibility or SEO is how the result is presented. Agentic browsing does not deliver a weighted score between 0 and 100. Instead you see a readiness checklist: each audit item passes or fails, and the tool shows a proportional pass rate such as 3/3 or 2/4. This logic makes the category more of a diagnostic list than a grade. You can see at a glance which concrete technical prerequisites for agentic use are met and which are missing.

Important for putting this into context: Google collects data with this category and gives signals. Agentic browsing is not a ranking factor. The results therefore do not directly influence your position in the classic search results. They are a technical readiness signal for how well an AI agent can work with your page. The underlying standards are explicitly marked as "proposed" or experimental, which means that audit items and scoring logic may still change in coming versions.

The four signal areas in detail

Agentic browsing checks whether an AI agent can understand and operate a page on the basis of four signal areas. Each area addresses a different layer of machine readability:

• llms.txt in the domain root: the audit checks whether an llms.txt file is located at the root of the domain. This file is intended as a structured signpost for large language models and is meant to tell an agent in compact form which content and resources of a site are relevant.
• WebMCP tool registration: this checks whether the page registers tools via the experimental WebMCP protocol, i.e. declares functions and forms in such a way that an agent can discover and call them.
• Accessibility tree: this checks the names and labels of elements, the integrity of the role and tree structure (role/tree integrity) and visibility. A clean accessibility tree is decisive not only for screen readers but also for agents that interpret the page via the same semantic layer.
• Cumulative Layout Shift (CLS): layout stability from the Core Web Vitals also feeds in. If the layout shifts after loading, an agent can miss elements or trigger the wrong actions, so a low CLS counts as a positive signal.

Why agentic browsing is becoming relevant for site operators

The logic behind the category results from a shift in usage behaviour. Increasingly, it is not only people who interact with a website but also AI agents that carry out tasks on a user's behalf: booking an appointment, putting a product in the basket, filling in a form or gathering information from several sources. A browser such as Chrome is experimenting with mechanisms that give such agents direct access to page functions. Agentic browsing in Lighthouse is the yardstick for whether your page offers these agents a clean surface to work with at all.

For you as an operator this means: a page that works well for people is not automatically easy for agents to operate. An AI agent does not rely on visual design but on the semantic and structural layer. If a clean accessibility tree is missing, buttons have no labels or the layout shifts, the agent stumbles at points that a human user would not even notice. The four signal areas cover exactly these break points.

A concrete example

Suppose you run an online shop and an AI agent is supposed to search for a product and put it in the basket on behalf of a customer. If you run a Lighthouse audit from version 13.3.0 onwards, the agentic browsing category automatically appears in the report. If there is no llms.txt at your-domain.com/llms.txt, this audit item fails. If the "Add to basket" button has no accessible label and can only be recognised by an icon, the accessibility tree check fails. If the layout shifts because a banner loads later, the CLS value gets worse. The result could then be 1/4, for example, and show you exactly at which three points an agent would fail. You can also run the same audit publicly via PageSpeed Insights without installing Lighthouse locally.

How to use the audit in practice

Treat agentic browsing as a diagnosis, not a grade. Because the result is a checklist, you can work through the failed audit items one by one:

1. Create an llms.txt in the domain root and list the central content and entry points of your site in it.
2. Check and clean up the accessibility tree: assign meaningful labels, make sure ARIA roles are correct and ensure that interactive elements are visible and named.
3. Reduce Cumulative Layout Shift by reserving space for elements that load later and by embedding fonts and images in a stable way.
4. Evaluate WebMCP if you want to enable agents specifically to call forms and functions, but bear its experimental status in mind.

Since the standards are considered "proposed", it is worth checking the official documentation regularly. Google documents the category's scoring logic here: Lighthouse agentic browsing scoring.

Agentic browsing in relation to classic search engine optimisation

It is worth clearly distinguishing agentic browsing from classic search engine optimisation, because the two are easily confused. Classic SEO aims to make a page appear as high up as possible in the search results when a person enters a search query. Factors such as relevant content, sensible internal linking, technical cleanliness and backlinks count for this. Agentic browsing, on the other hand, does not ask whether a page ranks well but whether an AI agent can also operate it once it has opened it. It is a readiness check for machine-to-machine interaction, not for visibility in the list of results.

This distinction is important because agentic browsing is explicitly not a ranking factor. A good result in this category does not automatically improve your position in the classic search results. What you improve is the probability that an agent that has already landed on your page successfully completes a task there. In a world in which users increasingly delegate tasks to agents, that is exactly what can make the difference between a completed and an abandoned process, for example between a completed contact enquiry and an agent that fails at the form.

At the same time there is a clear overlap: many measures that help with agentic browsing also contribute to other quality goals. A clean accessibility tree improves accessibility for people with disabilities and thus the Lighthouse Accessibility category. A low Cumulative Layout Shift has been part of the Core Web Vitals for years and affects the perceived quality for all users. Anyone who works through the failed audit items is therefore not doing isolated agent optimisation but improving the page on several levels at once.

Limits and open questions

Because agentic browsing is young and the underlying standard is marked as "proposed", you should treat the category with the necessary caution. Several points are still open today:

• The audit items may change. Since the standard is experimental, there is no guarantee that today's four signal areas will remain in this form. Lighthouse may add or adjust audit items or refine the scoring logic.
• Practical adoption is limited. WebMCP is at the origin trial stage, and the llms.txt concept is not yet established across the board either. A failed audit item therefore does not necessarily mean that a page is badly built, but often only that a very new feature has not yet been implemented.
• It is no guarantee of agent compatibility. Even a page with a full pass rate can cause problems in practice, for example when complex processes involve several steps and states that a checklist does not cover.

In practice this means: use agentic browsing as a useful early indicator and as a structured to-do list, but do not overestimate the individual pass rate. The biggest immediate lever lies in any case in the areas that make sense even without agents, i.e. a clean accessibility tree and a stable layout. WebMCP and llms.txt are the more forward-looking building blocks, whose effort you should weigh against their experimental status.

FAQ on agentic browsing

Is agentic browsing a ranking factor?
No. Google collects data through it and gives signals, but the category does not directly influence your position in the classic search results. It is a technical readiness signal for operability by AI agents.

Do I get a score from 0 to 100?
No. Unlike Performance or SEO, agentic browsing does not deliver a weighted score but a pass/fail checklist with a proportional pass rate such as 3/3.

Since when has the category been active by default?
Since Lighthouse 13.3.0 of 7 May 2026. Before that it was experimental. PageSpeed Insights has also adopted the category.

Which four areas are checked?
The presence of an llms.txt in the domain root, WebMCP tool registration, the integrity of the accessibility tree and Cumulative Layout Shift (CLS).

Are the standards final?
No. The underlying standards are explicitly marked as "proposed" or experimental and may still change in coming Lighthouse versions.