Agent readiness: can an AI use your website?

A program that reads the text of a page but does not recognise the button on it as a button stands in front of that page like a visitor at a door without a handle. It knows what is written inside and still cannot get in. That gap is exactly what one success criterion of the Web Content Accessibility Guidelines, version 2.2, describes: for all user interface components — the ones named include form elements, links and components generated by scripts — name and role must be programmatically determinable, states, properties and values that can be set by the user must be programmatically settable, and notification of changes to these items must be available to user agents, including assistive technologies. That is success criterion 4.1.2, level A.

The standard itself places this criterion in context, and that context is easily skipped. It is primarily for authors who develop or script their own user interface components; standard HTML controls, it says, already meet it when used according to specification. So the laborious part arises exactly where a button is not a button element but a rebuilt one.

These requirements do not come from the world of AI. WCAG 2.2 says of itself that it defines how to make web content more accessible to people with disabilities, and it lists a broad field — visual, auditory, physical, speech, cognitive, language, learning and neurological disabilities. Anyone who meets these criteria does so for people first. Whether a program gets anything out of it is not stated in that document.

1. 01 · Reading

   What does the page say?

   Success criterion 1.3.1, level A, requires that information, structure and relationships conveyed through presentation are either programmatically determinable or available in text. The two routes stand side by side as equals, joined by an “or” — anyone naming only the first reproduces the standard as stricter than it is. The document sets up no ordering against the operability criteria; that this is the first step here is our own sorting.

2. 02 · Recognising

   Which of it is a control?

   Success criterion 4.1.2, level A, requires a programmatically determinable name and a programmatically determinable role for every control. A field that looks like a select but is not one has neither name nor role for a program. For a person working from the keyboard it is the same hurdle: a screen reader too can only announce what has been marked up.

3. 03 · Acting

   Can the element be operated?

   Success criterion 2.1.1, level A, requires that the functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. The criterion carries an exception for input that depends on the path of movement. And it does not forbid the mouse: a note of its own states expressly that mouse input and other input methods in addition to keyboard operation are neither forbidden nor to be discouraged.

4. 04 · Reading back

   Did it happen?

   Success criterion 4.1.3, level AA, requires that in content implemented using markup languages, status messages are programmatically determinable through role or properties — and in such a way that assistive technologies can present them without the focus jumping there. A green bar without text does not satisfy this. Anyone who only shows completion instead of naming it leaves the last step open.

Anthropic's documentation for its browser tool describes a way of working that distinguishes precisely between structure and image. The tool — listed in the documentation under the toolset identifier browser_toolset_20260801 — works with a page both through its structure, that is the accessibility tree, elements, forms and tabs, and through pixels, that is screenshots and coordinates within the visible viewport. The read_page call, it says, returns the accessibility tree as text and tags every element with a reference that can be clicked later.

This tool therefore does not work through the tree alone. The same page frames structure as a preference and recommends references where a page has a usable accessibility tree; for everything else it names coordinates. And the tool table addresses the application that integrates the tool — it describes what that application's execution layer is to deliver, and it does not promise that Anthropic produces the tree itself.

Alongside it, not against it, stands OpenAI's API tool for operating a computer. OpenAI describes it as screen-based: the calling application provides the environment and executes the model's requests, and the model decides from screenshots and other tool results what to do next. This page makes no comparative statement about other providers. That two ways of working stand side by side here is our juxtaposition and not a statement by OpenAI.

A button that has been pressed is not yet a result. The fourth step is missing precisely when a page only shows success or failure instead of naming it: a green area without a word, a red outline without a message. For a program that is no harder to read than it is for a person who cannot see it — it is the same missing piece of information.

Three requirements of WCAG 2.2 bear directly on orientation within a website. Navigational mechanisms repeated on multiple web pages within a set of web pages must occur in the same relative order each time, unless a change is initiated by the user — success criterion 3.2.3, level AA. Headings and labels must describe topic or purpose — success criterion 2.4.6, same level. And above them stands a guideline of its own called Predictable: web pages are to appear and operate in predictable ways.

