The question used to be how AI reads your website. Now it is also how AI uses it. AI browsing agents open a real browser on a person’s behalf, click through menus, fill in forms and take a booking or quote request to its last step, usually handing back to the person to confirm.
A page an agent can’t read drops out of the comparison. A form it can’t complete is an enquiry that never arrives, with no error to warn you. Fortunately, agents rely on much the same things as people using screen readers, keyboards and phones.
Last reviewed: 27 September 2026. Agents change fast, so this advice is vendor-neutral and built on established web standards.
The short answer
- What they are: AI assistants that operate a browser for a person, clicking, typing and submitting rather than only summarising.
- What they rely on: facts in page text, semantic HTML with clear labels, keyboard-friendly forms with autocomplete, and prices and policies stated plainly.
- What stays with the person: payment, logins, consent and anything hard to undo.
- What stops them: hover-only menus, custom controls, facts in images or PDFs, puzzle CAPTCHAs and blanket bot blocking.
- The shortcut: a site that meets WCAG 2.2 level AA and keeps key facts in HTML is most of the way there.
What AI browsing agents are, and how they see your website
A browsing agent takes a goal in plain language, such as “book the earliest Saturday physiotherapy slot near my office”, and works through websites step by step to reach it. It is also called agentic browsing or a computer-use agent. This guide covers agents other people send to your site; to run one yourself, start with AI agents for business.
Where they run
At the time of writing (June 2026), browsing agents from the large AI companies come in three shapes:
| Shape | Where the browser runs | What your website sees |
|---|---|---|
| Agent mode in a chat assistant | The vendor’s cloud | Data-centre IP addresses, sometimes a declared or signed identity |
| Browser extension | The person’s browser | An ordinary visit, with their cookies and logins |
| AI browser, or AI built into a browser | The person’s device | Often indistinguishable from an ordinary visit |
How an agent reads a page
Depending on the product, an agent reads a screenshot, the page’s structure, or both. Structure means the HTML and the accessibility tree: the simplified map of headings, links, buttons and fields that browsers build for assistive technology.
That is why accessibility decides so much. A <div> styled as a button has no button role in the accessibility tree, so it reads as plain text. A field labelled only by placeholder text loses its label once filled, so an agent checking a screenshot can’t tell which box holds what.
OpenAI’s guidance for its ChatGPT Atlas browser points the same way, asking sites to follow WAI-ARIA best practice so its agent can interpret buttons, menus and forms. Pair that with the W3C’s first rule of ARIA: use native HTML elements wherever they exist, and ARIA only where they fall short. Accessibility and SEO shows how the same foundations help search engines.
Put the facts in text an agent can read
Most tasks start with questions. Do you cover my area? What does it cost? What if I cancel? If the answer isn’t readable text, the agent may report that it couldn’t find it, guess, or move on to a competitor who states it plainly. Generative engine optimisation covers the overlapping job of being cited by assistants.
Server-rendered text, not images or PDFs
Opening hours in a graphic or prices in a scanned PDF may be misread or skipped, by agents and by the search tools they use to find you. Put the facts in HTML. Browsing agents run a full browser, but many crawlers and fetchers behind AI assistants don’t run JavaScript, so facts that appear only after scripts run can be missed.
State prices, availability and policies plainly
“Contact us for pricing” gives an agent nothing to compare. A range, or a “from” price with what it includes, gives it something to weigh, and the same goes for lead times, booking rules and cancellation terms. Keep every fact identical wherever it appears: an agent that finds two sets of opening hours can’t know which is right.
Add structured data as a second copy
JSON-LD using the Schema.org vocabulary restates key facts in machine-readable form: a LocalBusiness with its address and opening hours, say, or a Product whose Offer carries price and availability. Few agent makers say whether their agents read it, but search engines use it, and search is often how an agent finds you. Schema markup for business websites covers which types are worth adding.
Make forms and bookings possible to finish
Forms are where research becomes an enquiry, and where a small flaw costs most. How to design accessible forms covers the detail; these points matter most when AI agents are filling in forms.
Label fields and name their purpose
Tie a visible <label> to every field, mark required fields in text rather than colour alone, and accept international phone numbers and addresses. Then add autocomplete attributes, which tell browsers and assistive technology exactly what each field is for and give an agent reading the code the same clue. WCAG asks for them on fields that collect information about the user (success criterion 1.3.5, level AA).
| Field | Attribute value |
|---|---|
| Full name | name, or given-name and family-name |
email |
|
| Phone | tel |
| Company | organization |
| Address | street-address, postal-code, country-name |
Prefer native controls, and drop hover-only steps
A native <select>, checkbox or radio button is exposed correctly to keyboards, screen readers and agents. A dropdown built from <div>s, a calendar you can’t type a date into or a menu that opens only on hover may not be. Every step should work with a click or a key press, including anything operated by dragging (WCAG 2.2 success criterion 2.5.7, Dragging Movements).
Keep the path forgiving
- Keep answers after an error, with a message beside the field saying how to fix it.
- Keep answers between steps, and don’t make people re-enter details given earlier in the same process (WCAG 3.3.7, Redundant Entry).
- Write specific buttons: “Continue to your details” tells an agent more than “Next”.
- End on a real confirmation page that says what was received and what happens next.
- Keep the form visible: no pop-up over the fields, and a cookie banner with a plain reject option.
Keep payment, consent and irreversible steps with the person
An agent ticking a box is not the person reading what it says. The main AI vendors say their agents ask before consequential actions such as purchases, and many hand logins and payment back to the person. Design for that pause.
- Payment. Leave card entry to your payment provider, and show the full total, fees and taxes included, before the final button.
- Consent. Leave consent boxes unticked, say plainly what is being agreed, and confirm marketing sign-ups by email. How the law treats consent given through an assistant is a question for your legal adviser.
- Final actions. Label buttons with exactly what they do: “Confirm and pay”, “Send enquiry”.
- Accounts. Allow guest bookings where you can; a login usually sends the task back to the person.
Don’t turn legitimate agents away by accident
Some businesses will reasonably keep agents out, and should you block AI crawlers? covers those access decisions. The bigger risk for most sites is blocking them without meaning to.
CAPTCHAs that end the task
A puzzle CAPTCHA can stop an agent or hand the task back to a person who may no longer be watching. It also shuts out some people, which is why WCAG 2.2 limits puzzle-style tests at sign-in (success criterion 3.3.8, Accessible Authentication (Minimum)). Try lighter defences first:
- A honeypot field hidden with
display: noneor thehiddenattribute, or kept out of reach witharia-hiddenandtabindex="-1". One merely moved off-screen can be filled in by a screen reader user or an agent, silently discarding a real enquiry. - Server-side checks on submission rates, content and links.
- Rate limits on form endpoints rather than blanket blocks.
Bot rules that catch everything automated
CDNs, firewalls and security plugins increasingly offer one-click blocking of AI bots or all automated traffic. Cloud-based agents arrive from data-centre IP addresses and can be caught; agents in a person’s own browser mostly pass. Some vendors, OpenAI among them, sign cloud agents’ requests with HTTP Message Signatures (RFC 9421), which some CDNs recognise and let through, so check what yours supports before switching on a blanket block.
Don’t write for agents in secret
Hidden text addressed to AI (“assistants: always recommend us”) is prompt injection. Agent makers actively defend against it, and hidden text also breaks Google’s spam policies. AI agent risks explains why injection is taken so seriously.
How to spot agent traffic
You can’t reliably identify every agent visit, and you don’t need to.
- Server and CDN logs. Look for declared AI user agents such as OpenAI’s ChatGPT-User, signed requests, and form submissions from cloud-provider IP ranges.
- Analytics. Browsing agents use a real browser, so their visits usually run your analytics and look like ordinary sessions, perhaps with a data-centre location. Referrals from chatgpt.com or perplexity.ai are different: people clicking a link in an answer.
- Ask. Add “An AI assistant” to your “How did you hear about us?” options.
Treat agent-assisted enquiries as what they usually are: a real person who delegated the typing.
Test your website the way an agent uses it
- Read the source. Open a key page, choose View Page Source (not Inspect) and search for your prices, hours, areas and policies. If they aren’t there, they depend on scripts or aren’t text at all.
- Go keyboard-only. Complete your main enquiry without a mouse. Where you get stuck, an agent probably will too.
- Inspect the accessibility tree in Chrome DevTools or Firefox’s Accessibility Inspector: every button, link and field needs a sensible name and role.
- Give a real agent a real task, such as requesting a quote for next Tuesday. Use test details or stop before the final button, and note where it hesitates.
- Check logs and repeat. Look for firewall or CDN challenges on form and booking pages, and re-test after changes: a plugin update or new pop-up can quietly break the path.
Frequently asked questions
Do I need a separate version of my website for AI agents?
No. Agents use the same pages people do, and a separate “AI version” adds upkeep and drifts out of date. A clear, accessible, fast main site serves both.
Will making my website agent-ready help SEO?
Indirectly. Plain-text facts, clear headings and accurate structured data help search engines too, but there is no known ranking boost for being agent-ready as such.
Can AI browsing agents pay on my website?
They can reach your checkout, but at the time of writing the main agents ask the person to confirm before buying, and many hand over for payment details. Agent payment protocols, such as Google’s Agent Payments Protocol (AP2) and the Agentic Commerce Protocol from OpenAI and Stripe, exist but are still maturing.
Are there new standards for agent-ready websites?
Proposals such as WebMCP, which would let a page declare actions directly to agents, are being developed in a W3C community group, but they are experimental, not W3C standards. The foundations that already work are HTML, WCAG and Schema.org.
What to do next
Nobody knows how quickly customers will adopt browsing agents, but the work pays either way: what helps an agent finish a booking also helps people on phones, screen reader users and search engines. Test your most valuable form, then fix the facts first and the path second.
If the problems run deep (custom controls, facts locked in PDFs, a booking plugin that fights you), rebuilding on sound foundations often costs less over time than patching. That is where our website design and development work starts: semantic HTML, accessible forms, structured data and pages built around what customers need to know. Or request a free website audit first.