AI agents read a web page through one or more of four channels: the HTML your server sends, the page as rendered after scripts run, the browser's accessibility tree, and a screenshot. Many will also use a clean Markdown copy if you offer one. Each channel sees something different, and each breaks in its own way.
Knowing which is which explains most of the problems agents have with real sites, and why the fixes are usually the same ones that help people using screen readers.
Channel one: the raw HTML
The simplest agents and most crawlers fetch the page and read the HTML the server returns, without running any JavaScript. What they get is exactly what your server sent: headings, paragraphs, links and whatever else is in the markup.
This channel breaks when the content only appears after scripts run. A page that ships an empty container and fills it in the browser looks blank here. The fix is server-side or static rendering for anything that matters: product details, prices, policies and the main text of every page. This is also long-standing SEO advice, because search crawlers face the same limitation on a first pass.
Channel two: the rendered page
Agents that drive a real browser load the page, run its scripts and read the resulting document object model (DOM). They see what a person's browser sees, including content added by JavaScript.
They still have limits. Content that loads only when you scroll, appears after a long delay, or sits behind a click the agent does not think to make may never be read. An agent working to a budget will not scroll forever. Put the essential content in the initial page, and make secondary content reachable through plain links.
Channel three: the accessibility tree
Browsers build an accessibility tree from your HTML so that screen readers and other assistive technology can use the page. Each element gets a role (button, link, heading, textbox), a name (the visible label or its equivalent) and a state (checked, expanded, disabled). Many agents use this tree to find and operate controls, because it describes what things are rather than how they look.
This is where most agent failures start. A clickable div has no button role. An icon button with no text or label has no name. A form field with a placeholder but no label is announced as an unnamed textbox. A person can work around all three by looking. An agent reading the tree often cannot. The standard guidance is in the ARIA Authoring Practices, and the first rule is to use native HTML elements before reaching for ARIA.
| Channel | What it sees | What breaks it |
|---|---|---|
| Raw HTML | The markup your server sends | Content that only appears after scripts run |
| Rendered DOM | The page after scripts run | Content loaded late or only on scroll |
| Accessibility tree | Roles, names and states of each element | Unlabeled buttons, divs used as buttons |
| Screenshot | Pixels, like a person | Low contrast, overlays, text in images |
| Markdown copy | Clean headings, text and links | Not offered, or out of date |
Channel four: screenshots
Some agents take screenshots and use a vision model to interpret the page, sometimes alongside the accessibility tree. This channel sees roughly what a person sees, so visual problems become agent problems: low-contrast text, cookie banners covering the content, pop-ups, carousels that move mid-read, and information carried only by color.
Screenshots are also expensive for the agent to process, so many prefer the text channels when they work. A page that reads well as text is cheaper and more reliable for an agent to use, which makes it more likely to be used.
One page, several readers at once
These channels are not alternatives you choose between. The same visit may involve a fetch of the raw HTML to decide whether the page is relevant, a browser render to read it properly, the accessibility tree to find the form, and a screenshot to check the result. A page that is consistent across all of them, with the same text, the same headings and the same controls, is the page an agent can rely on. Pages that show different content to different readers, or hide the important parts from some of them, are the ones that produce wrong answers.
The shortcut: a Markdown copy
You can skip most of the guessing by giving agents a clean text version of each page. A Markdown copy keeps the headings, text, lists, tables and links, and leaves out navigation, scripts and layout. Agents can find it in two standard ways: a <link rel="alternate" type="text/markdown"> tag in the page head, or content negotiation, where a request that sends Accept: text/markdown gets Markdown instead of HTML. Our guide to Markdown for agents covers both.
A site-wide llms.txt file adds a map on top: a short Markdown index of the site that points to the most useful pages. This site publishes one at /llms.txt.
What to fix, in order
The same short list helps every channel at once:
- Put the main content in the server HTML. This helps crawlers, simple agents and slow connections.
- Use native elements.
buttonfor actions,afor navigation,labelfor every field. They come with the right role and behavior for free. - Name every control. Icon-only buttons need an accessible name, for example through
aria-labelor visually hidden text. - Keep one clear heading outline. One
h1, thenh2andh3in order. Agents use headings to jump to the part of the page they need. - Keep text as text. Prices, dates and policies inside images are invisible to three of the four channels.
- Remove blockers. Overlays, forced pop-ups and layout that shifts after load cause agents to misclick or stop.
- Publish the Markdown copy and llms.txt. These are small additions with a large effect on content-heavy sites.
You can test the accessibility side yourself with the accessibility panel in your browser's developer tools, or with an automated audit such as Lighthouse, which reports missing names, labels and contrast problems.
Next step
For a wider view, read what agentic browsing is, then run the free agent-readiness scan to see which of the machine-readable files your site already serves.