Agent Experience (AX): The Websites Agents Can Actually Use

Agent Experience (AX) is how well a website serves an agent that is acting for a person: opening the pages, reading them, filling the form, getting to the price. Search engine optimization (SEO) and generative engine optimization (GEO) decide whether crawlers and answer engines can find and quote a site; neither asks whether an agent sent to do a job can actually do it there.

The second user on every page

For most of the web's history, a page had one kind of user who acted on it: a person. Crawlers read pages, but they didn't try to buy anything. That changed when browsers and assistants started shipping agents that click and type. OpenAI's ChatGPT Atlas launched in October 2025 with an agent mode that opens tabs, follows links and fills forms while the user watches. In January 2026 Google added auto browse to Chrome, a Gemini agent that handles multi-step tasks such as filling forms and shopping.

So a pricing page now has two readers. One is the person. The other is an agent the person sent, which reads the page through a different channel and gives up without telling you.

The term itself isn't new. Netlify's CEO Mathias Biilmann wrote "Introducing AX" in January 2025, describing agent experience as "the holistic experience AI agents will have as the user" of a product. His examples are developer platforms: agents that deploy sites, call APIs and read docs. We use the term for the public website, where the agent is acting for a customer, not a developer.

How AX differs from SEO and GEO

	SEO	GEO	AX
Who reads the page	A search crawler	An answer engine	An agent acting for a person
What it wants	To index and rank the page	To quote or link it in an answer	To finish a task on the site
Success looks like	A ranking for a query	A citation in an answer	Price found, form sent, trial started
Typical failure	Not indexed	Not cited	Blocked, lost, or stuck halfway

The three overlap. A page an agent can read is usually one a crawler can index and an answer engine can quote. But a site can rank well and get cited often while its sign-up form defeats every agent that tries it, and no SEO or GEO report would show that.

What breaks agents

Many browser agents read a page through the accessibility tree, the structure browsers build from the DOM for screen readers, where every element has a name, a role and a state. Playwright's agent tooling, for example, hands the model a snapshot that is "an accessibility tree with element refs for interaction". Some agents fall back to screenshots. Either way, the failures below are the first entries in a catalogue of agent patterns, the ways a site defeats an agent. Each fix also helps a person.

Consent walls that cover everything. A cookie banner that blocks the page until it is dismissed, with buttons an agent can't identify, can end a run on the first screen. Fix: give the buttons plain text names ("Accept", "Reject", "Settings") and let the content load behind the banner.

Text drawn on a canvas. Prices and plan names rendered in a canvas or as images of text don't reach the accessibility tree. Fix: put the text in the HTML.

Unlabeled forms. A field whose only label is placeholder text that disappears on focus, or an icon-only button with no accessible name, leaves the agent guessing which box takes the email. Fix: a visible <label> for every field and a name for every control, as WCAG's Name, Role, Value criterion already requires. Our ARIA labels guide covers the details.

State an agent can't hold. Multi-step flows that keep progress only in memory, time out quickly, or lose everything on a back navigation punish anything slower or more literal than a practised user. Fix: put the step in the URL and keep entered values on return.

Infinite scroll with nothing at the end. If the plans, the footer links or the contact details only load as you scroll, an agent that reads one snapshot may never see them. Fix: paginate, or keep the important links in the HTML from the first load.

Ghost buttons. A <div> styled to look like a button, with a click handler and no role, looks fine on screen and is invisible as a control in the tree. Fix: use a real <button> or link.

Bot walls that stop the user's own agent. Bot protection that challenges every automated visitor also challenges the agent a customer sent to check your prices. Fix: decide which agents you let in and tell them, through your robots rules and your bot protection's handling of declared, verified agents.

What a readiness checklist can tell you

Several tools already score sites for agents, and they are worth running. Cloudflare's Agent Readiness score checks which standards a site supports across discoverability, content, bot access control and capabilities: robots rules, sitemaps, Markdown for agents, Web Bot Auth, API catalogs, MCP server cards. squirrelscan's Agents rules group similar checks into Readable, Reachable, Discoverable, Declared and Actionable. Ora goes further and sends real agents through each site; its state of agent readiness report sums up its April 2026 snapshot as "Agents can read. They can't act."

A site can pass those checks, publish llms.txt, declare its agent policy, list an API catalog, and still hide its prices behind a canvas or lose the agent in a three-step form.

How to measure it

Measuring an agent's experience borrows from usability testing, with one advantage: you can run the participant yourself, as often as you like.

Pick one reference agent and record its version on every run, the way a test report names its browser; results from different agents, or the same agent a month apart, aren't comparable. Give it the same short list of read-only tasks every time: find the pricing, find a way to contact sales or support, find where to sign up, find the returns policy or terms. Read-only matters. An agent that submits forms or creates accounts on someone's site is doing something the owner never agreed to.

For each task, record one of three outcomes: completed, a dead end (it got in but couldn't find or reach the thing), or blocked (it never got past the first load). The dead end is the most useful finding, because it names the page and the step where the site lost the agent. Stamp every result with when the site was captured, which agent version ran and which rubric judged it, or the finding can't be re-checked after a fix.

Model-driven agents don't take the same path twice, so run each task several times and report how many runs completed.

Why a separate agent site goes stale

Some teams' first instinct is to build a separate surface for agents: a stripped-down page, a feed, a parallel site. Accessibility work tried this with separate text-only versions of sites, and WCAG accepts an alternate version only if it is kept as current as the original. Every price change then has to land in two places.

The better route is the one accessibility already points to. Semantic HTML, real labels, text that is text, state that survives navigation. A page built that way serves the screen reader, the keyboard user, the person on a slow phone and the agent from the same source. Declared files like llms.txt and API catalogs are worth adding on top, as a supplement to a page that already works.

Where to start this week

Five checks a team can run by hand in an afternoon:

1. Read your pricing page's accessibility tree. Open the browser's developer tools, switch the Elements panel to the accessibility tree view, and check that the plan names, prices and buttons appear with sensible names.
2. Do your key journey with the keyboard only. From the homepage, reach pricing, then contact, then sign-up, without the mouse. Anything you can't reach or can't tell apart, an agent will struggle with too.
3. Send your own agent. Ask a browsing agent to find your price and your support contact, and watch where it hesitates or stops.
4. Read your robots rules and your bot protection settings together. Decide whether a customer's agent should get in, and check that the two say the same thing.
5. Break your main form on purpose. Leave a field empty and submit. The error should be text, next to the field, naming what to fix.

The patterns behind these checks are the same ones in our library of UX patterns and the laws of UX shelf.

What we are building

We are building a way to measure AX: a pinned reference agent attempting read-only tasks, scored across reachability, legibility, the declared surface and task success, with a report that names where the agent stopped. It is in closed beta, it runs only on domains the requester owns, and we are measuring our own site first. If you'd like your site measured, request access on the AX page. For the human side of the same question, the UX Snapshot scores how clear a page is to the people using it.

More on accessibility and inclusive design: the accessibility hub.