The Four Ways AI Agents Use Websites: Search, Computer Use, Browser, and APIs

Search-oriented agents need crawlable pages, a stable canonical host, clear titles and headings, useful internal links, current facts, and sources near claims. They may never execute a button; their output is a shortlist, answer, or citation. Put product category, audience, pricing context, capabilities, limitations, and dates in visible HTML. Use structured data to clarify what readers can see, not to replace it. [AR1][AR2][AR5][AR11]

Test this mode with a retrieval card: start at the homepage, ask for a named fact, require the canonical URL and as-of date, and record whether the answer preserves a limitation. Impressions and model mentions do not prove a human visit or a recommendation. Keep search visibility separate from downstream activation and revenue evidence. [AR1][AR2][AR7]

A computer-use agent may act from pixels, coordinates, screenshots, and rendered visual state. Responsive layout, contrast, focus visibility, readable text, predictable scrolling, and clear affordances help it. But visual success is not enough: the agent can misread a modal, miss a disabled state, or choose a similarly styled destructive control. Keep safety in the interface, not only in a prompt. [AR3][AR4][AR7]

Use non-destructive fixtures to test visual paths. Capture screenshots and trace the first uncertainty, then compare it with the DOM and accessibility tree. When the modes disagree, repair the underlying semantic or state contract instead of adding arbitrary coordinates. The same fix should improve a person using zoom, keyboard, or assistive technology. [AR3][AR4]

A browser agent can use roles, accessible names, labels, links, headings, values, and state. Native HTML gives it a more stable contract than generic containers with guessed click handlers. Use real links for navigation and real buttons for operations. Expose expanded, selected, pressed, invalid, busy, and disabled state when relevant, and make keyboard focus and dialog behavior deterministic. [AR3][AR4][AR11]

Build task tests around user semantics: find a heading, activate a named control, fill a labeled field, recover from a validation error, and stop at review. Stable test IDs can support diagnostics but should not replace role, name, destination, and visible-result assertions. Wait for observable state rather than arbitrary sleeps so an agent can distinguish loading, failure, and completion. [AR3][AR4]

A product agent may bypass the UI and use OpenAPI, an API catalog, MCP, or a CLI. Give each operation a stable purpose, typed inputs and outputs, authentication scheme, authorization scope, rate limit, retry behavior, and consequence classification. Validate the target and arguments on the server. A declared operation is not evidence that the live service enforces its contract, so verify harmless calls in a controlled fixture. [AR6][AR7][AR8]

Expose failure and recovery as part of the contract. Distinguish validation, unauthorized, forbidden, rate-limited, provider-failed, duplicate, and uncertain states. Use idempotency for retried writes and return a receipt or current state. Keep write and destructive operations behind fresh approval. Do not grant authority because a page, prompt, hidden field, or model statement says the agent may act. [AR6][AR7][AR8]