The agentic web is mostly the accessible web
TL;DR
AEO, GEO, agent-readiness, accessibility, structured data: looking at the actual checklists rather than the names shows the same practice in different rebadges. Plus what WebMCP changes about the read-side foundation.
Agent-readiness is the practice of optimising websites so autonomous AI browsers can complete tasks on the site for users. Recent web.dev pieces by Alexandra Klepper, Kasper Kulikowski, Rachel Lee Nabors, and Omkar More set out the framing and the practical checklist.
The checklist is, almost line for line, the existing accessibility checklist. The various waves of "optimise for X" advice (SEO, accessibility, structured data, AEO, GEO, LLMO, agent-readiness) keep arriving at the same set of practices through different doors. The convergence isn’t a coincidence. It reflects what "machine-readable" means in practice.
The pattern of overlapping rebadges
Each recent wave of SEO and content advice has come with its own acronym and framing:
- SEO (long-running): semantic HTML, hierarchical headings, alt text, internal linking, fast pages, crawlable URLs.
- Accessibility / WCAG (long-running): semantic HTML, hierarchical headings, alt text, label-for-input, focus management, sufficient contrast, keyboard navigation.
- Schema markup / structured data (since around 2011): typed entities, organisation markup, FAQ, HowTo, Article, Product schemas.
- E-E-A-T (Experience added December 2022; the final letter shortened from "Trustworthiness" to "Trust" in the September 2025 quality rater guidelines): clear authorship and credentials, transparent ownership, accurate meta information, source citations, an About page and contact details, secure transport.
- Helpful Content System (introduced August 2022; folded into core ranking March 2024): people-first content, demonstrated first-hand experience, original analysis, satisfying answers to the user's question, transparent disclosures of who wrote the content and why.
- AEO, GEO, LLMO (2023 onwards): citable specifics (statistics, quotations, named sources), entity authority, structured data, content extraction-ready formatting.
- Agent-readiness (per Klepper, Kulikowski, and Nabors on web.dev, February 2025): semantic HTML, accessibility tree integrity, label-for-input, stable layouts, visible interactive elements.
If you put any two of these checklists side by side, the overlap is large. Put them all side by side and the overlap is most of the actual work. The acronyms describe different audiences (search crawlers, assistive technology, AI surfaces deciding what to cite, AI agents trying to complete a checkout) and different motivations. The advice keeps landing on the same set of practices because those practices are what makes a website machine-readable, full stop.
About the agent-readiness checklist
Kulikowski and More's practical guide on web.dev lists 7 items for building an agent-friendly site:
- All necessary actions clearly reflected in the interface
- Stable layout across similar pages
- No ghost or transparent overlays hiding interactive elements
- Semantic HTML for actionable elements (
button,a, not styleddivorspan) roleandtabindexon custom interactive elements where semantic HTML is unavoidablecursor: pointeras a visual signal of actionability- The
forattribute onlabellinked to the input id
6/7 are direct WCAG 2.1 / 2.2 requirements. The exception is layout stability, which sits in the Core Web Vitals (CLS) box rather than strict accessibility. The article's own closing line acknowledges the overlap: "Everything we suggest to make a site 'agent-ready' also makes sites better for humans."
Overall, it’s not a criticism of the agent-readiness framing. It’s the natural consequence of how agents read websites. Agents combine three lenses:
- a screenshot,
- the rendered DOM,
- and the accessibility tree.
A vision model reads a screenshot the way a sighted user reads the screen. A DOM reader operates on the same HTML a search crawler does. The accessibility tree is what screen readers read aloud. Three classes of consumer, one machine-readable substrate.
The one part that isn't a rebadge
Reading a website has always been the problem. Acting on it (clicking the right buttons, filling the right fields, completing the checkout flow) is the new layer.
WebMCP is the Chrome team's proposal for that layer. Announced as an early preview programme on the Chrome Developers blog by André Cipriani Bandarra on 10 February 2026, WebMCP would let a website expose a structured set of "tools" to an agent. 2 different APIs are proposed: a declarative one for actions defined in HTML forms, and an imperative one for richer interactions defined in JavaScript. The agent calls a tool ("checkout this cart") and the website performs the action. The agent doesn't have to infer the action from the rendered DOM.
The early preview is sign-up only, and the implementation is behind Chrome's experimental flags. It’s too early to build production code against it. Anthropic's Model Context Protocol, introduced in 2024 for AI assistants more generally, is a separate proposal solving a related problem. It would be interesting if they converged in the future.
WebMCP sits on top of the read-side foundation rather than in place of it. A site that hasn't done the semantic HTML work can't expose meaningful tools through WebMCP, because there are no clearly-defined actions for the tools to wrap. The convergence ladder runs: machine-readable content (semantic HTML, accessibility tree, schema.org) → AI citation surfaces (AEO, GEO, LLMO) → AI agent action surfaces (WebMCP, MCP, whatever wins). Each layer needs the one beneath it. None of the new layers replaces the foundation work.
What’s worth doing in practice
The same audit serves all five constituencies (search crawlers, assistive technology, structured data consumers, AI citation surfaces, AI agents).
Run an accessibility audit. Chrome DevTools, axe DevTools, or a manual run-through with a screen reader. The findings are the same findings an agent-readiness consultant would surface, in the same priority order.
Inspect the accessibility tree on the pages that matter most. Chrome DevTools shows it directly in the Elements panel. If the Buy button shows up as genericContainer with no accessible name, that's an agent failure, a screen reader failure, and arguably a search crawler failure all at once.
Get the structured data right. Organization, Person, Article, Product, FAQ, and HowTo schemas serve search rich results, AI citation surfaces, and entity recognition for agent context. A single schema audit closes three boxes.
Watch WebMCP. Read the early preview programme materials. Don't build against it yet. The advice for the markup layer (semantic HTML, accessibility tree, label-to-input wiring) is the foundation it sits on, so doing the foundation work today doesn't waste effort if WebMCP changes shape.
What we still don't know
The volume of agent traffic relative to human traffic isn't yet broken out by industry in publicly available data. The patterns above are inferred from how the major agents work, rather than from large-scale empirical study of conversion outcomes attributable specifically to agents.
It’s also unclear whether search engines will start to weight agent task completion as a ranking input. Google's September 2025 quality rater guidelines update framed usability without naming agents specifically. If task completion becomes a measurable user signal, ranking systems may start to incorporate it. None of the major engines has confirmed they do this today.
The taxonomy will probably keep multiplying. New acronyms will arrive, each describing a new audience, and the audience-specific advice will be largely the same as the previous wave's. The discipline (machine-readable content, plus an emerging structured-action layer) is settling while the labels seem to get more creative.
Where this leaves us
Treating "agent-readiness" as the next big migration overstates the work. The actionable checklist is the accessibility checklist plus a layout-stability recommendation, and most operators have an unfinished version of that checklist already. Treating it as a non-event understates what's coming, because WebMCP and similar proposals do introduce a new layer (structured action exposure) on top of the read-side foundation.
The work is mostly the work that was already on the list. The new names describe who the readership is becoming opposed to what the practitioner needs to do differently.