Two posts went up on Friday, both dated October 30, 2026, both describing the same mechanism, both pointing to the same working group.
OpenAI’s post is titled “Making it easier for websites to express AI training preferences” and opens: “Today, we’re announcing that OpenAI will honor a common signal in robots.txt, the file that lets websites express their preferences about the use of their content for foundational generative AI training.”
Google’s post, on the Search Central blog, opens: “Today, we’re announcing our plans to support a shared AI training control in robots.txt.” It says the control “is based on work from the AIPREF working group at the Internet Engineering Task Force (IETF)”.
The document underneath both is Machine-Readable Training Preference Signal, draft-kelley-aipref-training-preference-signal-00, dated 30 October 2026. Its author is K. Kelley of Anthropic. Its intended status is Standards Track. It defines exactly one thing.
What the mechanism actually is
Nothing in the draft invents a new file format. It reuses robots.txt groups, which already bind rules to a named product in the User-Agent line. The draft adds one reserved name to that position and calls it a policy token.
The draft’s own worked example, in full:
User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/
Read as the draft intends, that is a preference against AI training everywhere except under /press-kit/. The draft is explicit that the grammar is untouched: it “introduces no new directive names and no new grammar”, and the path language, longest-match precedence and group structure of robots.txt are unchanged.
Three technical rules in the draft are worth a website owner’s attention, because each one changes what a robots.txt file is saying.
- A wildcard group does not count. Section 4.2 states that wildcard groups, meaning
User-Agent: *, “MUST NOT be interpreted as matching the policy token”. A site that blocks every crawler with a single starred group has, under this mechanism, expressed no training preference at all. It has to name__usage_ai-trainingexplicitly. - No group means no preference. The same section: “If no group contains the __usage_ai-training policy token … then no preference has been expressed.” Silence is not consent and it is not refusal; it is silence.
- An allow is an affirmative preference. If the lookup finds the path allowed, the draft says “a preference in favor of that use has been expressed”. A permissive robots.txt entry becomes an affirmative statement about training, not merely the absence of a block.
Separately, section 4.3 keeps the two conversations apart: crawler rules for a named bot still mean exactly what they meant before, and content-usage preferences and traffic management “are independent and orthogonal”. Blocking a crawler and refusing training are different acts, and the draft does not merge them.
What the draft does not do
This is where the two announcements and the document they lean on diverge in emphasis.
Section 4.4 is one sentence long and it is the sentence that matters most: “This policy token is not a directive for crawling behavior.” What follows is permissive. “A consumer MAY use preferences to inform crawling.” A provider that reads a preference against training is permitted to act on it. Nothing obliges it to.
Section 4.5 closes the loop: “Private agreements MAY override preferences expressed via this mechanism.” A licence, a contract or a negotiated deal outranks anything a website writes in robots.txt. The token records a preference; it does not create a right.
Nowhere in the sections that govern behaviour — 4.1 through 4.5, read in full for this article — is there a requirement that a provider honour a preference it has read. The mandatory language in the draft is about how a consumer must parse and match the token, not about whether it must comply with what it finds. That distinction is the difference between a control and a request, and the draft lands on request.
What status the document actually has
An Internet-Draft is a working document, not an agreed standard, and this one says so about itself. Its Status of This Memo section carries the standard sentence: “It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”” It expires on 3 May 2027.
The document’s own filename settles a second question. A draft named draft-kelley-aipref-training-preference-signal-00 is an individual submission by its named author, not a working-group document adopted by the AI Preferences group. The -00 suffix marks its first revision. Its discussion is directed to the working group’s mailing list, and its “About This Document” note states plainly: “This note is to be removed before publishing as an RFC.”
Google’s post describes the arrangement accurately in one respect and loosely in another. It calls the mechanism “a shared ‘policy token’” and says the new mechanism brings website owners “the benefit of the AI training definition developed at the IETF while multistakeholder discussions continue on the rest of the AIPREF vocabulary”. The same post also calls the token “this draft proposal”, which it is. Neither company describes the token as a standard, and this article does not either.
The two commitments are not the same commitment
OpenAI’s timing: “We aim to implement the signal in the coming months, and will share another update with details about our implementation when we do so.” No quarter, no date.
Google’s timing: “We aim to support this new control along with other AI providers in 2027, and will provide updates on our progress.” A calendar year, and one that begins after the draft has expired unless it is renewed.
Both companies were careful to say the new signal changes nothing that already exists. OpenAI: “This new signal will not replace the controls we already provide through robots.txt.” Google: “Existing company-specific controls will continue to function alongside this new joint signal.” On both accounts the token is additive. A publisher who does nothing keeps exactly the controls it had on Friday morning.
Google’s post also attaches a consequence to the token that the draft does not. It states that a site using the token to opt out of training, where Google-Extended is not explicitly specified, will be read by Google “as if the publisher had disallowed Google-Extended”. And in the other direction: “Websites that specifically allow Google-Extended are eligible to appear in responses and receive clicks via grounding in Gemini Apps.” One shared line therefore has an effect inside a specific product, and the post does not spell out what happens to a site that wants the shared opt-out while staying eligible for grounding.
OpenAI’s post carries an organisation byline, “Author OpenAI”. No individual is named on it.
What we could not establish
- Whether any other provider committed on the same day. Both posts refer to other participants — OpenAI says it is “joining other participants in the working group in today’s announcement”, Google says it aims to support the control “along with other AI providers” — and neither names one. We found no primary statement from any other provider dated October 30, 2026, and we do not report one.
- What “support” will mean in practice. Neither post says whether a provider will stop crawling, stop training, or record the preference and continue on legal advice. The draft permits all three.
- What a publisher can do about non-compliance. There is no mechanism in the draft, and none in either post, for verifying that a provider honoured a preference or for discovering that it did not.
- Whether the two companion drafts the signal depends on are settled. The signal draft borrows its definitions from a separate vocabulary document and refers to an attachment document, both marked as work in progress in its references. We did not assess their state, and nothing in this article depends on it.
Why a shared token is still the story
The practical complaint this mechanism answers is real and it is administrative. Before Friday, a publisher refusing AI training had to identify each provider’s crawler by name, learn each vendor’s proprietary token, and keep them all current. Google’s post concedes the shape of the problem: the token lets owners “pick and choose” across providers instead of managing separate instructions for each.
One line, read the same way by every participant, is a genuine improvement over six lines that each require maintenance. What it is not is enforcement. The draft says a preference is a preference, that a private deal outranks it, and that a provider may do as it likes with what it reads. Two of the largest AI companies have now said they will read it. Neither has said what happens if a third does not.