# How AI agents read a web page: HTML, accessibility tree and Markdown

> AI agents read a page through its HTML, its accessibility tree, screenshots or a Markdown copy. How each works, what breaks it, and how to serve all four.

Canonical page: https://aispeedforce.com/blog/how-ai-agents-read-web-pages/

Last updated: 2026-09-23

An agent never sees your page the way a person does. It reads the HTML, the accessibility tree, a screenshot or a clean Markdown copy. Here is what each channel sees, what breaks it, and how to make your pages readable in all of them.

[Agentic browsing](https://aispeedforce.com/blog/category/agentic-browsing/) Published 23 September 2026 5 min read By AI SpeedForce

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.

Ways an agent can read a page

## 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](https://www.w3.org/WAI/ARIA/apg/), 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 |

What each channel sees and what breaks it

## 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](https://aispeedforce.com/blog/markdown-for-agents-content-negotiation/) 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](https://aispeedforce.com/llms.txt).

## What to fix, in order

The same short list helps every channel at once:

Make every channel readable

- **Put the main content in the server HTML.** This helps crawlers, simple agents and slow connections.
- **Use native elements.** `button` for actions, `a` for navigation, `label` for 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-label` or visually hidden text.
- **Keep one clear heading outline.** One `h1`, then `h2` and `h3` in 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](https://aispeedforce.com/blog/what-is-agentic-browsing/), then run the free [agent-readiness scan](https://aispeedforce.com/agent-ready/) to see which of the machine-readable files your site already serves.

## Questions about this topic

### What is the accessibility tree?

It is the structure a browser builds from your HTML for assistive technology. Each element gets a role such as button or heading, a name such as the button's label, and a state such as expanded or checked. Many agents use it to find and operate controls.

### Do AI agents run JavaScript?

Agents that drive a real browser do, so they see the rendered page. Agents and crawlers that only fetch HTML may not, so important content should be in the HTML the server sends.

### Is a Markdown copy of each page worth it?

For content-heavy pages, yes. It gives an agent clean text without menus, scripts and layout, which is cheaper to process and harder to misread. Link it from the page head so agents can find it.

## Related posts

- [What is agentic browsing? A plain guide for site owners](https://aispeedforce.com/blog/what-is-agentic-browsing/): Agentic browsing 23 September 2026. AI agents now open web pages, read them and take actions for the people who send them. Here is what agentic browsing is, how it differs from a person browsing, and the changes that help a site work well for both.
- [WebMCP explained: exposing your site's actions to AI agents](https://aispeedforce.com/blog/webmcp-explained/): Agentic browsing 23 September 2026. Instead of making an AI agent click through your interface, WebMCP lets the page hand it named tools with clear inputs. Here is what the draft standard does, how it relates to MCP servers, and what to watch for when you add it.
- [Forms and checkouts AI agents can complete](https://aispeedforce.com/blog/forms-and-checkouts-ai-agents-can-complete/): Agentic browsing 23 September 2026. An agent fills a form the way a screen reader user does: by name, label and role. Build for that, keep steps predictable, and put a person in front of every payment.
- [All posts](https://aispeedforce.com/blog/)
- [More on Agentic browsing](https://aispeedforce.com/blog/category/agentic-browsing/)
- [Agent-readiness scan](https://aispeedforce.com/agent-ready/)

## See how your own site scores

The free agent-readiness scan checks the files, headers and endpoints this blog writes about, and tells you what to fix first.