Chrome’s auto browse scrolls and clicks through pages. ChatGPT Atlas fills in forms and completes purchases. Perplexity Comet researches across open tabs. Every major AI platform can now navigate a website on its own — but none of them sees your site the way a human visitor does, and building for the wrong model of “seeing” is why so many otherwise solid websites are becoming invisible to agents.

The 2025 Imperva Bad Bot Report found that automated traffic overtook human traffic for the first time in 2024, making up 51% of all web interactions. Not all of that is agentic browsing, but the trend line is unmistakable: the non-human audience for your website is already larger than the human one, and building for it is quickly becoming a core technical requirement, not an edge case.

Three ways agents actually read a page

When a person loads your site, they see color, layout, and typography. An agent sees something else entirely, and the major platforms don’t all see it the same way.

Vision-based agents take the most literal approach. Anthropic’s Computer Use captures a screenshot, reasons about what it shows, and decides what to click or type, then repeats the loop. Google’s Project Mariner works similarly with an “observe-plan-act” cycle, and posted an 83.5% success rate on the WebVoyager benchmark. The tradeoff is cost and fragility: reading pixels is expensive to compute and breaks easily when a layout shifts.

Structure-based agents skip the pixels entirely. ChatGPT Atlas, built on Chromium, queries the accessibility tree — the same structured data screen readers like VoiceOver and NVDA use — for elements with defined roles and names, rather than analyzing what’s rendered on screen. OpenAI’s own publisher guidance confirms Atlas interprets pages through ARIA labels and roles, and Microsoft’s Playwright MCP, the standard tool for browser automation, made the same choice deliberately, returning accessibility snapshots instead of screenshots.

Hybrid agents combine both. OpenAI’s Computer-Using Agent, which powers Operator and Atlas, layers screenshot analysis on top of DOM and accessibility tree parsing, prioritizing ARIA data and falling back to visual cues when structure is missing. Perplexity describes an identical approach for Comet, calling it “hybrid context management combining accessibility tree snapshots with selective vision” in its BrowseSafe safety paper.

Even vision-first platforms are adding accessibility data, and the platforms optimized for reliability lead with the tree by default — it isn’t a compliance checkbox anymore, it’s the primary interface most agents use to understand your site.

Why the accessibility tree matters more than the DOM

The accessibility tree is a stripped-down version of your page’s DOM, generated by the browser for assistive technology. Where a raw DOM might have thousands of divs, spans, and scripts, the tree keeps only what a user — or an agent — can actually act on: buttons, links, form fields, headings, and landmarks. For models working inside a limited context window, that reduction matters a lot.

A 2026 study from researchers at UC Berkeley and the University of Michigan, presented at the CHI conference on human-computer interaction, put numbers on this. Testing Claude Sonnet 4.5 on 60 real-world web tasks across 40.4 hours and more than 158,000 logged interaction events, the researchers found the agent completed tasks successfully close to 80% of the time under normal conditions. Restricted to keyboard-only navigation — simulating how a screen reader user browses — success fell to 42% and took twice as long. Restricted to a magnified viewport, success dropped further to 28%, taking more than three times as long.

The researchers grouped the failures into three buckets: perception gaps, where agents miss accessibility state changes that would tell them what just happened; cognitive gaps, where agents lose track of task state across multiple steps; and action gaps, where agents fail at interactions like drag-and-drop or underuse keyboard shortcuts. A page that leans on hover states, visual-only cues, or unlabeled JavaScript interactions is a page where agents are statistically likely to fail — and Perplexity’s own engineering documentation confirms its indexing system favors content that preserves clear structure, with pages “heavy on well-structured data in list or table form” getting more reliable parsing.

Semantic HTML does most of the work for free

The accessibility tree is generated from your HTML, so the fastest way to improve it is to use the elements the web platform already gives you. A native button element shows up in the tree automatically with the role “button” and its own text as the accessible name — no extra work required. A styled div with a click handler gets none of that for free.

A few fundamentals do most of the heavy lifting:

• Use native elements for their intended purpose — buttons for actions, anchors for navigation, select elements for dropdowns — instead of recreating their behavior with generic divs.
• Label every form field. Agents rely on labels to know what data a field expects, and the autocomplete attribute (using standard values like name, email, or street-address) is what lets an agent fill a form confidently instead of guessing.
• Keep a logical heading hierarchy. A single h1, followed by h2 through h6 in order with no skipped levels, gives agents a map of how your content is organized.
• Use landmark regions — nav, main, header, footer, aside — so an agent can tell at a glance where on the page it’s operating.

