Agentic Browsing Auditing: See Your Website the Way Google’s AI Agents Do
For fifteen years we optimised websites for two audiences: humans and crawlers. Humans read, clicked, and converted. Crawlers indexed, ranked, and sent traffic. Every brief, every audit, every quarterly review came back to those two readers.
A third reader has now arrived, and it does not read the way either of the other two does. It does not skim your hero copy or weigh your backlink profile. It parses your accessibility tree, looks for a structured contract telling it what your forms actually do, and tries to click a button that it hopes has not moved since it last looked. This reader is the AI agent, and for the first time you can audit your site through its eyes.
Google shipped the tool to do it inside the browser you already have open. It is called the Agentic Browsing category, and it lives in Lighthouse, the same audit engine your web team has run for years. I want to walk you through exactly what it checks, why each check matters to your business, what we do about it for our client partners at Szymaniak Digital, and how you can act on it this quarter.
A note before we start: this category is experimental and built on proposed standards that are still moving. I will be honest throughout about which findings you can act on today and which ones to watch rather than panic over. That distinction is the whole point of this document.
Why “agentic optimisation” is now a board-level concern
Let me frame the stakes before the mechanics.
Search is no longer the only front door to your business. Increasingly, an AI agent sits between your customer and your website. The customer asks an AI assistant to “book me a table near the office for Thursday” or “renew my travel insurance for this upcoming trip, see my calendar”, “buy an educational course for my child to pass medical school exams”, or “find the cheapest flight with a checked bag,” and the agent goes off and does it – navigating sites, reading interfaces, filling forms, and completing actions on the person’s behalf.
If your site is easy for that agent to read and act on, you win the transaction. If it is not, the agent moves to a competitor whose site it can operate, and you never see the customer at all. There is no second page of results to climb back from. The agent simply succeeds somewhere else.
This is the discipline now being called agentic optimisation – or, depending on who you ask, Generative Engine Optimisation (GEO), Answer Engine Optimisation (AEO), LLM Optimisation (LLMO), or AI Search Experience Optimisation (ASXO). The names vary; the underlying shift does not. Your website is becoming an interface that machines operate, not just a document that machines read. Optimising for that is no longer speculative. Google has now put a measurement tool for it inside Chrome.
The reassuring part, which I will keep returning to, is that most of what makes a site good for agents also makes it good for humans. You are not building a parallel website. You are finishing the one you already have.
How to run the Agentic Browsing audit in four steps
Note: This takes a few minutes and your developers can do it on a coffee break. They just need to listen to their SEO Consultant 😉
1. Update Chrome. You need Chrome 146 or newer. The Agentic Browsing category is experimental, so if your stable channel has not received it yet, install the Beta or Canary channel to get a recent enough build.
2. Enable the flag. Go to chrome://flags/#enable-webmcp-testing, set it to Enabled, and relaunch Chrome. This is the experiment mode that switches on the WebMCP testing interfaces — without it, the WebMCP portions of the audit have nothing to measure. For your technical SEOs and developers, this step is mandatory, not optional. You will see the flag listed as “WebMCP for testing,” available across Mac, Windows, Linux, ChromeOS, and Android.
3. Run Lighthouse. Open DevTools, go to the Lighthouse tab, tick the Agentic Browsing category, and click Analys.
4. Read the report and fix. You will not get a familiar 0–100 score here. You get pass and fail signals per audit, plus a fractional ratio. Read it for direction, not for a grade.
That last point matters enough to spend the rest of this document on.
How the category is scored (and why it isn’t scored like the others)
Every other Lighthouse category — Performance, Accessibility, Best Practices, SEO — hands you a weighted number out of 100. Agentic Browsing deliberately does not. Because the standards for the agentic web are still emerging, Google’s stated goal right now is to gather data and give you actionable signals rather than crown your site with a definitive ranking.
So instead of a score, the report shows you three things. First, a fractional score — a ratio of how many agentic-readiness checks your site passes, displayed as something like “3/3” in the category header so you can read your progress at a glance. Second, pass or fail status on specific audits, which may surface errors or warnings when a technical requirement (such as WebMCP schema validity) is not met. Third, informational counts that simply tell you what exists on the page without grading it.
There is one behaviour you should brief your team on so nobody panics: results can fluctuate between runs, even though the audits themselves are deterministic. There are three common reasons. Tools registered dynamically through JavaScript may or may not be captured depending on the timing of the Lighthouse snapshot. Significant changes to the size or complexity of your DOM alter the accessibility tree, which is the agent’s core data model. And layout shifts caused by ads, undimensioned images, or injected content can move an element between the moment an agent identifies it and the moment it tries to click. If your numbers wobble, that wobble is itself a signal — usually about stability or timing.
Underneath, Lighthouse uses deterministic checks so the audit is reproducible and safe to wire into a CI/CD pipeline. That is the strategic prize: agentic readiness becomes something you regression-test on every deploy, not something you eyeball once a year.
The checks fall into four groups: WebMCP integration, agent-centric accessibility, layout stability, and discoverability. Let me take each in turn.
WebMCP: telling agents what your site can actually do
This is the genuinely new idea, so it deserves the most attention — and the most patience.
WebMCP (Web Model Context Protocol) is an emerging W3C standard, developed jointly by Google and Microsoft, that lets a website expose structured “tools” to AI agents directly in the browser. Instead of an agent guessing how your booking form works by scraping the DOM or reading a screenshot, you hand it an explicit contract: here are my available actions, here is what each one does, here is what it needs from you. Think of it as a menu of capabilities — “Book a Table,” “Add to Cart,” “Renew Policy” — written in a language the agent reads natively.
It is worth knowing how this differs from Anthropic’s MCP, because the names cause confusion. Anthropic’s MCP is a backend, server-to-server protocol connecting AI tools to APIs and databases. Google’s WebMCP is a frontend, browser-side protocol connecting agents to your website’s interface. They are complementary, not competing — a mature stack may well use both.
Lighthouse evaluates WebMCP through three distinct audits.
Registered WebMCP tools (informational)
This audit simply lists every WebMCP tool registered on the page, whether you declared it in HTML or registered it in JavaScript. If you have registered none, the list comes back empty — which is where almost every site sits today.
You register tools two ways. The declarative approach adds toolname and tooldescription attributes straight onto your <form> elements. The imperative approach uses JavaScript — navigator.modelContext.registerTool — for more dynamic cases. Best practice is to name tools with clear, action-oriented verbs (book_appointment, not form_3) and to write descriptions that genuinely explain what the tool does and when an agent should reach for it. The description is not decoration; it is how the agent decides whether your tool is the right one for the user’s request.
Forms missing declarative WebMCP (informational)
Here Lighthouse flags <form> elements that lack both a toolname and a tooldescription. Agents can often infer how a form works, but inference is fragile; declaring it explicitly makes the interaction reliable. For now this audit is purely informational and raises no warnings — it is showing you the gap, not penalising you for it.
The fix is small and human-readable. A newsletter form, for example, gains a toolname such as newsletter_signup, a tooldescription explaining that it subscribes the user to your weekly email, and a toolparamdescription on the email input clarifying what value belongs there. A handful of attributes turns an opaque form into an action an agent can call with confidence.
WebMCP schema validity (can fail)
This is the one audit in the WebMCP set that actually fails rather than merely informs, so brief your developers on its rules. It fails when a form declares a tooldescription but no toolname, or a toolname but no tooldescription, or when a required field is missing its name attribute. It also issues a warning when an optional field has a name but lacks either a toolparamdescription or an associated <label>.
The remedies are disciplined and simple: keep your tools symmetrical (always pair a name with a description), give every input a unique name, and add toolparamdescription to inputs so the agent understands what each value is for.
The honest caveat on WebMCP
Now the part I promised to be straight about. WebMCP is in early preview and the specification is still moving. Realistically, the WebMCP audit will report empty or incomplete on almost every website today, because almost nobody has implemented it yet and production readiness is expected later in 2026. A low or blank WebMCP result right now is expected and should not trigger an emergency. Do not let a vendor or an internal stakeholder scare you with it.
What it should do is two things. First, put WebMCP on your roadmap as a deliberate, early-adopter move rather than a fire drill. The forms you would expose — signup, booking, search, checkout — are often only a few HTML attributes away from being agent-ready, and being early on a standard your competitors have not touched is a real moat. Second, frame it correctly to leadership: this is where the web is going, you are getting ahead of it on purpose, and the cost of preparation is low.
Accessibility for agents: the machine-eye view of your page
This is where the experimental novelty ends and the immediately actionable work begins — so this is where we point most client teams first.
Agents read your page through the accessibility tree — the same structured representation that screen readers use to describe your interface to people with visual disabilities. It is, in effect, the machine-eye view of your site. When a button has no programmatic name, a sighted human might still guess its purpose from an icon, but a blind user and an AI agent are equally stranded. They cannot complete the task.
Lighthouse filters a specific subset of accessibility checks that matter most for machine interaction: that every interactive element has a programmatic name or label; that roles and parent-child relationships in the tree are valid; and that content which is interactive is not accidentally hidden from the accessibility tree. The fixes are the fundamentals you already know — semantic HTML and proper ARIA labelling — applied rigorously.
Here is the argument I make to any sceptical executive: this work pays twice. Every label you add for an agent is a label you added for a customer using assistive technology. Every valid role improves both your agent-readiness and your compliance posture. There is no trade-off and no parallel build. You are doing accessibility work you should arguably have done already, and getting agentic readiness as a bonus. Of everything in this audit, this is the highest-return, lowest-risk place to start.
Layout stability: can the agent click the button it found?
Agents frequently interact with pages by coordinate — they locate a button, then click where they believe it sits, sometimes guided by a screenshot. If your layout shifts between identifying the element and acting on it, the agent clicks empty space, or worse, the wrong control. The interaction fails silently.
Lighthouse measures this with Cumulative Layout Shift (CLS), the same Core Web Vital your performance team already tracks. The usual culprits apply: images without declared dimensions, ads and embeds that push content down, and late-injected DOM elements. The remedies are the same ones that already improve human experience and SEO — reserve space for media, size your assets, and stop content jumping around after load.
Like the accessibility work, CLS is fixable today and helps all three audiences at once. A stable layout is better for the customer who hates the page jumping as they reach to tap, better for your Core Web Vitals, and now better for the agent trying to act on the page.
Discoverability: llms.txt
The final group is about helping agents understand your site before they even crawl it. The mechanism is llms.txt, an emerging convention — a machine-readable Markdown summary you place at your domain root (for example, https://example.com/llms.txt) that gives agents a concise overview of your site’s purpose and key links. Without it, an agent may spend extra effort crawling around just to work out what your site is and where the important pages live.
The audit behaviour is gentle. Lighthouse flags the page if the server throws an error when trying to fetch the file. If the file simply does not exist and returns a 404, the audit is marked Not Applicable rather than failed — because providing it is optional for now. The fix is to author a short Markdown summary following the llms.txt specification and serve it from your root.
My practical advice: this is a low-effort, low-risk thing to ship. It will not transform your business overnight, but a clear llms.txt is cheap insurance that agents form an accurate first impression of who you are.
How we run an Agentic Browsing audit at Szymaniak Digital – a worked example
Theory is one thing; let me show you what this looks like in practice. The following is a representative engagement based on how we run these audits for our client partners. Identifying details are anonymised and the figures are illustrative of the pattern we see, not a single specific account – but the workflow and the kinds of findings are exactly what we deliver.
The client partner. A mid-market hospitality booking brand, “the client” – running a React-based site whose core conversion event is a “reserve a table” form, plus newsletter signup and a search/availability tool. They came to us worried they were “invisible to AI,” without a clear way to measure it. That phrase is exactly why this audit exists: it turns a vague fear into a checklist.
Here is the five-stage process we run.
Stage 1 — Baseline in Lighthouse (the source of truth). We start in the browser, not in a third-party dashboard, because the official Google signal is what we anchor every recommendation to. We update to Chrome 146+, enable chrome://flags/#enable-webmcp-testing, and run the Agentic Browsing category across a representative set of templates: the homepage, the booking page, a content/article page, and the contact page. We capture the fractional score and every pass, fail, warning, and N/A. For this client, the headline read like most sites do today — strong on the human-facing Lighthouse categories (Performance, Accessibility, Best Practices, SEO all high), and a near-empty WebMCP picture. That is the normal starting line in 2026, and we say so plainly so nobody panics at stage one.
Stage 2 — Triage into “fix now” versus “roadmap.” We sort every finding into the priority order I will lay out in the next section. For this client that meant: accessibility-tree gaps and CLS issues went into “fix now”; llms.txt went into “quick win”; and WebMCP went onto a deliberate roadmap rather than an emergency list. This triage is the single most valuable thing we do, because it stops teams burning a sprint chasing an experimental standard while ignoring the items that move the needle today.
Stage 3 — Deepen and benchmark with our specialist tooling. Lighthouse tells us what failed on the pages we tested; our specialist tools tell us how widespread it is and how the client compares to competitors. We run Glippy across the site to score all sixteen GEO categories and 240-plus checks per template, and to read its Agent Interactivity (WebMCP) category — which surfaces exactly how close the existing forms already are to being agent-ready. We pull the client’s competitors through the same checks for a side-by-side, and we use Agent Checker as a second, usability-focused lens to validate how operable the site genuinely is for an automated browser. The pattern we almost always find: the client’s booking and newsletter forms are only a handful of HTML attributes away from WebMCP compatibility, and a competitor or two is no further ahead — which reframes the whole thing from “we’re behind” to “there’s an open lane here.”
Stage 4 — Remediate, starting where value is highest. We action the “fix now” list first. On the accessibility tree, that meant giving every interactive control a programmatic name, correcting a couple of invalid roles, and un-hiding an interactive element that had been removed from the tree. On stability, we reserved space for the late-loading availability widget and dimensioned the gallery images so the booking button stopped shifting on load. We shipped a concise llms.txt at the root. Then, as the planned roadmap item, we added declarative WebMCP attributes to the three highest-value forms — toolname, tooldescription, and toolparamdescription on inputs — keeping every tool symmetrical and every input properly named so the schema-validity audit passes rather than fails.
Stage 5 — Re-test, wire into CI, and report. We re-run the Lighthouse Agentic Browsing category to confirm the fixes register, then wire the deterministic checks into the client’s CI/CD pipeline so agentic readiness is regression-tested on every deploy — not re-discovered next year. The client deliverable is a short board-ready report: the before/after Lighthouse signals, the Glippy category scores against competitors, the prioritised list of what we fixed and why, and the WebMCP roadmap framed as an early-adopter advantage with a low cost of preparation.
The outcome we aim for, and typically reach: the “fix now” items — accessibility and stability — close out within the first sprint and improve the experience for human customers, assistive-technology users, and agents simultaneously; llms.txt ships the same week; and the client moves from “empty” on WebMCP to having their core conversion actions declared before their competitors have started. The win is not a vanity number. It is that when an agent is sent to “book a table,” the client’s site is one it can actually operate.
PS: If you would like to see this run live against your own domain, that is exactly the kind of session we open a client engagement with.
A simple priority order for your team
If you take one operational thing from this document, take this sequence. The audit checks four areas, but they are not equally urgent or equally actionable.
Start with accessibility for agents and layout stability. Both are fixable today, both help humans and agents simultaneously, and both improve metrics you already report on. This is where your effort converts to value fastest.
Add llms.txt next, because it is quick and harmless.
Treat WebMCP as a deliberate roadmap item, not an emergency. Enable the testing flag, run the audit to see where your forms stand, identify the handful of high-value actions worth exposing first, and plan the work as an early-adopter advantage. Do not let a blank WebMCP result this quarter rattle anyone.
The tools we use internally at Szymaniak Digital
Lighthouse gives you the official, in-browser ground truth, and it should be your reference point. Alongside it, my consulting team uses two specialist tools to scale this work across clients and to go deeper than the four core Lighthouse checks.
Glippy is a GEO agent-readiness checker. It scores any page across sixteen optimisation categories and more than 240 individual checks, giving you a 0–100 score and a letter grade per page. Crucially for this conversation, its Agent Interactivity category checks for the exact WebMCP signals Lighthouse looks at — declarative attributes like toolname, tooldescription, and toolparamdescription, imperative API usage, SDK and polyfill detection, and how close your existing forms already are to being agent-ready. It deliberately keeps WebMCP at a low weight today, which reflects the same honest reality I have stressed: the standard is early, so it should not tank your score yet. Its MCP server is the part my team leans on most — it pipes all those checks straight into our AI workflow (Claude, Cursor, VS Code and similar), lets us compare a client against competitors side by side, and exports reports for the deck.
Agent Checker – we use it for audits on larger websites, specifically for agent usability. We use it as a second, agent-focused lens alongside Lighthouse and Glippy — a useful cross-check when we want to validate how operable a site really is for automated browsing rather than relying on a single tool’s verdict.
A word on how to read these: Lighthouse is the official Google signal and your anchor. Glippy and Agent Checker extend the picture — more categories, competitor benchmarking, workflow integration, and a usability-focused second opinion. Use the specialist tools to prioritise and to brief, but treat the in-browser Lighthouse result as the source of truth.
The bottom line for decision-makers
The agentic web is not a forecast you can defer to next year’s planning cycle. It is sitting in your developers’ DevTools right now, and the measurement tool came from Google itself.
Here is the honest, two-part takeaway. The new and headline-grabbing piece — WebMCP — is genuinely early. Expect it to read empty today, plan for it deliberately, and treat being early as the advantage it is. But the unglamorous pieces — a sound accessibility tree and a stable layout — are fixable this quarter, and every hour spent on them improves your site for customers, for assistive-technology users, for search, and for agents at the same time. That is as close to a free lunch as our discipline ever offers.
The question I would put to your team this week is the same one I keep asking friends in the industry: have you run the Agentic Browsing audit yet?