One detail belongs with 2.4.6. The criterion requires that headings and labels which are present describe topic or purpose. That a page must have headings at all is not stated there. Meaningful labelling is therefore a normative requirement and not a matter of style — the outline itself remains a recommendation.

Who these requirements were written for decides what may be derived from them. In the W3C documents named below on WCAG 2.2, on ARIA in HTML and on WAI-ARIA 1.2, AI agents do not appear. They speak of people with disabilities, of assistive technologies, of user agents and of conformance checkers. Anyone who justifies semantic structure by its use to AI systems is leaving the standard behind. That benefit can only be evidenced for a named product — and for that, two provider documents are listed below.

The normative rules for ARIA in HTML are set out in the W3C Recommendation “ARIA in HTML”, dated 11 August 2026. The status line identifies it as a Recommendation, published by the Accessible Rich Internet Applications Working Group on the Recommendation track. With a standard, the status is part of the statement: a Recommendation, in the W3C's own description, is a specification endorsed by W3C and its members after extensive consensus-building. A draft is something else.

Two rules in this document bear on practice directly. Authors must not use ARIA roles and aria-* attributes in a way that conflicts with the semantics described in the specification's two conformance tables — the document writes that prohibition in capital letters. And it is not recommended to set role and aria-* attributes to values matching the element's implicit ARIA semantics; doing so, it says, is unnecessary and can potentially lead to unintended consequences. That should not be hardened into a ban: the same specification notes elsewhere that in some situations explicitly setting these attributes can be helpful, for instance for user agents that do not expose implicit ARIA semantics.

The precedence of the existing means over the retrofitted one is set out in a second document. WAI-ARIA version 1.2 is a W3C Recommendation dated 6 June 2023; in its section on conflicts with host language semantics it carries a should-rule: where a feature in the host language with identical role semantics and identical values is available, and the author has no compelling reason to avoid it, the author should use that host language feature rather than repurpose other elements with WAI-ARIA. The rule speaks of the host language in general and not of HTML alone.

The catchy maxim usually quoted on this subject appears in neither of these two documents. It comes from the authoring guide of the Web Accessibility Initiative, is written there differently from the way it usually circulates, and is not a normative text. In “ARIA in HTML” the same point is carried by the must-not and the not-recommended. Anyone attributing the maxim to the Recommendation is citing a source for a sentence that is not in it.

What badly placed ARIA does is shown by the same authoring guide in a small example: a bullet list given the role of a navigation region becomes a navigation region and is no longer a list — the list items inside it are in no list. The section puts both sides next to each other. ARIA, it says, can cloak and enhance at once; some uses act like suspenders or belts and add meaning that supports the original content. Cloaking is the case of badly placed ARIA, not the rule.

That one provider does in fact evaluate ARIA is stated in a help page by OpenAI for publishers and developers. ChatGPT Atlas, it says, uses ARIA tags — the same labels and roles that support screen readers — to interpret page structure and interactive elements. The same page recommends that site owners follow WAI-ARIA best practices and give interactive elements such as buttons, menus and forms descriptive roles, labels and states. The list is phrased as an example, not as an exhaustive one, and the page names a purpose, not a performance promise. It speaks of ChatGPT Atlas and of the ChatGPT agent within it — not of ChatGPT in general and not of other providers.

From Anthropic's documentation only one technical side effect can be read off about the structure of a website, and it is more modest than it sounds. Element references, it says, are scoped to the tab that produced them and stay valid only until that tab navigates or its DOM changes materially; the interface itself cannot detect a stale or unknown reference. That is a rule for the integrating application. A requirement on the website — predictable navigation, say — is not stated on the provider pages named below.

We recommend semantic elements all the same, and expressly as our own recommendation. A navigation region, a main region, a button that is also a button element: that carries four things at once — operability from the keyboard, the announcement in a screen reader, testability against the standard and, according to the OpenAI page named above, interpretation by a named product. On the provider pages named below, however, these elements are not recommended by name. ARIA alone does not make a page agent-ready. It adds semantics where they are missing, and cloaks them where they were already there.

Another question comes before this one: a system can only evaluate semantics that are present on retrieval at all. Whether a button already sits in the delivered document or only appears through client-side JavaScript is decided by the delivery architecture — covered in How modern websites are built and delivered.

