Google shipped Lighthouse v13.5.0 this week, and buried inside a routine changelog is the closest thing to an official AEO readiness checklist the industry has seen. The release expands Chrome’s Agentic Browsing audit category with a new Agent Resource Discovery (ARD) schema check and tightens two existing WebMCP audits. It is set to land in the DevTools of Chrome 156 and reach PageSpeed Insights within two weeks.
None of this is speculative tooling from a third-party SEO vendor. It is Google auditing, inside the same tool that already scores performance, accessibility, and Core Web Vitals, whether a website can be discovered and used by an AI agent at all. Lighthouse has quietly become the place where “is this site agent-ready” gets a pass or fail grade, and most sites have never been checked against it.
Want to know whether your website has AI-readiness compatibility or not?
Book a meeting with us.
What Agentic Browsing already checked
Chrome’s Agentic Browsing category dates back to Lighthouse 13.3, when Google first added an llms.txt audit alongside three others: WebMCP integration, agent accessibility, and layout stability. The llms.txt check is lenient by design. If the file returns a 404, the audit is marked not applicable, since publishing an llms.txt file remains optional. If the file exists but the server throws an error retrieving it, or the file does not follow the emerging format conventions, the audit flags it.
WebMCP is the newer and more consequential piece. It centers on the document.modelContext API, which lets a page register callable tools for an AI agent directly — not just descriptive text for a model to read, but actions an agent can invoke, such as filling a search form or completing a checkout step. Sites declare these tools either through HTML attributes on form elements or through JavaScript calls to document.modelContext.registerTool.
What v13.5.0 adds
Three changes in this release move the category from experimental to something closer to enforceable.
The new ard-schema audit validates a site’s Agent Resource Discovery file, expected at a .well-known/ai-catalog path, against a formal schema. Where llms.txt is a freeform markdown convention with no strict structure, ARD is structured and machine-validated from the start. The release groups llms.txt and ARD audits together under a shared agent discovery configuration, which signals Google is treating them as two entry points into the same discovery layer rather than as competing standards.
The two WebMCP audits also matured. webmcp-form-coverage now passes outright when every form on a page is covered by a registered tool, instead of returning a not-applicable result. webmcp-registered-tools now warns when a page registers more tools than Google’s recommended limit, which suggests a ceiling is forming on how much surface area a single page should expose to an agent at once.
Of the three WebMCP checks, only webmcp-schema-validity can fail a page outright, and it fails on asymmetric tool attributes, input parameters missing a name, or a missing toolparamdescription. The other two remain informational: they report what exists without penalizing a page for having none.
The checklist hiding inside the changelog
Put together, these four audits describe a specific, testable definition of agent readiness rather than a vague aspiration toward it. A site can now be checked against:
- Does an llms.txt file exist, resolve without a server error, and follow the current format conventions?
- Does a .well-known/ai-catalog file exist and validate against the ARD schema?
- Are the page’s forms covered by registered WebMCP tools, declaratively or imperatively?
- Do those registered tools use valid, symmetric schema attributes, with named inputs and parameter descriptions?
- Does the page stay usable and stable when an agent interacts with it, per the layout stability check already in the category?
That is a checklist an AEO agency or an in-house team can run today, in the same Lighthouse panel already open in Chrome DevTools, without adopting a new toolchain. It costs nothing to check and, other than the schema-validity audit, nothing currently fails a site for non-compliance. That combination of low cost and zero penalty is exactly the window in which most sites will ignore it.
Whether agentic browsing will require compliance
The honest answer is that none of this is mandatory yet, and Google has kept the llms.txt and WebMCP checks informational specifically because the underlying standards are still moving. document.modelContext itself replaced navigator.modelContext earlier in its rollout, and Chrome has already deprecated the old namespace while an origin trial still serves it. A spec that renames its core API mid-rollout is not one Google is ready to enforce against.
But the direction is not ambiguous. Lighthouse audits do not stay informational forever. Accessibility and Core Web Vitals both entered Lighthouse as descriptive scores before becoming ranking and UX signals that agencies now treat as baseline requirements. Agentic Browsing is following the same path, just earlier in the cycle. The moment AI agents handle a meaningful share of commercial browsing — comparing vendors, filling forms, completing purchases without a human reading the page — a site with no registered tools and no discovery file is not poorly optimized for that traffic. It is invisible to it, in the same way a site with no HTML content is invisible to a crawler.
The likely impact on AI visibility
Today’s AEO and GEO work is almost entirely about being described accurately and cited generously inside a generated answer: entity clarity, structured content, third-party validation, citation-worthy claims. Agentic Browsing readiness is a different layer sitting underneath that work. It does not compete with citation-focused AEO; it determines whether an agent can act on a site at all once it has decided to.
A site can be extremely well cited by ChatGPT or Perplexity and still fail every Agentic Browsing audit, because citation and action are separate problems. As agent-mediated browsing grows, the sites that show up in an answer but cannot be acted on by the agent reading that answer will start losing ground to sites that can. That is a plausible mechanism for a second visibility gap opening up alongside the one AEO already addresses, not a certainty, but a direction worth tracking given how fast the underlying spec is moving.
What to do now
Run a current Lighthouse audit and read the Agentic Browsing section specifically, not just the performance score most teams default to. Publish or fix an llms.txt file if one does not already resolve cleanly. Evaluate whether a .well-known/ai-catalog file is worth publishing ahead of ARD becoming a scored audit rather than a validation check. Where a site has forms that represent a real action — a quote request, a booking, a signup — look at whether registering that form as a WebMCP tool is feasible with the current declarative attributes, since that is the lowest-effort entry point into the standard.
None of this replaces the citation and entity work that drives AI visibility today. It sits next to it, and it is the part of AI visibility that a Lighthouse audit can already measure in a way that citation share cannot. Given how quickly Google moved this category from zero audits to five in two release cycles, treating it as optional for much longer looks like a short window rather than a long one.
