For website teams, the emerging standard is less about blocking bots and more about publishing a machine-readable intent: which material may help train generative AI systems. Google, Microsoft, OpenAI and Anthropic are backing a draft that lets a site state that choice through a set of rules in robots.txt. The practical value is narrow but useful: teams can express training permission separately from ordinary crawl access, while staying inside a file format that web infrastructure already understands.
Before editing the file, publishers should separate three questions: should AI systems be allowed to fetch the page; should fetched text become training data; and should the page be retrieved to support an AI answer? The new training preference addresses the second question. It does not automatically answer the first or third, although later sections explain where provider behavior overlaps.
The proposal is tracked as an IETF Internet-Draft on the IETF DataTracker, which means webmasters should treat the wording as a standardization target rather than a finished law-like requirement. Still, because participating vendors have publicly stated their timelines, teams can prepare rules now.
Instead of maintaining a vendor-specific checklist, operators can place the shared User-Agent token in robots.txt and pair it with ordinary Disallow and Allow directives. The pattern can cover the whole site, or create exceptions for selected folders such as press kits, changelogs, or public archives.
| Publisher goal | robots.txt pattern | Review point |
| Exclude all site content from AI training | User-Agent: __usage_ai-training; Disallow: / | Confirms that the signal states a purpose preference, not an access block. |
| Keep most pages out, but open a public folder | User-Agent: __usage_ai-training; Disallow: /; Allow: /archive/ | Check that only intended paths are opened and that the folder contains no confidential material. |
| Exclude one sensitive folder | User-Agent: __usage_ai-training; Disallow: /archive/ | Use this only if the rest of the site should remain allowed under the policy. |
Adoption is staggered, so the safest rollout is staged. A site can publish the preference early, then validate how each provider reads it once their support window opens.
| Company | Stated support window | Practical implication |
| Microsoft | Starting February 1, 2027 | Sites that want to opt out of training use can prepare the declaration now, before the date arrives. |
| Early 2027, subject to readiness | Review Google-Extended settings now; if the new preference is used without an explicit Google-Extended rule, Google plans to treat the site as rejecting Google-Extended. | |
| OpenAI | Within the coming months | Run the rule through a robots.txt parser and document the change before the implementation window closes. |
| Anthropic | Appears to have begun supporting the draft | Check crawl and AI usage logs where available, because early support may precede full ecosystem convergence. |
No. The statement expresses a usage preference. If a site wants to deny access to a particular bot, it must still configure conventional robots.txt rules for that bot.
No. Training and AI answer retrieval are separate use cases. Microsoft provides AI Grounding controls for specific pages within Microsoft services, while Google's behavior around Google-Extended can affect Gemini-related training and reference paths.
Publish a conservative default, such as excluding the whole site from training while allowing only clearly public folders. Then validate exceptions, review logs after each vendor support date, and treat any change as a content-governance decision, not a one-line configuration trick.
For the General desk, the story is simple: robots.txt is becoming a policy panel for AI use, not only a crawler switch. The immediate action for web teams is to choose a training posture, document the rules, review Google-Extended and Microsoft AI Grounding as separate decisions, and monitor adoption as Google, Microsoft, OpenAI and Anthropic support windows mature.