By the DenverSEO.io team · 2026-10-19
Lighthouse’s Agentic Browsing category (Chrome M150, June 2026) is an informational set of audits covering accessible names on interactive elements, layout stability, declarative forms, structured data, well-formed WebMCP tools where declared, and whether llms.txt returns a server error. On a typical small-business quote page the failures are unnamed icon buttons, unlabeled form fields and layout shift from late-loading widgets, all fixable in HTML and CSS without new technology.
What we ran it on
A Denver home-services client’s quote page on a WordPress theme: hero, three-step form, a reviews widget that loads from a third party, a chat bubble, and a sticky call button. Representative of what most local businesses run. Lighthouse 13 in Chrome 150, DevTools panel, mobile emulation, with only the Agentic Browsing category ticked. The category is informational, so there is no headline score; you read the audits one by one.
Audit by audit
1. Accessible names on interactive elements
What it checks: every button, link, input and custom control has a name in the accessibility tree. Agents navigate that tree the way screen readers do; a control with no name is a control the agent cannot describe or choose.
What failed: twelve controls. Icon-only social buttons, a “next step” arrow implemented as a div with a click handler, the chat bubble, and the carousel dots on the reviews widget.
The fix: real <button> elements with visible or aria-label text; aria-hidden on the decorative dots; the chat bubble given a label and a role. Forty minutes.
2. Layout stability
What it checks: Cumulative Layout Shift, the same metric as Core Web Vitals. An agent that computed a click target before the page moved clicks the wrong thing afterward.
What failed: CLS of 0.23. The reviews widget injected 300 pixels of height above the form after load, and a web font swapped from a narrower fallback, re-wrapping the headline.
The fix: a reserved min-height on the widget container, and a metric-matched fallback font via size-adjust so the swap does not reflow. CLS to 0.02. Our INP note covers the sibling metric.
3. Declarative forms
What it checks: inputs have associated labels, names are meaningful, required fields are marked, autocomplete tokens are present, and errors are announced.
What failed: three inputs relied on placeholder text as the only label, the phone field had name="field_7", and validation errors appeared as red borders with no text.
The fix: explicit <label for> on each input, name="phone" with autocomplete="tel", and inline error text tied with aria-describedby. The long version is in agent-ready forms.
4. Structured data
What it checks: schema.org markup an agent can use for facts without parsing prose.
What failed: only an Organization node from the theme, with no address, hours, service area or offers.
The fix: one connected @graph: LocalBusiness with address, geo, openingHoursSpecification and areaServed; a Service node per service; a FAQPage matching the visible FAQ. Generated with our schema markup validator, validated, then checked against the visible page so nothing in the markup is absent from the HTML.
5. WebMCP tools
What it checks: if the page declares tools through WebMCP (in origin trial from Chrome 149), they are well-formed with typed inputs.
What we did: nothing yet. The client cannot act on agent-originated quote requests differently from human ones, so we left this for a later phase. The audit reports no tools declared, which is fine. Declaring tools you cannot fulfil is worse than declaring none.
6. llms.txt
What it checks: only whether the file returns a server error. Chrome’s documentation calls it an “emerging convention.” A 404 is marked not applicable.
What we did: nothing. See why llms.txt does nothing for Google Search.
After
accessible-names ........ 0 unnamed controls layout-stability (CLS) .. 0.02 declarative-forms ....... all inputs labeled structured-data ......... LocalBusiness, Service x4, FAQPage webmcp-tools ............ none declared (by choice) llms-txt ................ n/a
Total time, including the schema work: about six hours. The accessibility score went from 81 to 100 as a side effect, and the page’s Core Web Vitals passed in the field three weeks later when CrUX caught up. That is the pattern we keep seeing: agent readiness is not a new discipline. It is the old disciplines, audited by a new visitor.
How to run it yourself
- Chrome 150 or later. Open DevTools (F12), choose the Lighthouse panel.
- Tick only “Agentic browsing.” Choose Mobile.
- Run it on the page where a customer would act: quote, booking, contact.
- Fix in this order: names, forms, layout shift, structured data. Leave WebMCP for when you have an action worth exposing.
- Re-run, then run the machine-readability analyzer on the same URL to check the content side.
If you want the list produced for your site, the free technical review on our agent-ready website page is this process, written up.