There is a version of your website that you have probably never looked at, and it is the version a growing share of your visitors actually read. It is not the rendered page. It is the accessibility tree — a structured summary the browser builds from your HTML for screen readers, and now for AI agents.

I spend most of my time testing web applications, so I look at pages the way a machine does more often than the way a person does. This one is worth your attention even if you never touch security, because it changes who your audience is.

The short version

When a browser loads your page it builds two things. One is the visual layout you see. The other is the accessibility tree: a parallel, simplified structure that exposes the meaning of the page — which parts are headings, which are buttons, which are links, and what each one is called. Assistive technology has used this tree for about twenty years.

AI agents now read it too. Google’s own developer guidance, Build agent-friendly websites, says agents perceive a page in three ways: screenshots, the raw HTML, and the accessibility tree. The tree is the one they lean on for structure, because it strips away the visual noise and leaves the semantics. If your content only exists as unlabeled <div> soup, or only appears after JavaScript runs, the tree has nothing useful to show — and the agent sees a page that is, functionally, blank.

This is not a small or future audience. Cloudflare measured that automated traffic passed human traffic to web pages for the first time in early June 2026, at roughly 57% of requests to HTML content. The machines are now the majority reader. Building for the accessibility tree is no longer a favour to a minority; it is building for most of your traffic.

Check your own site in 30 seconds

You can look at your accessibility tree right now, no tools to install:

  1. Open the page in Chrome. Right-click anywhere and choose Inspect.
  2. In DevTools, open the Accessibility pane (it may be under the » overflow menu).
  3. Turn on “Enable full-page accessibility tree”, then click the icon to switch the Elements view into tree view.
  4. Scroll through it. Can you read all of your real content as headings and text nodes, in a sensible order?

If large chunks of your content are missing from that tree, that is your problem statement. A human sees the page; an agent sees the gap.

What actually fixes it

The fixes are not exotic. They are the same things that make a site accessible to a person using a screen reader — which is the whole point.

  • Use semantic HTML, always. Real <button>, <a>, <nav>, <main>, <header>, <article>, <ul>/<li>. This is the thing that builds a useful tree. A <div> with a click handler builds nothing.
  • Get your headings right. One <h1> for the page topic, then <h2> and <h3> in order with no skipped levels. Agents read the heading outline the way you skim subheadings to understand a document.
  • Render your real content on the server. If the meaningful text only appears after JavaScript executes, many agents and crawlers never see it. Static generation or server-side rendering puts the content in the initial HTML where it can be read.
  • Label everything interactive. Every input gets a <label>. Icon-only buttons get an aria-label or visible text. Links say what they do — “Read the report”, not “click here”.
  • Write real alt text for images that carry meaning, and alt="" for purely decorative ones so they are skipped.

The trap: don’t reach for ARIA first

The most common mistake is to sprinkle ARIA attributes on broken markup to “make it accessible.” It usually makes things worse. The 2026 WebAIM Million report found that home pages using ARIA averaged 59 detectable errors, versus 42 on pages without it. ARIA is a way people wallpaper over inaccessible custom components, and the wallpaper causes harm.

The first rule of ARIA is: don’t use ARIA. Use the native element that already has the role built in. Reach for ARIA only when no native element can do the job.

Two extra signals worth adding

Once the fundamentals are in place, two low-cost additions help agents specifically:

  • An llms.txt file at your site root — an emerging convention that tells agents, in plain language, what your site is and where the important pages are.
  • Valid structured data (schema.org / JSON-LD) describing who or what the page is about — a person, an article, a product. Agents and search engines both consume it.

The one line to remember

If a screen reader cannot get your content out of the accessibility tree, neither can an AI agent — and increasingly, neither can most of your traffic. Build the tree on purpose, not by accident. The good news is that there is no separate “AI SEO” checklist here: doing right by people using assistive technology is the same work as being readable to the machines. One tree, one set of rules.

This started from a 43-second clip by Darren Shaw pointing at Google’s guidance; the figures above are the current 2026 numbers, checked against the original sources.