I spend a fair amount of time in PageSpeed Insights and Lighthouse, possibly too much for my mental health. Performance optimization is a regular part of the web development work I do, so I’m used to looking at the familiar categories: Performance, Accessibility, Best Practices and SEO.
Recently, another category started appearing: Agentic Browsing.
My first reaction was probably similar to a lot of developers: What exactly is this measuring, and is it something I actually need to worry about?
There is no shortage of discussion right now about making websites “AI-ready.” Some of it is useful. Some of it feels like the early days of SEO, when every new development created an entire industry of people promising to sell businesses a shortcut.
So I wanted to take a closer look at what Agentic Browsing actually means, what Lighthouse is checking, and what I think website owners should be doing about it right now.
First, what is agentic browsing?
The basic idea is fairly straightforward.
Most of the interaction we have traditionally designed for on the web is human interaction. Someone visits a website, reads the content, clicks through the navigation, fills out a form, filters products or completes a purchase.
AI agents introduce another type of visitor.
Instead of simply finding and summarizing information, an agent may need to interact with a website on a user’s behalf. That could mean finding a particular product, completing part of a reservation process, entering information into a form or navigating a complicated support process.
Chrome describes this as the distinction between agents searching the web and agents using the web. The new Lighthouse Agentic Browsing category is focused on that second part: whether an agent can reliably understand and interact with a website.
That distinction matters.
Making information easy to find and understand is not the same problem as making an interactive process predictable enough for software to complete reliably.
What is Lighthouse actually checking?
The name “Agentic Browsing” makes the audit sound more mysterious than it really is.
At the moment, Lighthouse is looking primarily at three areas: accessibility, layout stability and WebMCP integration. The category does not currently produce the same kind of weighted 0–100 score used for Performance or Accessibility. Chrome describes it as informational and unbenchmarked while the standards around agent interaction continue to develop.
The first two areas should already be familiar to anyone building good websites.
Accessibility
AI agents use many of the same machine-readable signals that assistive technologies depend on.
That means things like:
- properly labeled form fields;
- meaningful button and link names;
- valid HTML relationships;
- logical page structure;
- interactive elements that are represented correctly in the accessibility tree.
Lighthouse specifically checks parts of the accessibility tree that are important to machine interaction, including programmatic names, valid roles and whether an interactive element is hidden from the accessibility tree.
This is one of the more interesting things about the Agentic Browsing discussion.
A website built with semantic HTML and accessibility in mind is already starting from a better position. The work that helps someone using a screen reader understand and operate a website can also make the site easier for an automated agent to understand.
That should not be interpreted as “accessibility is for AI.” It isn’t. Accessibility is for people.
But it is another example of good development practices producing benefits beyond their original purpose.
Layout stability
Lighthouse also looks at Cumulative Layout Shift, or CLS.
This has been part of the Core Web Vitals conversation for years. A common example is a user preparing to click a button only for an image, advertisement or other piece of content to load and shift the button somewhere else.
That is annoying for a person. It can also cause problems for an agent that identifies an interface element and then attempts to interact with it after its position has changed.
Chrome’s Agentic Browsing guidance specifically includes visual stability as one of the signals used to assess whether an agent can reliably interact with a page.
Again, this is not really a new argument for building stable interfaces. It is a new reason that an existing best practice may become even more important.
Then there is WebMCP
WebMCP is the genuinely new part of this.
It is a proposed web standard that allows a website to expose structured tools that an AI agent can use. Chrome’s documentation describes two approaches: a declarative API that adds machine-readable information to HTML forms, and an imperative JavaScript API for more complex interactions and application logic.
The easiest way to think about it is this:
Without a structured tool, an agent might have to inspect a page, identify a button, determine what it does, click it, wait for a response, find the next field and continue repeating that process.
With WebMCP, a website could explicitly describe an available action and the data needed to complete it.
Chrome uses examples such as checkout, filtering results, submitting an application and navigating complex booking processes. WebMCP is intended to give agents clearer instructions about what actions are available, what inputs they require and how those actions relate to the current state of the page.
There is real potential here, especially for complex web applications.
But the important phrase is potential.
WebMCP is still a proposed standard and is under active development. Chrome’s own documentation notes that it is subject to change.
I would pay attention to it. I would experiment with it where appropriate. I would not recommend that every business immediately rebuild its website around it.
What about llms.txt?
The Agentic Browsing section in Lighthouse also checks for llms.txt, which has become another topic of interest for website owners and developers.
The idea is simple: an llms.txt file placed at the root of a domain can provide a concise, machine-readable overview of the website and links to important content.
Chrome currently describes llms.txt as an emerging convention, and its Lighthouse audit treats the file as optional. A missing file results in an N/A result rather than a failed audit.
I have started adding these files to some websites because they are lightweight, straightforward to implement and potentially useful as AI systems continue to interact with website content.
But I also think it is important to be realistic about what an llms.txt file is.
It is not a magic AI SEO file.
Adding one to a website does not compensate for poor content, confusing architecture, inaccessible navigation or a technically broken site. It is a supplemental machine-readable resource, not a replacement for building a good website.
Should businesses be doing anything right now?
My answer is yes, but probably not what some AI optimization services would like to sell you.
I would not start by asking, “How do we optimize our website for AI agents?”
I would start with more basic questions.
Is the HTML structured properly? Are forms labeled correctly? Can the website be navigated with a keyboard? Does the layout move around while the page loads? Is the navigation predictable? Are important pages easy to find? Are forms and other interactive features built in a way that makes their purpose clear?
Those things matter to human visitors today. They matter to search engines. They matter to assistive technology. And increasingly, they may matter to AI agents interacting with the web.
For most business websites, that is where I would put the effort first.
A well-built website is in a much better position to adapt to whatever agentic browsing becomes than one built on layers of fragile scripts, inaccessible components and confusing interactions.
My take on Agentic Browsing
I think Agentic Browsing is worth paying attention to.
AI tools are moving quickly from answering questions about information to taking actions on behalf of users. It is reasonable to expect that websites will need better ways to communicate their capabilities to those systems.
WebMCP is one possible part of that future. The new Lighthouse audits give developers an early way to examine some of the issues involved.
But I also don’t think website owners need to panic.
A lot of what Lighthouse is rewarding right now comes back to things good developers should already care about: semantic structure, accessibility, stable interfaces and predictable interactions.
The newer pieces, including WebMCP, are interesting and worth following. They are also still developing.
For now, my approach is pretty simple: continue building websites properly, test the emerging technologies as they mature, and avoid pretending that anyone knows exactly what the “AI-ready website” checklist is going to look like two years from now.
The web has been through plenty of major changes before.
The technology changes. Good fundamentals tend to hold up.