The form is where it becomes visible what accessibility is made for. Where content requires user input, labels or instructions must be provided — success criterion 3.3.2, level A. If an input error is automatically detected, the item in error must be identified and the error described in text — success criterion 3.3.1, also level A. A red outline is not text. And where suggestions for correction are known, they must be provided, unless that would jeopardise the security or purpose of the content — success criterion 3.3.3, level AA, with the exception in the same sentence.

These criteria are written for people with disabilities and justified for them. Anyone who meets them builds a form that someone with a screen reader, someone without a mouse and someone with limited attention actually gets to the end of. That a program benefits from the same markup is plausible, but it cannot be evidenced from the standards documents — nothing there says so. Accessibility is therefore not an AI trick. It is first of all a benefit for people, and the side effect for machines is a consequence, not a purpose.

How a label technically reaches its field is governed by the WHATWG HTML standard. A label element, it says, represents a caption in a user interface, and the association with the form control arises either through the for attribute or by putting the form control inside the label element itself. The for attribute may be specified; if it is specified, its value must be the ID of a labelable element in the same tree. The specification does not literally speak of exactly one associated field: it phrases things in the singular and picks the first such element in tree order — and a label with no labeled control at all is provided for as well.

• Label

  Is it clear what belongs in the field?

  A field whose label merely sits next to it without being associated with it looks right and is not. The HTML standard knows two ways: the for attribute, or the field inside the label element. WCAG requires with 3.3.2 that a label or instruction is there at all. For ARIA there is a limit: aria-label and aria-labelledby must not be placed on elements whose implicit ARIA role cannot be named — the word implicit belongs to that sentence, because where the role does allow naming, the same specification expressly permits both attributes.

• Operability

  Can you get through without a pointing device?

  Success criterion 2.1.1 requires operability through a keyboard interface, with an exception for input that depends on the path of movement. A note in the same standard states that mouse input in addition is neither forbidden nor to be discouraged. The authoring guide of the Web Accessibility Initiative explains why this means work with rebuilt elements: an ARIA role, it says, is a promise. Unlike HTML input elements, ARIA roles do not cause browsers to provide keyboard behaviours or styling — whoever declares an element to be a button has to write the behaviour themselves.

• State and errors

  Does the page say what happened?

  Success criterion 3.3.1 requires that an automatically detected input error identifies the item concerned and describes the error in text; 3.3.3 adds known suggestions for correction, provided that does not jeopardise the security or purpose of the content. And 4.1.3 requires status messages to be programmatically determinable through role or properties, without drawing the focus. Which technical means one picks for that is not stated on the provider pages named below — live regions and status roles do not appear there. The recommendation is our own derivation from the standard.

One rule is often quoted in this context as a current standard, and is no longer one. The classic first rule of ARIA — an existing HTML element with the meaning and behaviour you want, rather than a repurposed element with a retrofitted role — is set out in a W3C document that has listed itself as a discontinued draft since 24 February 2026 and says of itself that it is informative only. As a current requirement the same point is carried by the two documents from the previous section. For the third rule of the same draft — every interactive ARIA control must be usable with the keyboard — we found no normative counterpart in the documents named below.

There is a conformance rule for the label element itself, too. If a label element is implicitly or explicitly associated with a labelable element, no ARIA role may be given to it; the introduction to that section states that the implicit ARIA semantics, or the native semantics of the HTML element, must not be overwritten. If the label is associated with no element, any role is admissible — the generic role, however, should not be used.

How a tool actually handles such a form is described by Anthropic for its browser tool. The form_input call, it says, sets a form element's value directly: a boolean for checkboxes, and for selects an option's value or its visible text. Beforehand, though, the element has to be addressed — the call works on a reference obtained earlier from read_page or from find. The find call in turn searches for elements matching a natural-language description such as “search field” or “add to cart button”. How it resolves such a description the page does not say; of labels or accessible names there is no mention there.

On reading back, the same page offers an observation that should not be overstretched. Claude, it says, typically ends a batch of calls with an observation call — a screenshot, a read_page or a get_page_text. The same paragraph, however, opens with the note that a screenshot is not needed after every call, and leaves it to the integrating application to attach the observation itself. An “every action ends with a read-back” is not stated there.

