I have spent years in rooms where grown adults argued about whether a button should read "Get started" or "Start free trial". Those arguments were worth having. Copy moves numbers.
This year I started reviewing the same pages for a visitor that has no opinion about the copy, cannot see the gradient anybody fought over, will never fill in an exit survey, and will never tell you it left. It just leaves.
Some people have started calling this AX, agent experience. I resisted the acronym for about a month and then gave up, because the thing it names is real: UX now has a sibling discipline, and almost nobody is staffing it.
Your traffic already has a second audience
Let me get the scale honest before I make the case, because this topic attracts wild claims.
HUMAN Security published a breakdown of agentic traffic in July 2026. Perplexity's Comet accounted for 47.1% of agent sessions, Claude's Chrome extension 24%, ChatGPT Atlas 15.5% (now being sunset), and ChatGPT Agent 6.1%. Publishers took 43.5% of the destinations, e-commerce 42%, travel 13.4%. Agentic traffic grew 7,851% year over year across 2025.
That growth number is spectacular and nearly meaningless on its own, so here's the denominator. Cloudflare's year in review put AI bots at roughly 4.2% of HTML traffic across 2025. Not a takeover. A minority audience.
I still think it deserves a design discipline, and the reason is that the agent isn't the customer. It's acting for one, someone who has delegated the reading. When an agent stalls on your filter control, the human never learns that your filter control was the problem. They just get a different recommendation.
Strange kind of visitor to lose. Not a bounce you can see. A verdict formed on your behalf, somewhere else.
What an agent actually sees
Google's web.dev guidance on building agent-friendly sites, updated April 2026, is the most useful document on this subject and mercifully short. It says agents perceive a page three ways: screenshots, raw HTML, and the accessibility tree, which it describes as a high-fidelity map that ignores the visual noise of CSS.
Nothing in that list is your JavaScript. Vercel's crawler analysis, using November 2024 data, found that no major AI crawler executes it. OpenAI, Anthropic, Meta and Perplexity fetch JS files and never run them.
So the three channels are a blurry picture, a text dump, and a tree of labelled controls. That's your design, received.
Here's the sentence I keep repeating to clients: humans squint past bad UX all day long. It's the load-bearing assumption of mediocre web design. A person sees an unlabeled icon and guesses from position, color and context, usually correctly, without noticing they guessed. An agent reading the accessibility tree sees a box with no name and nothing to guess with.
Agents can't squint. Everything below follows from that.
Perceivable: can it read the page at all
The first question isn't whether an agent likes your page. It's whether your content exists at all in the channels the agent reads.
Adobe reported that 80% of early-access customers for its LLM Optimizer had critical content-visibility gaps. That tracks with what we find whenever we view source instead of viewing the page: prices, availability, spec tables and pricing tiers arriving after hydration, which is to say never, as far as a crawler is concerned.
Server-render the substance. Title, price, stock, key specs, the actual answer to the question the page claims to answer. One honest note on attribution: that server-rendering argument comes from Vercel's crawler data, not from Google. Google's own guidance is gentler than the loudest voices on this topic. It says don't worry about perfect code, and it says structured data isn't required for generative AI search. Ship JSON-LD because it makes price and availability unambiguous, not because someone told you it was mandatory.
Semantic HTML sits here too, and this is where I have to admit something. The people who spent fifteen years telling us to use `<button>` instead of a clickable div were right, and they were right for reasons that had nothing to do with agents. They just finally got an audience that punishes the alternative in a measurable way.
Operable: can it finish anything
Legibility is the easy half. Operability is where projects actually die, and where almost nobody is looking, because "can an agent read my site" is a much more comfortable question than "can an agent complete a task on my site".
Google's checklist is concrete enough to hand to a front-end developer:
| Signal | What it means in practice |
|---|---|
| Stable layout | Their own example is an add-to-cart button that sits in a different place depending on the category. Screenshots stop matching the page. |
| No ghost overlays | Transparent or leftover layers swallow clicks that look, in the screenshot, like they should land. |
| Real elements | <button> and <a> over div and span. If you must use a div, give it a role and a tabindex. |
| cursor: pointer | Google treats it as an actionability signal. A hover state is documentation. |
| <label for> | Placeholders are not labels. An agent filling your form reads labels. |
| Visible target size | Interactive elements need more than 8 square pixels of visible area. |
Lighthouse turned part of this into a pass/fail test. Its agentic browsing category shipped in v13.3.0 on 7 May 2026 and is now in Chrome DevTools and PageSpeed Insights. The accessibility-tree audit runs 38 axe rules and scores zero if any single one trips.
We ran it across some well-built sites in August 2026. stripe.com scored 3/3. shopify.com scored 2/3, tripped by ARIA role and button-name violations. airbnb.com managed 1/2. Our own site scored 2/3 at the time, failed on a malformed llms.txt, and we fixed it; it scores 3/3 now. If Shopify's marketing site fails a button-name check, your theme isn't passing by accident.
The test I actually recommend costs nothing and takes ten minutes. Open a browser agent, give it a real task on your site, and watch. Where it stalls is your roadmap. When the task involves money, that stall has a price attached, which is the subject of what happens when the buyer is an AI agent.
Addressable: the part that isn't real yet
Perceivable and operable are today's work. Addressable is the interesting future, and I want to be careful with it.
WebMCP is a proposed standard that lets a page declare tools an agent can call directly, instead of making it drive your interface like a person would. Declarative attributes on a form (`toolname`, `tooldescription`, `toolparamdescription`) turn that form into something an agent can invoke by name.
Status, plainly: Chrome origin trial, versions 149 through 156, expiring around late October 2026. Proposal stage in a W3C community group. No signal from Firefox, none from Safari. No named production adopters in any primary source. Chrome's own documentation describes it as primarily designed for local browser workflows with a human in the loop.
So pilot it if you enjoy this sort of thing, and don't build a business case on it. The reason it's still worth an afternoon is that the preparation isn't wasted: giving your forms clean semantics and describable purposes is the same work the operability list already asked for. We covered the mechanics in WebMCP explained.
They fail loudly and leave silently
This is the part I find genuinely disorienting as someone who came up through UX research.
Every feedback loop I trust was built for humans. Session recordings, rage clicks, support tickets, the one customer who emails to say your date picker is broken on Safari. An agent generates none of that. It fails loudly inside its own reasoning trace, which belongs to somebody else's product, and from where you're sitting it's a request that arrived, got something unusable, and went away.
You can see the traffic, at least. Fastly measured more than 51% of AI requests reaching origin, against under 9% of human requests, so caching isn't hiding them from your logs. What you can't see is the failure. There's no analytics event for "an agent couldn't tell which of your two submit buttons was the real one".
Designing for a visitor who files no complaints changes how you work. You stop waiting for feedback and start auditing, which is less fun and considerably more honest.
AX is accessibility, finally with a business case
Google's agent-friendly guidance closes with a line I've been quoting on client calls all summer: "Everything we suggest to make a site 'agent-ready' also makes sites better for humans."
There's no trade-off hiding in here. Not one item on the list is agent-specific. Named buttons, labelled inputs, real semantic elements, layout that stops moving, content that exists in the HTML. That's the accessibility checklist, plus the craft a good front-end developer would have shipped anyway and got told to cut because nobody could put a number on it.
We've written before about why UX decides whether a mobile app survives, and the argument there is the argument every UX person has been making for twenty years: quality of experience compounds, and sloppiness compounds faster. Always true. Always hard to fund.
The argument didn't change. What changed is that a slice of your visitors now fails hard and visibly on exactly the things a screen reader user has been failing on quietly for years. My feelings about that are mixed. It's a bit bleak that semantic HTML needed a machine audience before it got a budget line. But I'll take the win, because the fix lands first on the people who needed it all along.
If you want to know where your site stands, run `npx lighthouse https://yoursite.com --only-categories=agentic-browsing` and then do the ten-minute agent test above. The score and the stall usually disagree, and the stall is the one that matters.
Or let us look. Our free agent-readiness audit tells you which controls an agent can't name, which content never reaches the HTML, and where your forms lose it. You decide what's worth fixing, knowing your human visitors get every fix too.
