ChatGPT Work launched on July 9, 2026. ChatGPT’s Atlas browser was sunsetted on August 9, the same day it turned ten months old. Claude for Chrome is generally available. Gemini auto-browse is live for Workspace users in the US.
The AI browser agent is no longer an experiment. It is a mainstream channel — and it works differently from every search-augmented LLM you’ve been optimizing for.
Search-mode AI (Perplexity, Google AI Overviews, ChatGPT without browsing) works by querying an index and synthesizing retrieved text. Agent-mode AI operates a real browser: it loads your page, observes the visual output or accessibility tree, reasons about what it’s looking at, and decides whether your content is usable for the task it was given.
LLM-referred traffic converts at 15.9% from ChatGPT and 10.5% from Perplexity, compared to 1.76% for organic search. The gap between “your site is accessible to agents” and “your site is invisible to agents” is increasingly a revenue gap. This post is about what those agents can and can’t read — and what to do about it.
The Difference Between Search Mode and Agent Mode
When Perplexity or Google AI Overviews cite your content, they are pulling from a cached index. The crawler visited your page, stored a text representation, and the LLM retrieves that representation at query time. Your optimization levers are: get crawled, have structured content, use the right schema, build authority signals.
When ChatGPT Work or Claude for Chrome visits your site, the process is different. The agent loads a live browser session. It observes the page — either through rendered screenshots or by reading the accessibility tree (the DOM subset that screen readers and assistive tools use). It acts: clicking links, filling forms, scrolling, navigating to subpages. The optimization levers are completely different.
An agent visiting your product page to complete a research task doesn’t care about your JSON-LD schema. It cares whether it can read your pricing, understand what you offer, and navigate to the relevant section without getting trapped in a JavaScript modal that blocks the accessibility tree.
What Agentic AI Actually “Sees” on Your Pages
AI browser agents primarily operate on two representations of a web page:
The accessibility tree: A structured representation of interactive elements — headings, links, buttons, form fields, landmark regions — derived from the DOM. This is what screen readers use, and it’s what most agents use when they need to navigate rather than just read. If your navigation is built with custom JavaScript components that don’t emit proper ARIA roles, agents frequently can’t find them.
Screenshots: Some agents — including Claude Computer Use — take visual screenshots and reason about the interface from the image. This approach is slower and less precise, but it catches visual elements that the accessibility tree misses. It also means that text baked into images (pricing graphics, screenshot-heavy documentation) is readable, but harder to act on.
What agents generally do not use for navigation: your JSON-LD structured data, your XML sitemap, your meta tags. Those signals matter for search-mode indexing. For agent-mode browsing, what matters is whether the rendered page is navigable by a system reading the accessibility tree or looking at a screenshot.
Why JavaScript-Heavy Sites Have a Structural Disadvantage
Single-page applications and JavaScript-rendered content create a specific problem for AI agents: the initial HTML shell contains almost nothing, and the meaningful content only appears after JavaScript executes.
For search-mode crawlers, this was solved (partially) by Googlebot’s two-wave rendering process. For AI agents, it’s a live execution environment — they can wait for JavaScript to render. But complex client-side routing, lazy-loaded components, and JavaScript-gated content introduce unpredictability. An agent navigating a React SPA may load the shell, fail to find the content it needs in the accessibility tree before its timeout, and classify the page as uninformative.
The practical implication: if your most valuable content — pricing, feature explanations, case studies — lives behind JavaScript rendering or is loaded on scroll, agents are more likely to miss it. Server-side rendering and static HTML generation aren’t just performance improvements; they are agent-accessibility improvements.
Concrete test: load your most important pages with JavaScript disabled. If the key content and navigation don’t appear in that view, an agent operating primarily from the accessibility tree may not find it reliably.
How llms.txt and llms-full.txt Help Agents Navigate
Current adoption of llms.txt across tech and documentation sites is estimated between 5 and 15%. That means the signal is still rare enough to be meaningful — sites that implement it correctly are sending a clear signal to AI systems about what they should read and use.
llms.txt functions as a navigation guide for AI systems: here are the sections worth reading, here’s what’s off-limits, here’s how my content is organized. For search-mode AI, this shapes what gets indexed. For agent-mode AI, a well-structured llms.txt helps the agent skip unnecessary crawling and go directly to the content relevant to its task.
llms-full.txt is the less-discussed complement. Where llms.txt is a structured index, llms-full.txt is a complete plain-text export of your most important content — documentation, key articles, product explanations — formatted for direct LLM ingestion. For documentation sites and knowledge bases, this file lets AI agents get the full content of your site in a single request, without navigating the DOM at all.
Implementation guidance that most llms.txt posts skip: sync your llms.txt with your robots.txt. If robots.txt allows a crawler but llms.txt blocks it, or vice versa, the contradiction degrades trust in both files. Resolve conflicts deliberately: if you have content you want search crawlers to index but don’t want AI systems to train on, you need to handle that at the llms.txt level with explicit per-crawler directives, not through a blanket block.
MCP Endpoints: Letting Agents Query Your Content Directly
The Model Context Protocol (MCP) represents a structural shift in how AI agents consume website data. Rather than scraping HTML or reading an accessibility tree, an agent can connect to an MCP endpoint and query your content programmatically — asking for specific products, documentation sections, or data points in a structured format.
For e-commerce and SaaS sites, an MCP endpoint means an agent comparing five vendors can pull your pricing, features, and documentation directly without interpreting your page layout. That’s a significant advantage over competitors whose data the agent has to extract from HTML.
WordPress now has multiple MCP server plugins available (Agent Abilities for MCP, among others visible in WP plugin search results). These are early implementations, but the trajectory is clear: sites that expose structured MCP endpoints will be easier for agents to query than sites that only serve HTML.
The immediate action for most sites isn’t a full MCP implementation — it’s making sure your key data (pricing, feature lists, contact information, core product claims) is available in plain HTML that agents can read, not locked inside JavaScript components, PDFs, or image-based layouts.
WebMCP Attributes: The New Layer for Agent Navigation
WebMCP is an emerging standard — currently implemented by projects like OpenHermit — that adds W3C-style attributes to existing HTML elements to help AI agents understand the structure and purpose of page components. Instead of an agent having to reason about whether a div is a product card or a navigation element, WebMCP attributes label them explicitly.
The standard is early, and broad adoption isn’t here yet. But it follows the same trajectory as schema markup: the sites that implemented schema.org structured data before it was mainstream got years of advantage in rich search results. WebMCP attributes are likely to follow a similar pattern as agent-mode browsing becomes the dominant AI interaction model.
At minimum, the principle behind WebMCP is immediately actionable without the spec: use semantic HTML correctly. Landmark elements (<nav>, <main>, <article>, <aside>), proper heading hierarchy, descriptive aria-label attributes on interactive elements, and explicit role attributes on custom components. These aren’t new — they’re accessibility best practices that also happen to be agent-legibility best practices.
Testing Whether Your Site Is Agent-Accessible
You don’t need an AI agent to test agent-accessibility. You need three checks:
Check 1 — Accessibility tree audit: Run your key pages through an accessibility tree viewer (Chrome DevTools → Accessibility panel, or axe-core). Verify that your main content, navigation, and interactive elements are represented in the tree with clear roles and labels. If an element exists visually but not in the accessibility tree, agents operating from the tree won’t see it.
Check 2 — JavaScript-off test: Disable JavaScript and load your most important pages. What content survives? Your product value proposition, pricing, and primary CTAs should all be visible in server-rendered HTML. If they only appear after JavaScript executes, you have a structural agent-accessibility gap.
Check 3 — llms.txt validation: If you have a llms.txt, check for three common errors: blocking sections that contain your core product or service content, failing to list your most important pages explicitly, and contradictions with robots.txt. The file should function as a curated reading list for AI systems — if it’s a default-generated block list, it’s probably doing more harm than good.
A fourth check for more technical teams: run your pages through a headless browser using Playwright or Puppeteer with JavaScript disabled, and verify that the text content an agent would read matches the content you want it to read. This is roughly what accessibility-tree-based agents experience on your first render.
The Conversion Argument for Prioritizing This Now
The practical business case for agent-accessibility isn’t abstract. LLM-referred visitors from ChatGPT convert at 15.9%. Organic search converts at 1.76%. The channel that requires your site to be agent-readable is already converting at roughly 9x the rate of the channel you’ve been optimizing for years.
Agent-mode AI is accelerating. ChatGPT Work is designed for multi-hour research and comparison tasks. Claude for Chrome is running in the same browser your customers use. Gemini auto-browse is completing tasks in the background for Workspace users. These agents are not visiting your site to read it — they’re visiting to complete a task, and they’re reporting back to users who are often close to a purchase decision.
If your site is navigable by a screen reader and your content is visible in server-rendered HTML, you’re most of the way there. The gap between “technically accessible” and “strategically optimized” is filled by llms.txt, semantic structure, and — for teams with development resources — MCP endpoints.
The sites that treat agent-accessibility as a distinct optimization track from traditional SEO are building an advantage that compounds as agent usage grows. The ones treating it as a future problem are watching that window close.
Conclusion
AI browser agents operate differently from search-mode AI: they load live pages, navigate accessibility trees, and complete tasks rather than retrieving indexed text. The optimizations that work for Perplexity citations don’t automatically work for ChatGPT Work visibility.
The core checklist: verify your content is visible in server-rendered HTML, audit your accessibility tree for completeness, implement a genuine llms.txt that guides rather than blocks, and add llms-full.txt if you run a documentation or content-heavy site. For teams ready to go further, MCP endpoints and WebMCP attributes represent the next layer.
Want to see how your site scores on AI visibility signals — including agent-readiness indicators, schema implementation, and authority factors? The AI Visibility Analyzer audits your pages against the signals that matter for both search-mode and agent-mode AI systems. It takes 30 seconds and gives you a prioritized action list.