And part of the subject is simply not covered in the documents named below. On required fields, on associating an error message with its field, on error states, on the fill-in hint for browsers and on the response after submitting, there is nothing there that could be evidenced here. Anyone implementing these points does so as good practice — not on the strength of a passage this article could quote.

For sign-in, WCAG 2.2 has gained a new success criterion of its own. Under 3.3.8, level AA, no step of an authentication process may require a cognitive function test — the standard names remembering a password and solving a puzzle as examples — unless that step provides at least one of four listed options. Two of them are ways around it: an alternative authentication method that does not rely on a cognitive function test, and a mechanism available to assist the user in completing the test. The other two are permitted kinds of the test itself: that the test consists of recognising objects, or of identifying non-text content the user provided to the website. Anyone speaking only of ways around it presents the standard as stricter than it is.

For the transaction itself a second criterion applies. For web pages that cause legal commitments or financial transactions for the user, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of three things must be true — the submission is reversible, it is checked for errors, or it can be confirmed before finalisation. That is success criterion 3.3.4, level AA.

A third criterion, also new, concerns repetition. Under 3.3.7, level A, information already entered earlier in the same process must be either auto-populated or available for the user to select. But the sentence does not stop there: it goes straight on to three exceptions — where re-entering the information is essential, where it is required to ensure the security of the content, or where previously entered information is no longer valid. The security exception in particular applies to sign-in forms. A “must not be asked for a second time” is not in this criterion.

What Anthropic, OpenAI and Google permit their own products at this point is set out in five documents — and none of them speaks about the other two providers. Anthropic lists, for Claude in Chrome, actions that are prohibited regardless of the permission level chosen; among them are purchases and financial transactions, creating accounts, and handling sensitive credit card or ID data, plus seven further points. A second help article states that Claude asks for permission before accessing financial sites — so financial sites are not on the prohibition list there but subject to permission. What counts as a financial site Anthropic does not define, and it limits itself by noting that it is unlikely to have captured all sites in these categories.

OpenAI separates the same matter across two documents. The recommendations for integrating the computer use tool carry a section headed with the instruction to confirm immediately before the action; named there are, among others, sending, posting or submitting to a third party on the user's behalf, subscribing to and unsubscribing from notifications, and confirming financial transactions. The list is expressly phrased as an example list and addresses integrators, not end users. For the agent in ChatGPT Atlas a help page describes something else: it pauses on certain sensitive sites such as financial institutions to make sure the user is watching.

For the self-driving browsing of Gemini in Chrome, Google describes a prompt named “Take over task”. Gemini in Chrome may ask the user to take over the task for certain steps — named are finalising financial transactions, accepting terms of service and creating an account. It is phrased as a may and as an open example list. And Google devalues its own list twice over in the same text: these safeguards, it says, do not guarantee protection against all risks.

One risk is named by Anthropic in the documentation for the computer use tool so plainly that it belongs here. In some circumstances, it says, Claude will follow commands found in content even when they conflict with the instructions of the party operating it; instructions on web pages or contained in images might override those instructions or cause mistakes. The following paragraph on the same page names countermeasures — training, classifiers and a check with the user. Anyone quoting only the risk sentence reproduces the page in abbreviated form.

What is evidenced, then, is what these five documents leave out or tie to a human confirmation — the stage of maturity is our own placement. On passing on credentials, on bot defence and on liability for transactions triggered by automation, nothing is stated in WCAG 2.2 as named below; what can be evidenced there are the three success criteria above. For a business planning today that means: the path up to the submitted contact form is the part for which this article can name evidence. Everything behind the sign-in is a second step — and Anthropic, OpenAI and Google have each restricted it for their own products themselves.

What applies depends on the date of the document it is set out in. WCAG 2.2 is a W3C Recommendation dated 12 December 2024, and the page itself notes that errata exist. It extends version 2.1 of June 2018, and content that conforms to 2.2 also conforms to 2.0 and 2.1. Where this article names a date, that is not a formality but part of the statement.

