Is your website ready for AI agents? The next visitors won't all be human

A new kind of visitor: agents that act, not only read

For thirty years, a website had two audiences: people, and the search crawlers that indexed pages for people to find. In 2026 a third audience became real and grew fast. AI browsers — ChatGPT Atlas, Perplexity Comet, Microsoft Edge’s Copilot Mode, Google’s Chrome agent — put an AI agent inside the browsing session that can carry out tasks autonomously. Ask Comet to “find availability and book a table,” and it navigates the restaurant’s site, fills the reservation form and confirms (No Hacks, 2026). These aren’t research prototypes: the category went from demo to mass-market consumer product in roughly fifteen months, and combined usage crossed the tens of millions early in the year (Pravin Kumar, 2026).

The distinction that matters is between reading and doing. Our pillar on being readable by AI covers the first half — whether an answer engine can read your content and cite you. Agent-readiness is the second half: once the agent lands on your page, whether it can actually complete the thing the person asked for. A site can be perfectly citable and still fail every agent that tries to use it, which is the quiet new failure mode of 2026 — the agent finds you, recommends you, sends the person over, and then can’t finish the booking.

Why most sites fail agents — the same reasons they fail people

Here’s the insight that makes this tractable instead of overwhelming: agents stumble over the exact obstacles that block people using assistive technology. When an agent can’t tell what a button does, it’s because the button isn’t labeled with what it does — the same problem a screen reader hits. When an agent abandons a form, it’s usually because the form uses custom widgets instead of native HTML controls, which Copilot Mode in particular tends to misclick (Open Hermit, 2026). When an agent gives up on a flow, it’s often because the content and controls only appear after heavy JavaScript runs, or because a CAPTCHA blocks the path.

Agents also strongly prefer structured data. Copilot Mode, the agent most likely to be reading an enterprise pricing page, heavily favors schema.org markup and reliable native controls (Open Hermit, 2026). One agentic-browser analysis put the design principle plainly: humans see colors, layout and emotion, while agents see structure, labels and predictable flows — so you don’t design for machines first, but you must design so machines can interpret the page correctly (AldoMedia, 2025). Every one of those requirements is something a well-built site already satisfies, and something a fragile one already fails.

The overlap you already own: accessibility is agent-readiness

This is the part worth sitting with, because it changes agent-readiness from a scary new mandate into work you should be doing anyway. The things an agent needs — semantic HTML, buttons and links labeled with their purpose, native and properly labeled form fields, logical heading structure, keyboard-operable flows, content present without waiting on scripts — are almost exactly the WCAG accessibility requirements that make a site usable for people with disabilities. As one accessibility team observed, properly structured headings and labels improve how both search engines and AI answer engines read your content (Optimum Web, 2026); the same structure that lets a screen reader announce a button lets an agent decide to click it.

So the same investment pays off three ways at once. A site built to the standard in our pillar on web accessibility is, by construction, easier for AI to read, easier for agents to operate, and — because in the EU accessibility is now the law — compliant. There’s no separate “agent optimization” budget to find. There’s the accessible, semantic, fast site you should already have, which happens to be the one agents can use. The teams that treated accessibility as infrastructure rather than a bolt-on widget arrive at 2026 already ready; the ones who sprayed an overlay script over a broken site are failing humans and agents alike.

What agents need: the concrete checklist

Stripped to specifics, here is what makes a site operable by an agent, and each item doubles as a usability or accessibility win:

• Extractable pricing. Put at least one real number on the page, even a starting price. Agents comparing options can’t weigh you if your price is “contact us” or lives only inside a script (Pravin Kumar, 2026).
• Buttons and links that say what they do. “Book appointment,” “Request quote,” “Add to cart” — not “Click here” or an unlabeled icon. The agent reads the label to decide the action (AldoMedia, 2025).
• Native, labeled form controls. Use real HTML inputs, selects and buttons with associated labels. Custom JavaScript widgets are where agents most often misclick and abandon (Open Hermit, 2026).
• No gratuitous CAPTCHA. Keep CAPTCHA off your primary contact and booking forms unless you have a documented spam problem; it’s a hard stop for a legitimate agent acting for a real customer (Pravin Kumar, 2026).
• Structured data (schema.org). Mark up products, services, prices, availability, FAQs and organization details so the agent reads facts instead of guessing from layout — the same schema markup that helps AI cite you.
• Content that doesn’t need JavaScript to exist. Agents behind the crawling layer don’t reliably run scripts, and even in-browser agents do better with server-rendered content — the same rendering discipline our pillar returns to again and again.

None of these is exotic. Together they’re a description of a competently built website.

WebMCP: publishing tools instead of hoping agents guess

Today, an agent operating your site is essentially reading the screen and inferring what to click — capable, but error-prone. The emerging fix is WebMCP, also called navigator.modelContext, a browser standard that lets your site publish structured “tools” an agent can call directly: search products, check availability, add to cart, submit a form (Tandem, 2026). Instead of screen-scraping and guessing, the agent invokes documented actions and gets reliable results. One team compared its significance to the arrival of responsive design: adapt, or become progressively harder for a growing share of visitors to use.

The honest status is early. WebMCP began shipping behind a feature flag in Chrome in 2026 and is expected to broaden later in the year, and the spec is still a draft, so the sensible move is to prototype and watch rather than rebuild around it today (Tandem, 2026). But the through-line is the same as everything above: the sites that will adopt WebMCP most easily are the ones already built on clean, semantic, well-structured foundations. It’s a layer on top of good architecture — of a piece with llms.txt and structured data — not a rescue for a bad one. When it matures, we’ll build it on top of a site that was already agent-ready without it.

The smoke test: watch an agent try your site

The most convincing audit is the one you run yourself, and it takes about two minutes with no special tooling. Open Perplexity Comet or ChatGPT Atlas in agent mode, go to your site, and ask the assistant to complete your single most important task in plain language — “add the cheapest plan to the cart and proceed to checkout,” “find the contact form and submit my inquiry,” or “compare this product to a competitor’s” (Open Hermit, 2026). Then watch, and note where it succeeds, clicks the wrong thing, or gives up.

Most teams uncover the same short list: the agent misreads a vague button, stalls on a custom form control, hits a CAPTCHA, or can’t locate a price (Pravin Kumar, 2026). That list is your roadmap, and it’s worth doing monthly, because the same fixes that unblock the agent — clearer labels, native controls, a visible price — also help the humans who were quietly struggling with the same rough edges. One caution worth knowing: agents can be manipulated by hidden text and injected instructions on a page, and letting them act on sensitive accounts carries real risk, so the goal is making your public, task-oriented pages operable, not handing agents the keys to everything (Human Security, 2026).

What we’d tell you

The temptation with any new channel is to treat it as a special project with its own budget and its own vendor. Agent-readiness resists that framing in the most useful way: the work is the work you should already be doing. Build the accessible, semantic, fast, structured site — the one that serves people with disabilities, ranks in search, and gets cited by AI — and you have also built the site that agents can operate. The measurement that matters isn’t how much agent traffic you get; it’s whether the agent-referred sessions convert as well as your human ones, which is the number worth watching as this grows (Pravin Kumar, 2026).

So our advice is unglamorous and freeing: don’t chase the agents, earn them. Run the smoke test to see where you stand, fix what blocks both agents and humans, keep your pricing and actions explicit and your markup clean, and prototype WebMCP when you’re ready without betting the site on it. This is the natural next chapter of the same story our guide on being readable by AI started, and the commerce-specific version — how agents discover and buy — is in our guide on agentic commerce. A site built to do less, cleanly, is a site that’s ready for whoever — or whatever — shows up to use it.