DEV Community: Robert

Your site just failed Lighthouse's new Agentic Browsing audit — here's how to fix each check

Robert — Fri, 19 Jun 2026 01:04:45 +0000

If you've opened Chrome DevTools lately and run Lighthouse, you may have noticed a new category sitting under Performance, Accessibility, SEO and the rest: Agentic Browsing.

It shipped in Lighthouse 13.3 (May 2026). It's still marked experimental, so it doesn't give you a 0–100 score — just a pass/fail per check. But "experimental" in Lighthouse has a way of becoming "default, and now your client is asking why it's red." So it's worth understanding now, while it's cheap.

The category answers one question: can an AI agent actually understand and operate this page? It does that with four checks. Here's what each one tests and exactly how to make it pass.

1. llms.txt

What it checks: whether your domain root serves an /llms.txt, and — this is the part people miss — whether that file is actually useful: it flags the file if it's missing an H1, is too short, or contains no links.

How to pass: add a plain-text (well, Markdown) file at https://yourdomain.com/llms.txt. Minimum viable version:

# Acme Tools

> Acme sells precision hand tools. This file helps AI agents find the right pages.

## Core pages
- [Product catalog](https://acme.example/products): browse and filter all tools
- [Search](https://acme.example/search): full-text product search
- [Support](https://acme.example/support): returns, warranty, contact

One H1, a one-line summary, real links to the pages that matter. That's the whole check. Don't dump your sitemap into it — curate the handful of entry points an agent should know about.

2. Accessibility tree

What it checks: every interactive element has a programmatic name, roles and parent/child relationships are valid, and nothing is hidden from the a11y tree while still being interactive.

How to pass: this is just accessibility hygiene, and it's the most important check of the four — because the accessibility tree is the primary way an agent reads your page. Use real <button>, <a>, <label>/<input> pairs instead of click-handlered <div>s. Give icon-only buttons an aria-label. Make sure a <div role="button"> you couldn't avoid is focusable and named.

If you've been putting off your a11y backlog, the agentic era just gave you a second, harder-to-ignore reason to do it: the same fixes that help screen-reader users help every agent that visits.

3. Cumulative Layout Shift (CLS)

What it checks: the same CLS you already know from Core Web Vitals.

How to pass: nothing agent-specific here — reserve space for images and embeds (width/height or aspect-ratio), avoid injecting content above existing content, preload fonts. Why does an agentic category care about visual stability? Because agents that drive a real browser click coordinates and read snapshots; a page that reflows under them mis-clicks exactly like a human would. Stable layout = reliable automation.

4. WebMCP

This is the new one, and the only check that's genuinely about the agentic web rather than hygiene you should already be doing.

What it checks: Lighthouse surfaces every WebMCP tool registered on the page — whether via the declarative HTML API or imperatively through navigator.modelContext.registerTool() — and validates that any declared inputSchema is syntactically and semantically valid. For annotated forms, it checks that the annotations match the expected schema.

How to pass: you need to actually expose tools, and their schemas have to be valid. The imperative version:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "search_products",
    description: "Search the product catalog",
    inputSchema: {
      type: "object",
      properties: {
        query: { type: "string" },
        maxPrice: { type: "number" },
      },
      required: ["query"],
    },
    // call the SAME function your search box already calls
    async execute({ query, maxPrice }) {
      const results = await productSearch({ query, maxPrice });
      return { content: [{ type: "text", text: formatResults(results) }] };
    },
  });
}

Two things worth saying out loud, because they're where teams get this wrong:

Feature-detect. Most browsers don't ship navigator.modelContext yet (it's in a Chrome 149 origin trial; WebKit has formally opposed it). The if ("modelContext" in navigator) guard means you lose nothing if the spec stalls — it's progressive enhancement.
Reuse your existing handlers. Your search_products tool should bottom out in the exact function your search UI already calls. If a tool does something your UI can't, you've created a second source of truth that will drift — which is precisely the redundancy critique WebKit raised. Keep tools as thin, typed front doors to behavior you already ship.

