Google tells developers to build websites for AI agents
Summary
Google published an official web.dev guide on building for AI agents. Agents read your site three ways: screenshots, raw HTML, and the accessibility tree.
If you already pass WCAG accessibility audits, you're mostly covered. If your site relies on styled divs instead of semantic HTML, agents can't use it.
Google also linked to WebMCP, an early-stage standard for letting sites register tools that agents can call directly.
What happened
Google’s web.dev site published a new guide titled “Build agent-friendly websites,” telling developers that their sites now have “a new type of visitor.” The guide frames AI agents as a distinct audience alongside human users and recommends specific development practices to support them.
The core argument: sites built with complex hover states, shifting layouts, and fluid motion are “functionally broken for agents.” Search Engine Journal’s coverage notes that most of the guidance maps directly to existing accessibility and semantic HTML practices.
Google describes three ways agents interpret websites:
- Screenshots: Agents take a page snapshot and use vision models to identify elements visually.
- Raw HTML: Agents read DOM structure and hierarchy directly.
- Accessibility tree: Google calls this a “high-fidelity map” of interactive elements, stripped of visual noise.
The specific recommendations include using semantic HTML elements like <button> and <a> instead of styled <div> elements, keeping layouts stable across pages, linking <label> tags to inputs with the for attribute, and setting cursor: pointer on clickable elements.
Google closes with a pointed summary: “Everything we suggest to make a site ‘agent-ready’ also makes sites better for humans.”
At the bottom of the guide, Google links to WebMCP, a proposed web standard for agent-website interaction. WebMCP would let websites register tools with defined input/output schemas that agents can discover and call as functions. Chrome’s team describes it as an early preview program and is accepting developer sign-ups.
Why it matters
Semantic HTML, stable layouts, and proper accessibility markup have been web development defaults for years. The practices Google recommends are not new. What changed is the messenger and the framing.
Publishing this on web.dev puts agent-friendliness alongside established developer guidance areas like accessibility and performance. Google is signaling that agent interaction is now part of its official web platform priorities.
For sites already following accessibility best practices, there is likely little to change. The practical gap is for sites that rely heavily on JavaScript-rendered UI components, custom <div>-based controls, and layouts that shift between states. Those patterns already hurt accessibility scores. Now they also break agent workflows.
The business case for semantic HTML now extends beyond screen readers. AI agents that browse, compare, and transact on behalf of users need the same structural clarity that assistive technology does. Sites selling products or services through multi-step flows should pay particular attention. An agent that cannot reliably identify form fields or buttons cannot complete a purchase.
WebMCP is worth watching separately. If adopted, it would give sites a way to expose structured capabilities directly to agents, rather than relying on agents to parse page structure. Chrome is listed for Google I/O on May 19–20, which may bring more details on browser-based agent interactions.
What to do
Audit your HTML semantics. Check whether interactive elements use native HTML (<button>, <a>, <input>) rather than styled <div> or <span> elements with click handlers. Browser DevTools’ accessibility inspector can flag these quickly.
Check layout stability. Pages with high CLS scores are already a Core Web Vitals problem. They are now also an agent problem. Ensure layouts do not shift between interaction states.
Verify label associations. Every form input should have a <label> element linked via the for attribute. Run an accessibility audit in Lighthouse to catch missing associations.
Review your accessibility tree. Open Chrome DevTools, navigate to the Accessibility panel, and check how your key pages look in the accessibility tree view. If interactive elements are missing or mislabeled, agents will struggle with them too.
Consider the WebMCP early preview. If your site offers transactional functionality that agents might use (bookings, purchases, comparisons), signing up for the WebMCP preview could give you early input into the standard. The sign-up is linked from Google’s web.dev guide.
No urgent changes are needed for sites that already pass WCAG audits and use semantic markup. The guide confirms existing best practices rather than introducing new requirements.
Watch out for
Custom component libraries that swallow semantics. Many React, Vue, and Angular component libraries render interactive elements as nested <div> structures. Even if your source code looks clean, the rendered DOM may not expose proper semantics to the accessibility tree. Inspect the rendered output, not just the source.
Cursor styling as a signal. Google specifically recommends cursor: pointer on clickable elements. Some CSS resets or design systems strip this style. Agents using screenshot-based interpretation may rely on visual cues like cursor changes to identify interactive targets.