Google’s agent-friendly guidance is just accessibility, finally winning

Google quietly published a developer guide on web.dev last week titled *Build agent-friendly websites*. The framing is that websites now have "a new type of visitor" — AI agents acting on behalf of humans — and developers should design accordingly. The recommendations include semantic HTML, stable layouts, properly labelled form inputs, and `cursor: pointer` on clickable elements.

If that list sounds familiar, it should. It's the accessibility checklist that's been sitting on the same domain for fifteen years.

I've been waiting for this argument to land somewhere with weight, and Google has now made it for me. The thing accessibility advocates have been saying since the WCAG 1.0 days — that semantic, machine-readable HTML is the floor of a competent website — has finally been given a commercial reason to matter. Not because anyone suddenly cares about screen reader users. Because the agent reading your page might be the only "visitor" between you and a sale.

The guidance is not new. The audience is.

Read the web.dev guide carefully and you'll notice something. There is essentially nothing in it that wasn't already true.

Use `<button>` instead of a styled `<div>`. Link `<label>` to inputs with the `for` attribute. Keep layouts stable. Use the accessibility tree as your interface description. Every one of these is decade-old advice that accessibility consultants have been begging clients to follow, usually unsuccessfully. The reason it's failed to land isn't that developers are lazy. It's that the cost of ignoring it has been borne almost entirely by users who don't show up in analytics — screen reader users, keyboard-only users, people on slow connections, people with cognitive impairments — and the commercial case has always been thin.

Now Google is reframing the same advice with a different stakeholder. The page that's "functionally broken for agents" is the same page that's been functionally broken for assistive technology since it was built. The guidance hasn't changed. The visitor who matters to procurement has.

Why Google is doing this now

Three things are happening at once and they're all pulling in the same direction.

The agent doesn't punish you for bad HTML. It just goes somewhere else.

First, the agent layer is real. ChatGPT can browse, Perplexity can transact, Comet and Arc-style agentic browsers are accumulating users, and Google itself is shipping more agentic features into Search. None of these systems can interact reliably with a page that's a wall of unsemantic divs. The proportion of "users" who literally cannot use a badly-built site is rising fast.

Second, Google is hedging. The web.dev guide links to WebMCP, a proposed standard where websites register tools with defined input/output schemas that agents can discover and call as functions. Chrome is running an early preview programme. This is Google saying: even if the open web stops being the primary interface for humans, we'd like it to remain the primary interface for the agents acting on their behalf. Whether that bet works is a separate question. The point is that Google has decided agent-readability is now part of its developer guidance alongside performance and accessibility.

Third — and this is the part the SEO industry will undersell — agent-readability is going to start correlating with discovery. If an agent can't parse your booking flow, your product schema, your pricing table, or your contact form, you don't exist in the agent layer. You can have brilliant content and a strong brand and still be invisible to the system that's increasingly mediating between users and the web.

The agent doesn't punish you for bad HTML. It just goes somewhere else.

The accessibility argument was always the SEO argument

I've sat through enough technical audits to know how this conversation usually goes. A site is built on a stack of nested divs with click handlers. Forms have placeholder text instead of labels. Buttons are anchor tags styled to look like buttons. The dev team knows it's not great. The marketing team has heard "accessibility" in a meeting somewhere. Nobody wants to pay to fix it because the business case is fuzzy.

The business case has never been fuzzy. It's just been politely ignored.

Semantic HTML is what makes a page parseable by Googlebot, Bingbot, the Common Crawl, screen readers, browser reader modes, and now the agent stack. The exact same markup that helps a blind user navigate your checkout helps Perplexity understand what you sell. The same `<label for="email">` that helps a keyboard user fill in your form helps an agent autofill on someone's behalf. The same stable layout that prevents a low-vision user getting lost helps a vision-model agent identify the same button on two different visits.

The reason this matters now is that the discovery surface has multiplied. When the only machine reading your page was Googlebot, you could get away with a lot, because Googlebot has spent twenty-five years getting clever enough to extract meaning from broken markup. New agents are not Googlebot. They're operating on screenshots, raw DOM, and accessibility trees, often with limited compute, often making decisions in seconds. They don't have the patience or the cleverness Google built up. If your page doesn't tell them what it is, they will assume it isn't anything.

What this actually means if you run a website

The temptation will be to read this as another item on the GEO checklist. Add structured data, add llms.txt, add a WebMCP manifest, tick the box, move on. That misreads the situation.

The thing Google is pointing at is more fundamental than any of those add-ons. It's whether your site is built on semantic HTML at all. If your menu is divs with `onclick`, no amount of JSON-LD will save you when an agent tries to interact with it. If your forms don't link labels to inputs, the agent will guess and get it wrong. If your interactive states only exist on hover, an agent operating on a single screenshot has no idea they exist.

This is the layer underneath the GEO conversation, and almost nobody in the optimisation industry is talking about it because there's no software product to sell on top of it. You can't charge a monthly subscription for "your HTML is correct." But the businesses that already have this right — usually because they took accessibility seriously, or because they had a developer who insisted on doing it properly five years ago — are about to get an unearned advantage in the agent layer. The ones that don't are going to discover that the cheapest way to be visible to agents was to have written it correctly the first time.

The fix isn't a tool. It's an audit of whether your page would still be usable if you stripped all CSS and JavaScript away. If the answer is no, the agent layer is going to treat you the way screen readers have treated you for fifteen years. Quietly skipping past you on the way to a competitor.

The honest read

Google publishing this on web.dev doesn't mean agent-readability is now a ranking factor. It means Google thinks it will become one, or that the ecosystem around its products will start treating it like one, and it would prefer the open web be ready. There's a self-interested layer here too — if WebMCP becomes a standard, Chrome ships it first, and Google sits comfortably as the orchestrator between agents and websites the same way it's sat as the orchestrator between humans and websites.

But you don't need to believe in the WebMCP future to act on this. The recommendations in the guide are correct on their own terms. They were correct in 2010, they were correct in 2018, and they're correct now. The only thing that's changed is the cost of ignoring them.

Accessibility consultants spent two decades being right and unheard. They're about to spend the next two decades being right and finally getting their invoices paid. I'm not sure that's a vindication anyone wanted, but it's the one we've got.