The visitor is also an AI.

Three kinds of non-human visitors

Bots are nothing new on the web. What is changing is their diversity and their role. Three families can be distinguished today.

Training crawlers collect content to build model datasets. GPTBot, at OpenAI, is one example, and it can be blocked via the robots.txt file. Search crawlers feed the indexes that assistants query to answer in real time, such as OAI-SearchBot for ChatGPT. Blocking them means disappearing from those answers. Finally, agents act on behalf of a specific person, during their session: they consult a page, compare offers, fill in a form.

This third family is the most recent. OpenAI launched its ChatGPT Atlas browser in October 2025, with an agent mode. Perplexity offers Comet. Google is building agentic capabilities into Chrome and into AI Mode, which can already make certain bookings for the user in a few countries. These tools remain imperfect and are often presented as experimental. The direction is nonetheless clear: part of the interactions with a website will be delegated.

How an agent reads a page

An agent has three ways of understanding a page: analysing a screenshot, traversing the DOM, or querying the accessibility tree. The latter is the simplified representation the browser builds for assistive technologies, such as screen readers. It reduces a page of several thousand elements to what matters for interaction: headings, links, buttons, fields, navigation regions.

The vendors say so openly. OpenAI states that the Atlas agent relies on ARIA roles and labels to interpret structure and interactive elements, and recommends following WAI-ARIA best practice. Microsoft chose to provide accessibility snapshots rather than screenshots in Playwright MCP, its browser automation server. Most agents combine several approaches.

One nuance matters. Accessibility specialists point out that ARIA must remain a complement. A properly used native HTML element, a real button, a real link, a label associated with its field, automatically produces correct information in the accessibility tree. Adding ARIA attributes to a badly built structure often creates more problems than it solves. For an agent as for a screen reader, semantic HTML remains the best foundation.

From reading to action: WebMCP

Reading a page is not enough to act reliably. An agent that has to book an appointment or send a request still guesses where to click and what to type. It fails as soon as a label changes or a modal window appears.

WebMCP offers another route. Announced in preview by the Chrome team in February 2026, this standard in the making, backed by Google and Microsoft within a W3C community group, lets a website explicitly declare actions, with their parameters, through a browser interface (navigator.modelContext). The agent no longer interprets the interface, it calls a function described by the site. Despite its name, WebMCP differs from the Model Context Protocol (MCP): it runs in the browser tab, within the user’s session, and not on a server.

The project is young. First available behind an experimental flag in Chrome Canary, it was presented at the Google I/O 2026 conference with a trial programme. The position of other browsers remains to be seen. In e-commerce, Google is pushing in parallel the Universal Commerce Protocol (UCP), co-developed with Shopify, to let its agents complete purchases.

In May 2026, Google also added a section on agentic experiences to its official documentation for site owners. It presents it as an avenue to explore when relevant to the business, not as an emergency. That is a reasonable reading.

What this changes for a corporate website

For most organisations, the immediate challenge is not to implement WebMCP. It is to make sure that important journeys remain usable when it is not a person going through them.

Contact, quote request, sign-up or booking forms come first. Properly labelled fields, explicit error messages, named buttons, predictable steps: everything that makes a form robust for a human also makes it usable by an agent. Conversely, a click captured on a plain div element, validation that displays nothing or content loaded only after interaction complicate the task for both.

Bot management also calls for an explicit policy. Blocking all agents indiscriminately protects content, but can make a service invisible in assistants or unusable for customers who delegate. Anti-bot protections and CAPTCHAs must be weighed accordingly, journey by journey.

Measurement is changing too. An agent consulting a page on behalf of a user does not behave like a human visitor. Server logs, referrers and segmentation in the analytics tool make it possible to start telling these visits apart.

What can wait, and what should not

Implementing protocols still in preview can wait, except for an e-commerce or booking player that wants to experiment early.

The rest should not wait: clean semantic HTML, accessible forms, content readable without complex execution, a robots.txt policy that is decided rather than endured, and a first measurement of visits coming from assistants. These projects are useful today for people and search engines. They also prepare the ground for agents, whichever standard prevails.

Frequently asked questions

Should AI crawlers be blocked?

It depends on the goal. Training crawlers and search crawlers are distinct: blocking OAI-SearchBot removes the site from ChatGPT’s search answers, whereas blocking GPTBot concerns model training. The decision deserves to be made crawler by crawler.

What is WebMCP?

A proposed standard backed by Google and Microsoft at the W3C, which lets a website declare actions (book, search, send a request) that an AI agent can call directly in the browser. It is still in trial.

How do you make a website understandable to an agent?

By starting with the fundamentals of accessibility: semantic HTML, labelled fields, named buttons, a consistent heading hierarchy. This is the information agents read first.