Google Is Now Auditing Your Site for ‘AI Readiness’: Here’s What It’s Looking For

Alex Rostovtsev is an SEO at Elfsight and an AI visibility specialist at Beamtrace. Alex combines hands-on SEO practice with original research into how AI systems evaluate and surface content. In this article, he breaks down Google’s new Agentic Browsing audit – what it checks, why it matters, and what site owners can do to prepare before it starts carrying real weight.

A few weeks ago, Google launched a new version of Lighthouse, Chrome’s auditing tool that scores webpages on performance, accessibility, and SEO. One move in the update caught our attention: Google promoted the “Agentic Browsing” category from experimental to default, meaning, the audit now checks whether a site is ready for AI agents that operate a browser on behalf of humans.

The Growing Role of AI Readiness for Websites

A year ago, Google’s John Mueller compared llms.txt to the keywords meta tag and called building a separate Markdown for bots “a stupid idea.” Now, Chrome’s new Lighthouse has an llms.txt check included in the default audit.The contradiction dissolves once you separate the two contexts: Google Search is talking about ranking, and llms.txt won’t help you rank higher or get cited in AI Overviews. Agentic Browsing audit is talking about something else entirely: the growing category of AI that doesn’t search for your site but visits it and tries to do things on it – booking a flight, filling out a form, comparing products, or completing a checkout.

For that use case, the agent needs to understand your site’s structure programmatically: it needs clean accessibility trees, stable layouts, and ideally, explicit declarations of what actions are available. That’s what the Agentic Browsing category measures.

The distinction is in the purpose: while Search decides whether agents find you, Lighthouse measures whether they can use you once they arrive.

What it Means to be AI Ready According to Google

The Agentic Browsing category runs four groups of audits, and there’s no 0-100 score we see in Performance or Accessibility. You get a fractional pass/fail ratio – how many checks your site passes out of how many were run. Chrome’s documentation says the standards are still emerging, so Google appears to be gathering data.

Here’s what each group looks for.

1. Accessibility Tree Integrity

Despite sitting in the Agentic Browsing category, this audit isn’t about AI-specific preparation.

Behind what you see, the browser builds an invisible map of the page’s elements – buttons, links, headings, form fields – labeled and structured so assistive software can navigate it. This map is called the accessibility tree, and Lighthouse checks whether yours is clean enough for both screen readers and AI agents to use. Specifically:

• Names and labels. Interactive elements (buttons, links, form fields) need a name that software can read. An unnamed <button> shows on the page, but screen readers and AI agents have no way to tell if it’s a button or what it does.
• Structure that makes sense. Page elements should nest the way they’re supposed to – list items inside lists, tabs inside tab groups, headings in a sensible hierarchy. When the structure is broken or mislabeled, screen readers and AI agents get confused about what belongs where, and the page’s hierarchy stops being readable.
• What software can read. Parts of a page can be excluded from the accessibility tree – by CSS that hides them, or by attributes set to exclude them – and when that happens, screen readers and AI agents have no way to reach them. The same goes for dynamically loaded content: if the tree isn’t updated as new content appears, software can’t tell it’s there.

AI agents have two other options for understanding a page: take screenshots and process them visually, or read through the raw HTML. Both are slower and messier than reading the accessibility tree, which is a clean, labeled version of the page that browsers build automatically – as long as the HTML supports it.

This isn’t new work. The same checks that make a site usable for people with screen readers also make it usable for AI agents. A site that meets WCAG 2.1 AA – a widely used web accessibility standard – is in good shape for this audit.

2. Layout Stability (CLS)

Cumulative Layout Shift appears in the Agentic Browsing category because agents are faster than humans.

When a person loads your page, a 200ms layout shift is a minor annoyance. When an AI agent loads your page and immediately tries to click a button, that same shift means it clicks the wrong element. The agent doesn’t have human patience or the ability to visually re-orient. It reads where elements are on the page, acts on those positions, and if the layout shifted between reading and acting, the click lands somewhere else.

Chrome’s documentation says: “An AI agent may interact with your website more quickly than a human visitor, so shifts that occur as content is loading may be more disruptive to an agent.”

If your CLS score is already good for Core Web Vitals, it’s good here too. The threshold hasn’t changed. The consequence of failing has, though: a poor CLS costs a ranking signal, and now it also keeps agents from completing their actions on the page.

3. llms.txt Presence

This audit was the most surprising of the four. Lighthouse checks whether /llms.txt exists at the domain root – the same file Google Search has said sites don’t need.

The file follows a specification created by Jeremy Howard in September 2024. It’s a Markdown document that gives AI agents a machine-readable summary of the site it’s on: what it does, what content it has, and where to find key resources. The format requires an H1 header for the site’s name, an optional blockquote summary, and H2 sections that each contain links with descriptions.

What the audit checks:

If the file is there and loads correctly: the audit passes, then looks at the file’s structure – missing H1, too-short content, no links.