A W3C document, too, can lose its status. “Using ARIA” has been a discontinued draft since 24 February 2026; the four rules of ARIA, it says, are kept there for historical purposes and for easier reference, and there are no plans to continue work on the document. Anyone invoking these rules invokes a text whose own status line rules that out. For the first of the four rules the living counterpart is in “ARIA in HTML” and in WAI-ARIA 1.2; for the third we found none.

Even within a document currently in force not everything is binding, and the boundary is stated there expressly. “ARIA in HTML” records in its conformance section: as well as sections marked as non-normative, all authoring guidelines, diagrams, examples and notes are non-normative; everything else is normative. And key words such as “must” or “should” count as such only when they appear in capital letters. Anyone quoting a standard is therefore always quoting a level of obligation as well.

How far the standard reaches at all it likewise states itself. The notion of accessibility support is tied in the W3C document to demonstrated interoperability with users' assistive technology: the way a web content technology is used must have been tested for interoperability with users' assistive technology in the human language of the content — and that is expressly only the first of two conditions, both of which must be met. How much assistive technology support is needed the W3C expressly does not define, in a note of its own.

• documented

  Identifiers and robots.txt

  Google maintains a list of user-triggered fetchers and writes in its introduction that such fetchers generally ignore robots.txt rules because the fetch was requested by a user; the list describes itself as not exhaustive. The identifier Google-Agent is connected by the same page with agents hosted on Google infrastructure that navigate the web and perform actions upon user request — what those actions are directed at, the page does not say. OpenAI lists four identifiers and writes of ChatGPT-User that it is not used for crawling the web in an automatic fashion and that robots.txt rules may not apply to these user-initiated actions; for search results, it says, it can take around 24 hours after a robots.txt change for its own systems to adjust. Anthropic lists three identifiers and undertakes to respect “do not crawl” signals by honouring industry standard directives in robots.txt — with the caveat, in the same document, that alternate methods such as blocking IP addresses may not work correctly. Perplexity writes on its crawler page, about the user-triggered identifier Perplexity-User, that this fetcher generally ignores robots.txt rules because a user requested the fetch; the neighbouring row on PerplexityBot carries the opposite recommendation, to allow it in your site's robots.txt file — the two are not to be conflated. The same page writes in its introductory paragraph that it may take up to 24 hours for its own systems to reflect changes to robots.txt.

• tied to a product

  What a named tool can do

  OpenAI names express limits for the agent in ChatGPT Atlas: it cannot run code in the browser, download files, or install extensions. Anthropic describes, for Claude in Chrome, built-in knowledge of how to navigate named platforms — Slack, Google Calendar, Gmail, Google Docs and GitHub — and calls these capabilities site-specific itself; the list is expressly not exhaustive and says something about stored knowledge, not about operability as such. The same extension reads, clicks and navigates websites, in Anthropic's description, alongside the user, and the same introductory block records that interacting directly with websites on the user's behalf is still risky. Perplexity describes, in the developer documentation for the Perplexity Computer MCP Server, a full cloud browser: when a task requires interacting with a website, filling forms or accessing login-gated content, Computer launches a browser session automatically. What that browser does is listed by the same page in a capability table — navigate to any URL, click elements, fill forms and extract structured data. That describes a capability; that it happens on every page is not what the row says.

• Experiment

  Signed agent traffic

  For part of its agent traffic, Google is testing a cryptographic procedure: a subset of the requests made by Google-Agent, it says, are signed and are then authenticated under an address of their own. Google calls its own implementation currently experimental, writes that not all Google user agents use the procedure, and recommends that, in addition to it, site owners continue relying on IP addresses, reverse DNS and user-agent strings while signed traffic is gradually rolled out. The page draws the conclusion itself: be sure to fall back to the established methods of bot verification. Whether other providers use the same procedure, this page does not say.

How reliable that is in daily use, none of these documents states in figures. For the computer use tool Anthropic at least formulates a possibility: Claude might make mistakes or hallucinate when selecting tools and take unexpected actions; reliability might be lower with niche applications or with several applications at once. That is a possibility and not a finding — and a success rate for operating someone else's websites is set out in none of the documents named below.

