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 genuinely 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 is not coincidence. It reflects what "machine-readable" actually means in practice.
The pattern of overlapping rebadges
Each recent wave of SEO and content advice has come with its own acronym and its own 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.org / structured data (since around 2011): typed entities, organisation markup, FAQ, HowTo, Article, Product schemas.
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.
What the agent-readiness checklist actually contains
Kulikowski and More's practical guide on web.dev lists seven 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
Of those seven, six 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."
That is not a criticism of the agent-readiness framing. It is 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.
Where the convergence ends and genuinely new work begins
There is one part of the agentic web that is not a rebadge of anything older. 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. Two 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 does not have to infer the action from the rendered DOM.
WebMCP is not a stable standard yet. The early preview is sign-up only, and the implementation is behind Chrome's experimental flags. It is 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. The two have not converged; they may or may not.
What is genuinely new is that WebMCP sits on top of the read-side foundation. A site that has not done the semantic HTML work cannot 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 is 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 is 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. Do not 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 does not waste effort if WebMCP changes shape.
What we still don't know
The volume of agent traffic relative to human traffic is not yet broken out by industry in publicly available data. The patterns above are inferred from how the major agents work, not from large-scale empirical study of conversion outcomes attributable specifically to agents.
It is 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. The labels are not.
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 is coming, because WebMCP and similar proposals do introduce a genuinely 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, not what the practitioner needs to do differently.