The October 30, 2026 announcements from OpenAI, Google and Microsoft back a shared way for websites to express AI-training preferences in robots.txt. They do not give every provider the same activation date. A publisher should record each provider’s stated timeline before treating the new signal as operational everywhere.
Read the three timelines separately
OpenAI says it aims to implement the shared signal in the coming months and will provide implementation details in a later update. It also says the new mechanism will not replace its existing crawler controls. Its announcement is therefore a commitment with implementation still ahead, rather than confirmation that the signal is already active.
OpenAI’s October 30 announcement and implementation wording
Google says it aims to support the control in 2027. Its announcement also explains how provider-specific settings interact with the shared preference: where Google-Extended is not explicitly specified, Google plans to interpret a shared training opt-out as a Google-Extended disallow. Explicit provider settings therefore deserve their own review.
Google’s planned support and Google-Extended interaction
Microsoft gives February 1, 2027 as the start for honoring its new preferences as it crawls. Its announcement includes a separate March 1 transition deadline for sites using NoArchive or NoCache for training and grounding preferences. These dates describe different parts of its rollout; neither is a common start date for all providers.
Microsoft’s rollout, transition and implementation guide
What the shared token expresses
The October 30 Internet-Draft names the policy token __usage_ai-training. It describes a content-use preference expressed through a robots.txt group, while preserving ordinary crawler-specific rules. The document is work in progress, not a completed RFC.
Internet-Draft: Machine-Readable Training Preference Signal
A declared training preference should not be read as a universal technical block on downloading a page. The draft separates content-use preferences from crawl-management signals. Implementation and provider behavior still matter; publishing a line in a file is not evidence that every consumer has adopted it.
Try a fictional rollout record
Imagine an invented publisher with a review sheet containing three providers. One row says support is planned without an exact date, another names a future year, and a third names a particular day. A colleague summarizes the sheet as “all providers activate on the named day.” That summary has transferred one provider’s timetable to the other two.
Correct the sheet by keeping the announcement date, planned implementation date, existing provider-specific controls and next verification step in separate columns. Preserve words such as aims and plans. Mark a completed implementation only when later evidence establishes it. This example is a documentation exercise, not a test of an actual website.
Keep the change reviewable
Before changing a real file, retain its current contents and identify which existing settings express crawl access and which express content-use preferences. Compare each proposed change with that provider’s current documentation. A clean file syntax check would not prove that a provider has discovered or applied the preference.
This article reviews published announcements and the draft mechanism. It does not modify any robots.txt file, verify a crawler’s behavior or establish that previously collected material has been removed. The immediate planning task is to distinguish a published preference, a provider’s announced support and a subsequently verified implementation.
Read the Rollout Dates