That is why there is no percentage figure in this article. Nor anything on the websites of small businesses: on German-language sites, on trade or practice websites and on booking flows typical of a sector, none of the provider documents named below says anything. Anyone quoting you a rate on this should say where it comes from — it does not come from the provider documents named below.

What is workable today is above all what is good work anyway. A page that delivers its content in text, marks up its controls, labels its forms and names its states is more operable for people using assistive technology, testable against a published standard and — according to the OpenAI page named in the second section — more interpretable for a named product. That is a solid gain, and it hangs on no provider promise.

Everything beyond that is an experiment. Anyone assuring you that AI agents can reliably operate your website today is promising something that Google, OpenAI and Anthropic, in the documents named below, do not promise for their own products: Google expressly devalues its own safeguards, OpenAI lists functional limits, and Anthropic names mistakes and lower reliability as a possibility. The part you hold in your hands is the page. What an agent makes of it is the part to which the documents named below give no assurance.

W3C — WCAG 2.2

WCAG 2.2 contains every success criterion in this article: 1.3.1, 4.1.2 and 2.1.1 in the first section, 3.2.3, 2.4.6 and guideline 3.2 in the second, 3.3.1, 3.3.2, 3.3.3 and 4.1.3 in the third, 3.3.4, 3.3.7 and 3.3.8 in the fourth, and the date, the version and the notion of accessibility support in the fifth.

Web Content Accessibility Guidelines (WCAG) 2.2 W3C Recommendation of 12 December 2024; the page notes that errata exist. Without a browser it answers with HTTP 403. Retrieved on 4 September 2026

W3C — ARIA in HTML

The specification names the normative ARIA rules in the second section, the limit on aria-label and aria-labelledby together with the conformance row for the label element in the third, and the delimitation of normative from non-normative in the fifth. A normative specification by the Accessible Rich Internet Applications Working Group — not a draft and not a guide.

ARIA in HTML W3C Recommendation of 11 August 2026. Without a browser the page answers with HTTP 403. Retrieved on 4 September 2026

W3C — WAI-ARIA 1.2

WAI-ARIA 1.2 marks, in the second section, the status as an adopted Recommendation and names the should-rule from the section on conflicts with host language semantics: the host language feature before the repurposing of other elements.

Accessible Rich Internet Applications (WAI-ARIA) 1.2 W3C Recommendation of 6 June 2023 — the version is expressly no more recent than that. Without a browser the page answers with HTTP 403. Retrieved on 4 September 2026

W3C — Using ARIA

The draft gives, in the third section, the historical wording of the first and the third rule of ARIA, and shows in the fifth that a W3C document can lose its status. Expressly a discontinued, informative-only draft — the rules in force are in “ARIA in HTML” and in WAI-ARIA 1.2.

Using ARIA W3C Discontinued Draft of 24 February 2026. Without a browser the page answers with HTTP 403. Retrieved on 4 September 2026

W3C WAI — ARIA authoring guide

The guide brings, in the second section, the example of the list that a navigation role turns into something other than a list, and the juxtaposition of cloaking and enhancing; in the third, the principle that a role is a promise. An authoring guide by the Web Accessibility Initiative, not normative.

Read Me First — ARIA Authoring Practices Guide No date given on the page. Without a browser it answers with HTTP 403. Retrieved on 4 September 2026

WHATWG — HTML Standard, forms

The HTML Standard lays down, in the third section, the rules for form labels: what a label element is, how the association with the field arises, and what requirement applies to the for attribute.

HTML Standard — 4.10 Forms Living Standard, last updated on 3 September 2026, retrieved on 4 September 2026

Anthropic — browser tool

Anthropic describes, in the first section, the way of working through structure and pixels and the call that reads out the page, in the second the expiry of element references, and in the third the setting of form values, the search by natural-language description and the closing observation call. Developer documentation by the provider.

Browser use tool No date given on the page; the only version indication is the toolset identifier. Retrieved on 4 September 2026

Anthropic — computer tool

Anthropic names, in the fourth section, the documented risk that instructions found in page content override the instructions of the operating party, together with the countermeasures named in the following paragraph, and in the fifth the possibility statement on mistakes and lower reliability. Developer documentation by the provider.

Computer use tool No date given on the page, retrieved on 4 September 2026

Anthropic help — Claude in Chrome

