# AI Browser Agents Read the Live Page: What They See and Miss > Browser agents load your page and work from its accessibility information or a screenshot. What they can and can’t see, and how to test your site. URL: https://llmagnet.com/blog/what-ai-browser-agents-read Author: Ben Cohen, Founder & CEO at LLMagnet Published: 2026-08-30 Updated: 2026-11-10 Category: Guides AI browser agents read the live page: its accessibility information or a screenshot of it. If your prices, product details and buttons aren’t exposed clearly in those forms, an agent can miss them, so the fixes are mostly server-rendered content, semantic HTML and correct labels. The products keep changing. [OpenAI folded its Atlas browser into ChatGPT Work](https://www.theregister.com/a/5269818), with August 9, 2026 set as the date Atlas would stop working. [Claude in Chrome became generally available](https://claude.com/blog/claude-in-chrome-generally-available) on paid plans on August 26, 2026. [Google announced Gemini auto browse](https://techcrunch.com/2026/04/22/google-turns-chrome-into-an-ai-coworker-for-the-workplace/) for US Workspace users in April 2026. The way these tools read pages matters more than which one is on top this month. ## Contents 1. Search Mode and Agent Mode 2. What Agents See on Your Pages 3. What a Fix Looks Like 4. Why JavaScript-Heavy Sites Carry More Risk 5. What llms.txt Can and Can’t Do 6. MCP Endpoints 7. WebMCP: Tools a Page Can Offer Agents 8. What to Fix First 9. How to Test Your Site 10. Why This Is Worth Doing Now ## Search Mode and Agent Mode In search mode, an AI product answers from indexed or fetched text. Your levers are familiar: be crawlable, say things clearly, and earn mentions elsewhere. In agent mode, the software opens the page and works in it. It clicks links, fills in forms and moves between pages to complete a task. A page can be easy to index and still hard to use, for instance when a pop-up blocks the content or a menu has no label. ## What Agents See on Your Pages Vendors describe two main inputs, and they don’t all work the same way: **Page structure and accessibility information.** OpenAI’s publisher guidance, [as reported by Kickpoint](https://kickpoint.ca/chatgpt-atlas-browser-aria-tags-guide/), said Atlas used ARIA tags, the labels and roles that screen readers rely on, to interpret page structure. If a menu or button is a bare `
` with a click handler, there’s little for this approach to read. **Screenshots.** [Claude’s computer use tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/computer-use-tool) works from images of the screen, and can zoom in to read small text. Text inside an image can be read this way, but small text can lose detail when a screenshot is scaled down. Claude’s documentation also shows what makes this input hard. It recommends displays such as 1280x800 for web applications, says each screenshot costs roughly 1,000 to 1,800 input tokens, and warns that dropdowns and scrollbars can be tricky to operate with mouse movements. Every extra screen costs time and money, and a custom dropdown is a known weak spot. Some tools skip images altogether. [Playwright MCP](https://github.com/microsoft/playwright-mcp), a public browser automation server, reads “structured accessibility snapshots” by default and offers coordinate-based clicks only as an option for elements the snapshot doesn’t expose. It’s a useful example because you can run it and see exactly what such an agent receives. We found no vendor documentation saying browser agents use JSON-LD or an XML sitemap while working in a page. Don’t count on them for this. What an agent needs should be on the page. | On your page | First HTML response | Accessibility tree | Screenshot | | --- | --- | --- | --- | | **Server-rendered text** | Yes | Yes | Yes, once scrolled into view | | **Text added by JavaScript** | No | Yes, once rendered | Yes, once rendered | | **Text inside an image** | Alt text only | Alt text only | Yes, if legible | | **Icon button with no label** | Markup only | A button with no name | Visible, meaning guessed from the icon | | **Clickable `
`** | Markup only | Little or nothing | Visible, clicked by position | | **JSON-LD** | Yes | No | No | This table is our summary of how each input works, and individual products differ. The pattern is what matters: only server-rendered text with proper labels shows up correctly in every column. ## What a Fix Looks Like An add-to-cart button built from a styled `
` shows the problem: ```
...
``` There’s no role and no name here, so a tool reading the accessibility tree has nothing to identify. The fix is a native element with a label: ``` ``` Now the tree reports a button named “Add to cart”, and it works by keyboard without extra code. Missing names like this are common. In the [WebAIM Million](https://webaim.org/projects/million/) analysis of the top 1,000,000 home pages, 51% had form inputs with no label and 30.6% had buttons with no text. Across all failure types, 95.9% had detected failures, at an average of 56.1 errors per page. ![Share of the top 1,000,000 home pages with each detected failure in February 2026: low contrast text 83.9 percent, missing image alt text 53.1, missing form input labels 51, empty links 46.3, empty buttons 30.6, missing document language 13.5.](https://llmagnet.com/images/blog/charts/agentread-webaim.png) *Source: WebAIM Million, February 2026. Automated scans of home pages only.* In our reading, the three highlighted failures are the ones most likely to stop software, because each leaves a control with no name. WebAIM measures accessibility and not agent success, so treat this as a sign of how common the problem is. We found no study that links these failures to agent task completion. ## Why JavaScript-Heavy Sites Carry More Risk Browser agents can run JavaScript, so a client-rendered site isn’t automatically invisible to them. The risk is in timing and interaction. Content that loads on scroll, appears after a delay, or sits behind a custom modal may not be there when the agent looks. Crawlers that don’t run JavaScript have it worse, since they only get the first HTML response. Server-side rendering removes most of this risk. Put your pricing, feature explanations and contact details in the HTML of the first response. ## What llms.txt Can and Can’t Do [llms.txt](https://llmstxt.org/) is a proposed markdown file that gives a short summary of a site and links to key pages. An agent can use it as a map. It has no allow, block or per-crawler rules, so it can’t control access. That job stays with robots.txt. `llms-full.txt` is a common add-on holding full text, and isn’t described on the proposal’s main page. Keep your expectations low. [SE Ranking’s study of about 300,000 domains](https://seranking.com/blog/llms-txt/) found no measurable link to citations. In [Ahrefs’ May 2026 log study](https://ahrefs.com/blog/llmstxt-study/), about 97% of the files received no requests that month. The AI bots that did fetch them included coding agents such as Claude Code, so the case is strongest for developer documentation. ## MCP Endpoints The Model Context Protocol lets an AI application call defined tools, such as a search of your catalog. [Anthropic reported](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) more than 10,000 active public MCP servers in December 2025, with support in products including ChatGPT, Cursor, Gemini and Microsoft Copilot. A server only helps once a user or platform connects to it, so most sites can start elsewhere. Make sure key data such as pricing, feature lists and contact details is in plain HTML first. Build an MCP server when customers or partners would connect to it. ## WebMCP: Tools a Page Can Offer Agents [WebMCP](https://webmachinelearning.github.io/webmcp/) lets a web page offer JavaScript-based tools to AI agents through a `modelContext` object on the document. It’s published by the W3C Web Machine Learning Community Group as a draft report, and it says clearly that it isn’t a W3C Standard or on the standards track. Expect it to change. The November 9, 2026 draft has a page call `document.modelContext.registerTool()` with a name, a description, an input schema and an `execute` callback. Its security section lists prompt injection and over-collection of private data among the risks. Most teams should watch it and do the basics now: use `