Your website has a third audience now — agents

Questions this guide answers

• How do I make my website agent-friendly?
• What is an agent-friendly UI?
• How do AI agents read websites?
• What does Google say about agent-friendly websites?

Direct answer

Your product UI now serves three audiences. The first is humans — the users you've been designing for since you started. The second is search crawlers — the audience SEO has trained product and engineering teams to accommodate for two decades. The third, new in 2026, is agents: AI systems that operate websites on a user's behalf, summarize what they see, or call into your application through MCP and similar protocols.

Agent-friendly UX is not a new design discipline. It's the same accessibility and clarity practices that benefit screen-reader users, with one extra dimension: agents that work by screenshot rather than DOM see what's visually rendered; agents that work by accessibility tree see structural intent; agents that work by DOM see what's structurally present. The three views diverge in ways your human users never see, and that divergence is where agent UX breaks.

The three views agents read your UI through

Different agents read your UI different ways. Today's production agents tend to use one of three approaches, often in combination.

The five rules that move the needle

Google's web.dev guidance on building agent-friendly websites is straightforward: agent UX is accessibility and UX, applied with discipline. The five rules below capture most of the practical value. They are not new rules; they are the rules accessibility teams have been asking for since the W3C ARIA spec was published. Agents are the new constituency that makes the rules procurement-relevant.

• Use real semantic HTML for interactive elements. Buttons should be `<button>` tags, links should be `<a>` tags, and inputs should have associated labels. A clickable `<div>` with an `onclick` handler may look right visually but carries no semantic role information — and will fail across all three agent views.
• Give every interactive element an accessible name. The visible label is often enough; when it's not (icon-only buttons, ambiguous controls), an `aria-label` or `aria-labelledby` carries the intent. "Submit" beats "Click here"; both beat an icon with no text.
• Make state visible in the DOM, not just in CSS. If a button is disabled, use `disabled` or `aria-disabled`; if a toggle is on, use `aria-pressed` or the equivalent. State that lives only in CSS class names is invisible to agents that read the DOM or accessibility tree.
• Keep layout stable after first paint. Layout shift moves agent targets between the time the agent identifies them and the time it tries to click them, and the agent fails. The Core Web Vitals metric CLS (Cumulative Layout Shift) was designed for humans, but it captures the same failure mode.
• Surface operations as visible affordances, not as hidden gestures. If an important action only happens on right-click or on a multi-touch gesture, agents that don't simulate those won't find it. Provide an explicit button or menu entry as the primary path; gestures can be a shortcut.

The anti-patterns that quietly break agent UX

Three patterns are common in modern B2B SaaS UIs that look fine to human users and quietly fail to agents.

A one-week audit you can run

Five days, one rule per day, applied to the three highest-traffic flows in your product. End of week, you have an inventory of where agent UX fails and a prioritized list of fixes.

• Day 1: Walk every clickable element in the priority flows. Inventory any rendered as a `<div>` instead of a `<button>` or an `<a>`. Replace.
• Day 2: For every input field, confirm a visible or aria-associated label. For every button, confirm an accessible name. Fix gaps.
• Day 3: For every stateful component (toggle, tab, selected row, disabled button), confirm DOM-visible state. Replace CSS-only state.
• Day 4: Run the priority flows in a low-bandwidth Chrome window and watch for layout shift. Pin elements that shift.
• Day 5: Audit hover-only and gesture-only interactions. Add visible alternatives for any operation that's currently gesture-only.

What you don't have to do

A few things tend to come up in agent-readiness conversations that you can safely skip. Google's May 2026 guide is explicit: there's no agent-specific schema, no special markup file, no agent-friendly content variant. The accessibility and clarity work above is what agents need. "Build a separate agent UI" is a category error.

Similarly, you don't need to rewrite content for agents. Agents read your product UI; the user's request flows through them. The content quality bar is the same one your human users hold you to.

Why this matters now

Agentic AI is moving from research demos to production in 2026. Anthropic's Claude operates browsers; OpenAI's Operator agent is generally available; the Apps SDK shipped; Google's Gemini agent capability has its own footprint. The number of times your product is operated by an agent on a user's behalf has gone from approximately zero in 2024 to a measurable share in mid-2026, and is growing.

If you wait until the share is large to start, you will have a backlog of work to fix and customers who already churned because their agent couldn't operate your product. The rules above are not expensive to apply early; they are expensive to retrofit later.

About the author

Eason Wang is Co-Founder & CPO of SolCrys, the AEO operating system for brands and agencies competing for visibility, citations, and recommendations across the major AI engines. PhD in Machine Learning. Eighteen-plus years building enterprise products; started at Microsoft Research Asia. Current focus: agentic AI workflows in production. Connect on LinkedIn.

Written May 2026 after a product review where SolCrys's own UI failed agent UX in a way our human users had never noticed. The rules above are the ones we run our product reviews against now.

FAQ

Related guides