Lighthouse now checks if AI agents can use your site. Here is what it looks for.

Run Lighthouse in a recent Chrome and you will find a new section under the usual four: Agentic Browsing. It asks a different question from performance or SEO. Not “can a person use this page” or “can Google index it”, but “can an AI agent working in the visitor’s browser read this page, use its forms and find what the site offers”. The category is experimental, missing items are marked not applicable rather than failed, and only things done wrong cost points. For most B2B sites the useful work is small: keep the page accessible and stable, keep llms.txt valid, describe every form for agents, and publish a short catalog of what an agent can use.

What the category checks

Lighthouse scores this category as the share of applicable audits that pass. An audit that does not apply to your page, because you have no WebMCP tools yet for example, drops out of the calculation instead of pulling the number down.

The first two rows are not new work. An agent finds buttons the way a screen reader does, through the accessibility tree, so an icon-only button with no label is as invisible to it as to a blind visitor. And a layout that jumps under a click sends the agent’s click to the wrong place, the same way it does a person’s thumb. If your accessibility and Core Web Vitals are in order, most of this category already is.

llms.txt: only checked if you have one

A missing llms.txt costs nothing. A broken one does: Lighthouse wants a top-level heading, more than a line or two, and links. The file is a plain-text map of the site, the services and the pages worth reading, and I wrote about why it is cheap insurance in the article on what AI search says about your company. If yours was generated once by a plugin and never looked at again, open it: an empty template is worse than no file.

WebMCP: telling agents what your forms do

There are two ways to do it. The simple one is a few attributes on a form you already have. The form keeps working exactly as before for people; an agent that supports WebMCP reads the descriptions and knows what to put where.

<form toolname="send_message"
      tooldescription="Send a project enquiry to Andrew. A person reviews and replies within one business day.">
  <input name="email" type="email" required toolparamdescription="Work email to reply to">
  <textarea name="message" toolparamdescription="What the site is and what needs fixing"></textarea>
  <button type="submit">Send</button>
</form>

Three details decide whether it works:

• Every form on the page counts. Lighthouse lists each form that is not described, including a search box in the header or a chat input. Each needs its own name; two forms on one page cannot share one.
• Every field needs a name. A required field without a name breaks the tool’s schema.
• JavaScript forms must answer the agent. If the submit handler calls preventDefault(), as most React and Vue forms do, it has to reply through the submit event’s respondWith(). Without it Chrome hands the agent a programming error instead of a result.

Leave out the auto-submit attribute on anything that sends data, books a call or charges money. The agent fills the form, the person reads it and presses the button. That keeps consent where it belongs and keeps your bot protection meaningful.

The second way is code: small read-only tools registered from JavaScript, such as listing your services with prices or finding an article. They are worth it when there is something an agent would genuinely want to ask your site, and they should load only in browsers that support the API, so normal visitors download nothing extra.

// Only where the browser supports WebMCP; navigator is the fallback for early builds
const context = document.modelContext ?? navigator.modelContext
const controller = new AbortController()

context?.registerTool(
  {
    name: 'list_services',
    description: 'Fixed-price website services with the starting price and a link to each.',
    inputSchema: { type: 'object', properties: {} },
    annotations: { readOnlyHint: true },
    async execute() {
      const { services } = await fetch('/webmcp/catalog').then((r) => r.json())
      return { content: [{ type: 'text', text: JSON.stringify(services) }], structuredContent: { services } }
    },
  },
  { signal: controller.signal },
)

ai-catalog.json: a list of what agents can use

The newest audit validates a catalog file defined by the Agentic Resource Discovery (ARD) spec: a small JSON document that lists the resources a site offers to agents. The latest version of the spec calls it /.well-known/ard.json and links it with rel="ard"; Lighthouse 13.5 still looks for the older name, /.well-known/ai-catalog.json, and the ai-catalog relation. Serve the same file at both addresses and name both relations in one tag:

<link rel="ard ai-catalog" href="/.well-known/ard.json" type="application/json">

One more wrinkle: the spec’s list of entry types has nothing for WebMCP tools or llms.txt yet, and Lighthouse lowers the score for types outside that list. What fits today is an Agent Skill, a Markdown file that describes the site for an agent and names its tools, with llms.txt and the sitemap linked from it.

What I did on this site

Before the change, Lighthouse on andrewbarchuk.com listed four forms on the home page with no agent description, no tools, and the schema and catalog audits as not applicable. After it, all four audits pass on the home page, the contact page, the deep audit page and a service page, and the category scores 1 on each.

The tools load as a separate 9 KB file only where the browser supports WebMCP, and fetch their data from one JSON endpoint built from the same content as llms.txt, so publishing in WordPress updates both. The catalog lives at both addresses with an Agent Skill behind it. Mobile performance did not move: the home page scored 0.91 before and after, with first paint within 3 ms, as a median of three local runs.

Is it worth doing now?

In this order, cheapest and most useful first:

1. Accessibility and layout shiftThey help every visitor today and count toward this category too.
2. A valid llms.txtAn hour, and it is read by more than Lighthouse.
3. Descriptions on your formsEvery form on the page, each with a name, auto-submit off, and a reply to the agent if the form submits with JavaScript.
4. The catalog fileA few lines of JSON at two addresses and one link tag.
5. Read-only toolsOnly if there is a question an agent would really ask: prices, availability, documentation.

None of this will make an assistant recommend you on its own. What it does is remove the reasons an agent would give up on your site halfway through a task, which is a small advantage now and a larger one once these browsers are common.

The free scan on this site checks the pieces it can see from outside: whether llms.txt is valid, whether a resource catalog exists and parses, and whether your forms are described for agents correctly.