Many AI agents read your site through the tree screen readers use.
Assistants that compare, book, and buy on a person's behalf need what a screen reader needs: real buttons, labeled fields, and a page structure that means something. We test your key journeys the way agents read them, then fix what gets in the way.
Three ways an agent sees your page
Google's web.dev guidance describes 3 ways AI agents perceive a website: screenshots, raw HTML, and the accessibility tree. Screenshots are slow to process and easy to misread. Raw HTML is noisy, full of wrapper elements and scripts. The accessibility tree is the browser's own summary of what each element is, what it's called, and what state it's in, and Chrome's developer guidance calls a well-formed tree the primary way agents understand a page.
That is the same tree screen readers use. When a checkout button is a styled <div> with a click handler, a screen reader can't name it and an agent can't reliably find it. When a form field has no label, both have to guess.
So agent readiness starts with accessibility. Then it adds what agents need on top: structured data that matches the visible page, forms that tell a machine what each field expects, and a deliberate policy on which crawlers may read what.
The same control, as an agent sees it
A styled <div>
- No role, so it isn't exposed as a button
- No accessible name unless someone adds ARIA
- Not focusable or keyboard operable by default
- State, such as expanded or selected, lives only in a CSS class
A native <button>
- Exposed with the button role automatically
- Named by its text, or by
aria-labelwhen it's an icon - Focusable, and operable with Enter and Space
- State exposed through
aria-expanded,aria-pressed, ordisabled
What we check on each journey
We pick two or three journeys that matter to your business, such as finding a product, booking an appointment, or requesting a quote, and inspect every layer.
| Layer | What we inspect | Typical fix |
|---|---|---|
| Semantics | Landmarks, heading order, lists, and native controls in the accessibility tree | Replace clickable <div> and <span> elements with real buttons and links |
| Names, roles, and states | Whether every control has an accurate name and exposes its current state | Visible labels, aria-expanded on disclosures, aria-current in navigation |
| Forms | Labels, autocomplete tokens, required fields, and how errors are announced | Programmatic labels, tokens such as email and postal-code, errors tied to fields with aria-describedby |
| Structured data | schema.org JSON-LD for products, offers, organizations, and events | Markup that matches the visible page, including prices and availability |
| Crawler policy | robots.txt rules, AI crawler user agents in your logs, and any llms.txt file | A written policy first, then rules that implement it |
Which AI crawlers may read your site is a business decision
Your robots.txt file already answers this question, often by accident. Some AI companies publish separate user-agent tokens for training models and for fetching pages live when a person asks a question, so you can allow one and block the other. Blocking everything can keep your products out of the answers people get. Allowing everything may hand your content to uses you'd rather license. Remember that robots rules are requests that well-behaved crawlers honor, not access controls.
We lay out the options, your team decides, and we implement the decision in robots.txt and your server rules, then confirm it in your logs.
We also look at llms.txt, a proposed convention for a plain-text guide to your site aimed at language models. It isn't a standard and support varies, but it costs little to publish. We treat it as optional, and keep it accurate if you choose to have one.
WebMCP is a draft, not a standard
WebMCP is a proposal that would let a page offer structured tools, with names, descriptions, and input schemas, that an agent in the browser can call instead of clicking through the interface. It is published by the W3C Web Machine Learning Community Group as a Draft Community Group Report. It is not a W3C Standard and is not on the W3C Standards Track, and Chrome's support is an experimental origin trial. We follow it and can prototype with it, but we don't recommend building critical journeys on it yet.
How we test agent readiness
Choose the journeys
We agree on two or three tasks an agent might complete for a customer, and what success looks like for each.
Inspect the accessibility tree
We capture the tree at every step with Chrome DevTools and Playwright's ARIA snapshots, and compare names, roles, states, and order against the visible page.
Run the agents
We attempt each task with current browser-using AI agents and record where they hesitate, misread, or fail, alongside a screen-reader pass through the same steps.
Check structured data and crawler access
We validate JSON-LD against schema.org and the visible content, and confirm your robots rules and server logs match your policy.
Rank the fixes
Fixes are ranked by the journeys they unblock, for agents and for people using assistive technology, with code-level guidance for your developers.
One audit, two or three journeys
Agent-Readiness Audit
Starting at
$3,600
How AI agents and crawlers read your key journeys, with fixes for labels, structure, and structured data.
Request a quoteFixes can be made by our remediation team or yours. Most agent-readiness fixes are also accessibility fixes, so each one helps two audiences.
Questions about AI agents and your website
Is this just SEO with a new name?
No. Search optimization is about being found. Agent readiness is about whether an assistant can finish a task once it arrives: find the right button, complete the form, and read the price correctly.
Do we need an llms.txt file?
It's optional. It's a proposal rather than a standard, support varies, and it won't help on a page an agent can't operate. If you publish one, keep it short, accurate, and maintained.
Should we block AI crawlers?
That depends on how your content earns its keep. A business that sells products or services may want to be recommended; a publisher may prefer to license. We lay out the trade-offs, and your team decides.
How is this different from an accessibility audit?
They overlap on purpose. An accessibility audit covers every WCAG criterion across your templates; an agent-readiness audit goes deeper on a few journeys and adds structured data and crawler policy. If you've had a Baclion audit, we build on its findings.
Keep reading
Tell us what your website needs to do.
Send a link and a sentence about your deadline. You will hear back from a person within one business day, usually with a short list of questions and a proposed scope.