The help centre lists, in the fourth section, the actions prohibited regardless of the permission level and the permission prompt before financial sites together with Anthropic's own qualification of it, and in the fifth the site-specific navigation knowledge and the description of the extension that reads, clicks and navigates alongside the user. Help centre articles for end users, not developer documentation.

Claude in Chrome permissions guide · Use Claude in Chrome safely · Get started with Claude in Chrome Only relative date information on the pages, retrieved on 4 September 2026

Anthropic help — crawlers

Anthropic names, in the fifth section, the provider's three identifiers, the undertaking on industry standard robots.txt directives and the caveat named in the same document about other ways of blocking. A help centre article from the collection on privacy and legal matters.

Does Anthropic crawl data from the web, and how can site owners block the crawler? Page dated 7 April 2026, retrieved on 4 September 2026

OpenAI — computer use

OpenAI describes, in the first section, the screen-based way of working and the division of roles between model and calling application, and in the fourth the list of actions to be confirmed immediately beforehand. Developer documentation by the provider; the second page expressly addresses integrators.

Computer use · Computer use integration recipes No date given on the pages, retrieved on 4 September 2026

OpenAI help — Atlas and publishers

The OpenAI help centre describes, in the second section, the evaluation of ARIA tags by ChatGPT Atlas and the recommendation to follow WAI-ARIA best practices, in the fourth the pause on sensitive sites, and in the fifth the functional limits of the agent in Atlas. Help centre articles.

Publishers and Developers — FAQ · Using Ask ChatGPT sidebar and ChatGPT Agent on Atlas Only relative date information on the pages; without a browser they answer with HTTP 403. Retrieved on 4 September 2026

OpenAI — crawler identifiers

OpenAI names, in the fifth section, the provider's four identifiers, the description of ChatGPT-User together with the caveat that robots.txt rules may not apply, and the lead time of around 24 hours for search results. Product and developer documentation, not a blog post.

Overview of OpenAI Crawlers No date given on the page, retrieved on 4 September 2026

Google help — Gemini in Chrome

The Google help calls, in the fourth section, for taking over certain steps yourself — finalising financial transactions, accepting terms of service, creating an account — and states twice the caveat that the safeguards described do not guarantee protection against all risks. A help centre article for end users.

Ask Gemini in Chrome to complete tasks for you with auto browse No date given on the page, retrieved on 4 September 2026

Google — user-triggered fetchers

Google states, in the fifth section, by way of introduction that user-triggered fetchers generally ignore robots.txt rules, calls the list itself not exhaustive, and describes the Google-Agent identifier. Reference documentation by the vendor, not a blog post.

List of Google user-triggered fetchers Page dated 19 August 2026, retrieved on 4 September 2026

Google — Web Bot Auth

Google describes, in the fifth section, the experiment with signed agent traffic: the signed subset of requests, the express labelling as experimental, the note that not all identifiers use the procedure, and the recommendation to continue relying on IP addresses, reverse DNS and user-agent strings. Developer documentation by Google, not an announcement.

Authenticate requests with Web Bot Auth (experimental) Page dated 4 May 2026, retrieved on 4 September 2026

Perplexity — Computer MCP Server

Perplexity describes, in the fifth section, the full cloud browser that Perplexity Computer launches automatically when needed, and the row of the capability table on navigating, clicking, filling and extracting. Developer documentation from the provider, neither a blog post nor a changelog.

Perplexity Computer MCP Server No visible date on the page, retrieved on 4 September 2026

Perplexity — crawler identifiers

Perplexity describes, in the fifth section, the user-triggered identifier Perplexity-User, the opposite recommendation in the neighbouring row on PerplexityBot, and the lead time of up to 24 hours for changes to robots.txt. Product and developer documentation, not a policy page.

Perplexity Crawlers No visible date on the page, retrieved on 4 September 2026

State of this article: 4 September 2026. Provider statements can change without notice; a measurement stays bound to its date. Where this article names a date, that is not a formality but part of the statement. Seven of the pages named here answer retrievals without a browser with HTTP 403 — the five addresses at the W3C and the two in OpenAI's help area. Anyone wishing to check needs a browser for that.