In my last website report, there was a category that hadn’t existed the year before. It’s called ‘Agentic browsing’ and appears right at the bottom, after performance, accessibility and SEO. In my case, it initially showed 1 out of 2.
It took me a while to understand what Google is actually measuring here. And even longer to work out how seriously one should take it. The short answer: more seriously than the hype suggests, but less urgently than some people claim.
What is actually being tested here
Until now, websites have been assessed on the basis of how quickly they load, how user-friendly they are and whether search engines can understand them. All three factors assume that, ultimately, a human being is sitting in front of the screen.
This assumption is becoming less and less accurate. These days, when someone asks their AI assistant to find a tradesperson in the area or to compare prices, it is not the person who visits the website, but a programme acting on their behalf. And these programmes read a page in a completely different way to you and me.
The new category assesses four things:
- The accessibility tree. This is the structured version of your page, which was originally designed for screen readers. It has now become the most important source of information for AI agents.
- Visual stability. If elements shift whilst the page is loading, an agent may click in the wrong place.
- WebMCP. A proposed standard that enables a website to actively make its own features available to agents.
- A file called llms.txt. A machine-readable summary in the root directory of the domain.
Unlike the other categories, there is no score from 0 to 100, just a ratio of audits passed. Google itself says that, for the time being, the aim is to collect data, not to produce a ranking.
The point at which Google contradicts itself
And this is where it gets interesting. When it comes to llms.txt, two departments within the same company are saying different things.
The Search Team has published a guide in which llms.txt is explicitly listed amongst the things you do not need for visibility in AI search functions. John Mueller from Google has even publicly compared the file to the ‘keywords’ meta tag, that specification from the early 2000s which eventually came to be ignored by everyone.
At the same time, Chrome uses Lighthouse to analyse precisely this file.
The contradiction is resolved if you keep two things separate. For search and for citations in AI answers, llms.txt is genuinely of no use. However, it can help an agent that’s already on your site and needs to find its way around. It’s like the difference between a motorway signpost and a floor plan in the entrance hall.
My view: The file can be created in twenty minutes and costs nothing afterwards. You should just get on with it and not dwell on it any further. Anyone who sells it as a ranking tactic is selling you something that Google itself has ruled out.
WebMCP is actually the most exciting part
I find the second new module far more interesting, even though it is of little relevance to most businesses at present.
To understand why, you need to know how AI agents currently interact with websites. They load the page, take a screenshot of it, and let an image recognition model guess which area of the image is likely to be the search button. They then move the cursor there and click. This works surprisingly often, but it’s slow, prone to errors and breaks every time the website is redesigned.
WebMCP turns this on its head. Instead of leaving the agent to guess, the website registers its functions itself. In essence, it says: here is my search, it takes a search term and returns a list. The agent then calls the function directly, just as one programme calls another function. No screenshot, no guessing.
For an online shop or a booking system, this will be a big topic in the medium term. For a tradesperson’s website with a contact form, not for now.
And things are at a much earlier stage than the excitement suggests. WebMCP is running as an Origin Trial, you need to register for it, and a flag has to be switched on in Chrome. Anyone who builds WebMCP in today is building for a future that isn’t here yet.
Two out of four points are familiar faces
That’s the part I find most remarkable.
The accessibility tree and visual stability are not new requirements. Both have been around for years. Accessibility has always been a matter of semantic HTML, clean ARIA labels and elements with readable names. Layout stability has been a standard topic since the introduction of Core Web Vitals.
Anyone who has done their job properly in recent years automatically has a head start here. Anyone who has been sloppy is now paying the price a second time.
That’s exactly how it was for me. Of the four audit areas, only one really had an open issue, and the cause was a single link in my cookie banner that led nowhere and had no readable text. It was a mistake that would also have been a problem for a blind visitor using a screen reader. It’s just that nobody had ever reported it, because nobody clicks on links in the cookie banner.
After the repair and the additional text file, it showed 3 out of 3.
By way of comparison: large platforms with hundreds of developers fail precisely these checks. It is therefore not a question of company size, but of diligence.
What I would advise a business today
My order, from the most important to the least essential:
- Tidy up accessibility. Every image needs alternative text, every link needs meaningful text, and every heading needs to be at the right level. This helps people with disabilities, it helps search engines, and it now helps agents too. A threefold benefit, no need to gamble on the future.
- Stabilise the layout. Set fixed dimensions for images so that nothing jumps around when the page loads. This also improves the key metrics that Google has been evaluating for years.
- Create llms.txt. It takes twenty minutes, then you can forget about it. If the standard catches on, you’ll be part of it. If not, you’ve lost nothing.
- Monitor WebMCP. Don’t implement it just yet. Just keep an eye on it. If you run a shop or a booking system, this will become relevant in one or two years’ time. Not before then.
What I definitely do not recommend is spending money on consultancy firms that are trying to sell you ‘optimisation for AI search engines’ today. The market is full of them, and the vast majority of their claims cannot be substantiated.
Why the issue is still important
There’s one sentence I haven’t been able to get out of my head for weeks: the browser is changing its role.
For twenty years, a website has been a shop window for people. It had to look attractive, load quickly and be easy to understand. That remains the case. But alongside this, a second use is emerging, in which a machine visits the site, understands it and acts on behalf of its client.
If your website is unreadable by machines, you won’t disappear straight away. But you’ll gradually become less visible to a group of visitors who didn’t even exist three years ago.
And the best thing about it is that most of this work consists precisely of the best practice you should be following anyway. Clean markup, a clear structure, consistent presentation, no unnamed elements. None of this is new, none of it is expensive, and none of it will become worthless if the standards evolve differently than expected.
You could see this as an annoying extra requirement. I see it more as belated confirmation that doing things properly pays off in the end.
If you want to know how your website is doing in this category, you’ll find it at the bottom of every Lighthouse report. And if you’d like help sorting out what’s flagged there, just get in touch.