If there’s no file at all: marked “not applicable.” Not a failure – the file is optional.

If the file is there but the server can’t serve it: flagged as an error. The server is misconfigured and worth fixing.

A recent SE Ranking study of 300,000 domains found 10.13% had implemented llms.txt; among Fortune 500 companies, adoption sits at 7.4%. The same study also found zero correlation between having an llms.txt file and AI citation frequency – removing the llms.txt variable from the model improved accuracy.

Chrome audits for it because llms.txt is meant for browser agents – agents that arrive at a site and need to understand its structure without crawling the whole thing. The same way robots.txt tells crawlers what to avoid, llms.txt tells agents what to prioritize.

The file won’t help rankings, but it won’t hurt them either. If browser agents become a meaningful traffic source – which Chrome appears to be working toward with Auto Browse and Gemini integration – having an llms.txt means agents can understand a site faster.

4. WebMCP Integration

This audit is about transactional functionality. If a site lets users do things – book flights, complete a checkout, fill in account details – this is where WebMCP matters.

WebMCP (Web Model Context Protocol) is a proposed browser-level standard that Chrome added in early preview earlier this year. It lets websites tell AI agents what actions they support, so agents can call those actions directly instead of trying to figure them out by looking at screenshots.

The Lighthouse audit checks:

Tool setup. Are any WebMCP tools set up on the page, through HTML or JavaScript?

Forms that should be tools. Are there forms that could be set up as WebMCP tools but aren’t?

Schema validity. For tools that are set up, do the schemas follow the spec?

There are two ways to add WebMCP tools to a site.

HTML attributes. Add a couple of tags to a form and the browser figures out the rest. Works well for any site with clean forms.

JavaScript. Write the setup in code. Needed for anything more dynamic than a static form.

For most sites, the HTML route is enough. The JavaScript route is for dev teams that need precise control over what tools look like and how they behave.

Early adopters of WebMCP have been mostly transactional sites – Expedia, Shopify, Etsy, Target, and others. These are sites where agents booking flights or completing checkouts directly benefit from having tools they can call instead of buttons they have to figure out.

WebMCP is less immediately relevant for content-only sites – blogs, publications, informational pages – where actions for agents are less common. But for sites with a search function, a contact form, a filtering system, or any interactive workflow, the HTML setup is a low-friction way to make those readable to agents.

The origin trial launches in the next Chrome release. This is pre-production. But the audit is already in the default Lighthouse config, and Chrome is building the scoring before the spec is final.

What You Can Do Now

1. Run the audit. Run Lighthouse – either inside Chrome (in the developer tools) or through a hosted tool like DebugBear’s free checker – and look at the Agentic Browsing category. Cross-site averages so far are around 17 out of 100.
2. Check the accessibility tree. Fixing problems here helps both screen readers and AI agents – the same checks serve both audiences. Common issues: buttons without readable names, broken page hierarchy, and content that’s been hidden from assistive software.
3. Get CLS under control. A CLS score below 0.1 already passes Core Web Vitals, and that same threshold applies here. A poor CLS score now affects two things – search ranking and how reliably agents can interact with the page.
4. Create an llms.txt file. Put a Markdown file at the domain root with an H1 for the site’s name, a one-line summary, and links to the main content sections. The spec is at llmstxt.org. It won’t help rankings, but it gives agents a faster way to understand the site – and Lighthouse will stop flagging the audit.
5. Look at forms for WebMCP readiness. WebMCP is still in pre-production, so implementing it isn’t urgent. The foundation matters now, though. Look at the main user actions on a site – search, contact, booking, filtering – and check that the labels are clear, that input types match what’s being collected (dates, numbers, emails), and that the HTML holds together without heavy JavaScript. Clean forms now make WebMCP easier to add later.
6. Track AI visibility alongside traditional metrics. Measuring this is hard – Google Search Console doesn’t separate out agent-driven visits from regular traffic. An ai visibility tool like Beamtrace can show how a brand appears across AI platforms. Manual quarterly checks are an option too – running queries through ChatGPT, Gemini, and Perplexity with the site’s category keywords gives a starting picture.

What’s Still Unclear

Several things about the Agentic Browsing category are open. Whether it will carry ranking weight is unknown – Chrome describes the audit as data-gathering, and the pass/fail ratio might stay informational or become part of a signal that matters. The pace of browser-agent adoption is another open question: Auto Browse is live on desktop and coming to Android in late June, but available and widely used are different things. WebMCP itself could become the standard or get superseded – it’s a proposal from Google rather than a W3C recommendation, and early adoption is encouraging but pre-production.

Against this uncertainty, Chrome added these audits to the default config rather than behind a flag, which signals direction. The accessibility and CLS improvements the audit rewards have value regardless of where browser agents go – they help screen reader users today, and if browser agents become a meaningful traffic source, the site is already set up to handle them too.