The honest prioritization

Three of these four checks — llms.txt, accessibility, CLS — are things you should be doing regardless of whether you believe in the agentic web. Do them first; they pay off for users and search today.

The fourth, WebMCP, is the real bet on where browsing is going. It's also the one with the most leverage if you sell anything: the gap between "an agent can read my page" and "an agent can complete a purchase on my page" is exactly the gap WebMCP tools fill.

Disclosure: I work on Latch, an open-source (MIT) one-line script that does the WebMCP check (#4) for you — it exposes your site's existing search/cart/forms as WebMCP tools with valid schemas, feature-detected, reusing your own handlers. If you'd rather understand the standard than adopt any tool, the WebMCP guide is vendor-neutral. Happy to talk trade-offs in the comments.

WebKit opposes WebMCP. Here's what to actually build today

Robert — Thu, 18 Jun 2026 01:05:42 +0000

If you've been following the agentic-web standards fight, you've seen the headlines: Chrome shipped a WebMCP origin trial in Chrome 149, and WebKit's standards-positions tracker landed on a one-word verdict — oppose.

It's tempting to read that as "Apple says no, so wait." That's the wrong takeaway. The opposition is mostly good engineering feedback, and once you internalize it, it tells you exactly how to build for agents today — in a way that's safe even if the spec stalls.

What WebKit actually objected to

WebKit's position cites the usual list — API design, duplication of existing platform functionality, i18n, portability, privacy, security, unclear use cases. Boilerplate-sounding, but one of those is the load-bearing critique, and it shows up most sharply in the WebMCP repo itself: redundancy with the accessibility tree.

The argument is clean:

The accessibility tree already exposes a machine-readable action space — labels, roles, states, expected inputs, validation errors, relationships. It's derived from the DOM, so it can't desync. A separately-maintained JavaScript tool registry can and will diverge from the page over time.

This is correct. If you hand-write a parallel description of your UI for agents, you've created a second source of truth, and second sources of truth rot. That's a real smell, and "agent-only APIs that don't help humans" is a legitimate thing to be suspicious of.

Why the accessibility tree alone isn't enough either

Here's the part the opposition under-weights. The a11y tree is excellent at describing state — what's on the page, what each control is, what's required. It's much weaker at describing actions, especially compound ones.

Consider "filter products under €50, in stock, then add the top result to the cart." For a human with a screen reader that's a sequence of discrete control interactions. For an agent, inferring that whole flow from roles and labels is brittle — it has to reverse-engineer your app's intent from primitives. A tool with a typed input schema ({ maxPrice, inStock }) and a single handler collapses that guesswork into one verified call.

So both things are true at once:

A parallel, hand-maintained agent API is a liability.
The a11y tree is lossy for multi-step actions.

The resolution isn't "pick a side." It's how you implement the tools.

The design that survives the critique

The redundancy objection only bites if your tool definitions are a second implementation. So don't make them one.

The right posture, in order:

Build for humans first. Semantic HTML, real form elements, a clean accessibility tree. This is non-negotiable and it's what everyone — users, assistive tech, search, and agents — benefits from.
Expose the actions, not a new app. Where you register an agent tool, have its handler call the exact same function your UI already calls. Your "Add to cart" button and your add_to_cart tool should bottom out in one code path.
Keep tools thin. A tool is a typed entry point to existing behavior, not a place for new business logic. If a tool does something your UI can't, that's the divergence WebKit warned about — fix the UI instead.

Do this and the "two sources of truth" problem evaporates, because there's still only one. The tool registry isn't a parallel description of the page; it's a typed front door to the handlers the page already runs. They can't desync because they're the same code.

Concretely

The imperative API is just a typed wrapper over a function you already have:

navigator.modelContext.registerTool({
  name: "add_to_cart",
  description: "Add a product to the cart by id and quantity",
  inputSchema: {
    type: "object",
    properties: {
      productId: { type: "string" },
      quantity: { type: "number", default: 1 },
    },
    required: ["productId"],
  },
  // same handler your "Add to cart" button calls — no second implementation
  async execute({ productId, quantity = 1 }) {
    await cart.add(productId, quantity);
    return { content: [{ type: "text", text: `Added ${quantity} x ${productId}` }] };
  },
});

And feature-detect, because most browsers won't have it yet:

if ("modelContext" in navigator) {
  // register tools
}

That if is the whole risk profile. If WebMCP ships everywhere, you're ready. If WebKit holds the line and it stalls, you've lost nothing — you added a feature-detected enhancement over handlers that already existed for your human users. This is just progressive enhancement.

Where this leaves you

The agentic-web tooling has already moved past "is this real" — Google's Lighthouse now ships an Agentic Browsing audit category, and scanners will increasingly grade whether your site exposes tools. The standards politics will take a year to settle. Your move in the meantime isn't to bet the company on a spec; it's to keep one source of truth and put a typed, feature-detected front door on the handlers you already ship.

Disclosure: I work on Latch, an open-source (MIT) one-line script that exposes a site's existing search/cart/forms as WebMCP tools — built around exactly this "reuse your existing handlers, feature-detect, lose nothing if the spec stalls" posture. If you'd rather understand the standard than adopt any tool, the WebMCP guide is vendor-neutral. Happy to talk design trade-offs in the comments.

Make any website agent-ready in one line (WebMCP, navigator.modelContext)

Robert — Wed, 17 Jun 2026 01:04:56 +0000

In mid-2026 a quiet fact about the "agentic web" still holds: none of the big agents call navigator.modelContext tools directly in production yet. ChatGPT Agent, Gemini, Perplexity, Claude — they still mostly DOM-scrape or take screenshots and guess where to click. That's slow, brittle, and burns tokens.

WebMCP fixes the mechanism. Your site declares tools — searchProducts, addToCart, submitLead — each with a name, a JSON schema, and an execute callback. An agent makes one structured call and gets JSON back, instead of clicking through your filter dropdowns. Chrome shipped the early preview in 146 (Feb 2026); Edge 147 ships it natively; Chrome 149 is now in an open origin trial (announced at Google I/O, May 2026), with DevTools support for inspecting registered tools. Benchmarks from Chrome Labs show large token reductions vs. screenshot automation.

The catch: wiring navigator.modelContext.registerTool() for every search box, cart action, and form on a real site — with auth, schemas, and a polyfill so it works in browsers that don't have it yet — is real work.

The one-line version

Latch is an open-source (MIT) script that does the wiring for you:

<script src="https://latch.tools/latch.js" data-key="YOUR_KEY"></script>

It introspects your search, cart, and forms and registers them as WebMCP tools, with a polyfill so today's agent browsers and extensions can call them now. You keep your existing UI; agents get a structured contract.

Why bother before agents "officially" support it

Two reasons. First, agent browsers and extensions that do read navigator.modelContext already exist, and the standard is landing in stable Chrome/Edge fast — being early is cheap insurance. Second, you can't improve what you can't see: when an agent does hit your site, you want to know which one, and what it tried to do. Latch's optional hosted analytics (Latch Pro, EUR 19/mo per project) shows per-agent breakdowns and a full event feed; the OSS client is free.

Try it

Guide: https://latch.tools/webmcp
Source: https://github.com/r0bertini/latch
Check your own site's agent-readiness, add a couple of tools, and watch what the agents do.

The web spent 30 years optimizing for human clicks and search crawlers. The next layer is tools for agents — and it's a one-liner to get on it.

Disclosure: I work on Latch. WebMCP itself is an open W3C Community Group standard — you can implement navigator.modelContext by hand without any library; Latch just automates the wiring.