ARIA is a supplement, not a foundation

OpenAI recommends ARIA (Accessible Rich Internet Applications) for agent compatibility, and it’s genuinely useful — but only on top of solid HTML, not instead of it. The W3C’s own first rule of ARIA use is blunt: if a native element already has the behavior you need, use that instead of bolting an ARIA role onto something else. The fact that “don’t use ARIA” had to become rule one tells you how often it gets misapplied. Accessibility expert Adrian Roselli raised a pointed concern about this in an October 2025 critique of OpenAI’s guidance: recommending ARIA without enough context risks the misuse WebAIM’s annual survey of the top million websites already documents, where sites using ARIA tend to score less accessible, not more, because it’s applied as a patch over broken HTML rather than a genuine fix — including the risk of keyword-stuffed aria-label attributes, echoing the meta-keyword gaming of early SEO.

The correct order: start with semantic HTML, which works by default. Add ARIA only where native elements genuinely fall short, such as custom tab panels with no HTML equivalent. Use ARIA states like aria-expanded to communicate what changed when JavaScript updates the page, and keep aria-label text honest and descriptive rather than keyword-stuffed.

If it’s not in the HTML, it doesn’t exist for crawlers

Full browser agents like Atlas, Comet, and Chrome’s auto browse run on Chromium and execute JavaScript, so they can render a single-page application. But a large share of what visits your site isn’t a full browser agent — it’s a crawler. Bots like PerplexityBot, OAI-SearchBot, and ClaudeBot index content for citation, and many do not execute client-side JavaScript. If your page is a blank shell until React hydrates, these crawlers see nothing, and content that was never indexed can never be cited.

Server-side rendering, in other words, isn’t just a performance nicety anymore — it’s a visibility requirement. Even JavaScript-capable agents struggle with dynamic content that loads after an interaction or forms that rebuild themselves after every input, echoing the “cognitive gap” failures the CHI study documented. Keep pricing, specifications, and availability in the visible, initial HTML rather than behind an accordion or tab, and use real anchor links rather than JavaScript click handlers that never update the URL.

How to test what agents actually see

Screen reader testing is the closest practical proxy for agent testing, since both rely on the same accessibility tree. If VoiceOver, NVDA, or TalkBack can navigate your site’s key flows — finding buttons, reading form labels, following the content structure — an agent likely can too. For a more direct look, Microsoft’s Playwright MCP (published as @playwright/mcp) generates structured accessibility snapshots of any page, showing exactly the roles, names, and states an agent works with. Browserbase’s Stagehand, now in its third major version, parses both DOM and accessibility trees and is useful for testing whether an agent can complete a workflow like checkout. A quick, low-tech gut check is loading the page in the Lynx text browser, which strips out all visual rendering and shows roughly what a non-visual agent parses.

A prioritized checklist

For teams working through this incrementally, tackle it by impact versus effort. Start with the cheapest, highest-leverage fixes: native HTML elements for buttons, links, and dropdowns; labeled form inputs with autocomplete attributes; server-side rendered content pages. Next, invest moderate effort for still-high impact: landmark regions with distinguishing aria-labels where duplicated, a clean single-h1 heading hierarchy, and pricing or specs pulled out of hidden containers. Finally, round it out with lower-effort polish: ARIA states on dynamic components like menus and accordions, descriptive link text instead of “click here,” and screen reader testing folded into regular QA rather than treated as a one-time audit.

None of this is separate from the rest of your search strategy. The same structural work that helps agents navigate your site is what makes content easier to cite in AI answers, a topic covered in depth in our guide to getting your content into AI responses. It also connects directly to how machine-first architecture is reshaping site design, and to why AI Mode traffic behaves differently from a typical search visitor once it lands on your pages. Even your analytics setup needs a rethink here, since GA4’s AI assistant channel undercounts this traffic by default.

Frequently asked questions

Do I need to rebuild my site to be agent-friendly?

Usually not. Most of the highest-impact fixes — semantic HTML elements, form labels, heading hierarchy, server-side rendering — are incremental changes to existing templates rather than a full rebuild.

Is ARIA required for AI agents to understand my site?

No. Native, semantic HTML generates a usable accessibility tree automatically. ARIA fills gaps for custom components with no native HTML equivalent; it should never be the first tool you reach for.

Will a JavaScript-heavy single-page app work with AI agents?

Full browser agents that execute JavaScript can render it, but many AI crawlers used for indexing and citation cannot. Content that only appears after client-side rendering is invisible to a large share of the AI ecosystem.