As an indie developer I maintain my sites alone, so I recently handed routine smoke-testing of one of them to Antigravity's Browser Subagent, and it stumbled over things no human visitor would even notice. It couldn't find the theme toggle. It missed a payment confirmation toast and reported that it "could not verify the result." On an infinite-scroll list, it concluded that an article which definitely existed was "not found." I wrote that frontend myself, and yet from an agent's point of view, large parts of it were simply unreadable.
This is no longer a niche concern. At I/O 26, Chrome announced fifteen updates under its agentic web initiative (rolling out via Chrome for Developers), and designing for browsers operated by agents is becoming a practical requirement. In this article I'll share the concrete failures I found on my own site, how I fixed them, and the checklist I extracted from the process.
Agents Read Structure, Not Pixels
The first thing that clicked while watching the Browser Subagent work was that it relies on the accessibility tree and DOM structure far more than on visual appearance. Screenshots are used as a supplement, but target identification fundamentally depends on elements that expose a role and a name.
In other words, a site that is hard to use with a screen reader is almost exactly as hard for an agent. The encouraging flip side: most of what we already know as accessibility work doubles as agentic web readiness. My current rule of thumb is that human UX and agent UX overlap about ninety percent, and the remaining ten percent is making application state machine-readable.
My observation workflow is the same one I described in Why Antigravity's Browser Sub-Agent Mistakes SPAs for Blank Pages and How to Fix the Waiting Strategy: compare the agent's action log against what you see with your own eyes.
Three Real Failures and How I Fixed Them
Icon-Only Buttons Are Blind Spots
The most frequent failure involved icon-only buttons. A theme toggle showing nothing but a moon icon is, to an agent, just a nameless button element.
// Before: the agent sees an anonymous button
<button onClick={toggleTheme}>
<MoonIcon />
</button>
// After: give it a name and a state
<button
onClick={toggleTheme}
aria-label="Switch to dark mode"
aria-pressed={isDark}
>
<MoonIcon aria-hidden="true" />
</button>Adding aria-label (what the button does) and aria-pressed (which state it is in) was enough for the agent to reliably find the button and verify the outcome of pressing it. After this change, the success rate on the same task felt like a different product.
Vanishing Toasts Disappear Before They're Read
Communicating payment or copy success only through a toast that fades after three seconds also turned out to be hostile to agents. An agent's observation cycle can be slower than a human's glance, and the message is gone from the DOM before it gets read.
I moved to a two-layer approach: keep the transient toast, but also reflect the result in a persistent element with role="status".
// Write the result somewhere that stays, not just in a toast
<p role="status" data-state={purchaseState}>
{purchaseState === "completed" ? "Your purchase is complete" : ""}
</p>role="status" is a live region designed for screen readers, but it works equally well as the place an agent goes to confirm what happened.
Infinite Scroll Needs an Alternate Route to Everything
For the infinite-scroll failure, the reliable fix wasn't forcing the agent to scroll repeatedly — it was providing an alternate route: a paginated archive and a search page. My site already had a full article index and category pages, so simply making those links explicit in the footer solved it. Conveniently, this structure is also long-standing SEO practice for crawl efficiency.
The Checklist — A Minimal Set for Agent-Ready Pages
Here is what I now verify whenever I build a new screen.
- Every interactive element has a role plus an accessible name (
aria-labelon icon buttons; no "click here" link text) - State is exposed through attributes (
aria-pressed/aria-expanded/aria-checked, withdata-statefor custom states) - Every form input is paired with a
nameand alabel - Operation results are written to a persistent
role="status"element, not only to toasts - Never rely on infinite scroll alone — provide pagination or search as an alternate route
- Never serve an empty
mainwhile JavaScript renders; show an explicit loading indicator
That last item is a general SPA pitfall and shares its root cause with flaky E2E tests. The selector discipline (adding data-testid) I covered in Automating E2E Tests with Antigravity's Browser Sub-Agent pays off directly here as well.
This Is Not About Welcoming Every Bot
A natural worry is that agent-friendliness also makes life easier for scrapers. I treat operability and access control as separate layers. Rate limiting, authentication, and robots.txt policy stay exactly as they were; what changes is that any visitor who legitimately reaches a page — human or agent — gets a structurally readable screen. For verification, Chrome DevTools now ships agent-oriented tooling too, which I summarized in Chrome DevTools for Agents 1.0 Goes Stable — What Changes Now That It Ships with Antigravity 2.0.
Agent-driven visits are still a small share of traffic, but given the direction set at I/O 26, that share will only move one way. Start by letting a Browser Subagent walk through your site's most important flow — subscription, purchase, or contact — and watch where it gets stuck. You'll have a concrete fix list faster than you expect.