User-Agent: __usage_ai-training - Google y Bing planean estandarizarlo

Google y Microsoft Bing han anunciado que admitirán una señal común de robots.txt para expresar si una web permite usar su contenido para entrenar IA generativa. 

Sería con con User-Agent: __usage_ai-training. 

Un Disallow: / en ese user-agent expresa el rechazo al entrenamiento para toda la web. 

También permite definir preferencias por rutas. No sustituye las reglas de acceso de Googlebot o Bingbot ni es una barrera técnica contra un rastreador que las ignore.

El documento de Kevin Kelley, de Anthropic, es un borrador individual del IETF, el organismo que desarrolla estándares de internet. 

Su ficha advierte de que no está respaldado por el IETF y no tiene rango formal en el proceso de estándares. Solo lo interpretarán los proveedores que lo adopten. 

El comodín User-agent: * no expresa esta preferencia de entrenamiento. Es decir, que no valdría para este propósito.

OpenAI ha anunciado que respetará la señal «en los próximos meses», sin retirar GPTBot ni sus demás controles de robots.txt. 

Anthropic, de donde sale el borrador, dice en la lista del grupo de trabajo que ya ha empezado a implantarla.

Qué decide cada buscador con tu configuración

Este simulador monta el robots.txt y las etiquetas a partir de lo que elijas y dice cómo los leerán Google, Bing, OpenAI y Anthropic según lo anunciado. Para comprobar un robots.txt real, mi  probador de robots.txt ya admite el token __usage_ai-training

Por si alguien puede hacer pruebas antes de que llegue el estándar. Igualmente en este artículo os muestro como funciona.

Cómo se escribe en robots.txt

El token se trata como si fuera el nombre de un rastreador: abre un grupo con User-Agent y dentro valen Allow y Disallow con las reglas de siempre del estándar de robots.txt (RFC 9309): se aplica la regla con la ruta más larga que encaje y, en empate, gana Allow. 

Permitir es lo que se entiende cuando no hay grupo, así que para dejar entrenar no hace falta escribir nada. Estos son los tres patrones que documenta Bing y que Google leerá igual:

# Rechazar el entrenamiento en toda la web
User-Agent: __usage_ai-training
Disallow: /

# Rechazarlo solo en una carpeta
User-Agent: __usage_ai-training
Disallow: /informes/

# Permitirlo de forma explícita (es lo que ya pasa por defecto)
User-Agent: __usage_ai-training
Allow: /

Como las reglas son las del estándar, se combinan como en cualquier otro grupo. El ejemplo del propio borrador del IETF rechaza el entrenamiento en toda la web salvo en el kit de prensa:

User-Agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

El Comodín User-agent: * no servirá por si solo aunque se ponga Disallow para prohibir el entrenamiento. Así que cuidado con esta potencial trampa.

Y una misma línea User-Agent puede nombrar el token junto a rastreadores concretos, que leerán esas reglas como propias.

Así queda un archivo que cierra una carpeta privada a todos, rechaza el entrenamiento en toda la web y, aun así, deja que Google siga usando el contenido a través de Google-Extended:

User-agent: *
Disallow: /privado/

User-agent: Google-Extended
Allow: /

User-Agent: __usage_ai-training
Disallow: /

Con ese archivo:

• Googlebot rastrea todo menos /privado/
• Bing no entrenará con la web y Google sí: acepta el token, pero da prioridad al grupo de Google-Extended por ser más específico.
• Si se quita ese grupo, el token pasa a decidir: Google lo aplica como si Google-Extended estuviera bloqueado.

Google lo vincula a Google-Extended

Si una web rechaza el entrenamiento con el token común y no especifica Google-Extended, Google lo tratará como si hubiera bloqueado Google-Extended. 

Google acepta el token como señal propia, pero solo lo aplica cuando Google-Extended no está especificado: si hay un grupo explícito, manda ese por ser la regla más específica, la misma lógica que sigue el borrador del IETF, donde lo específico prima sobre lo general. La documentación sitúa el soporte a principios de 2027, sin fecha concreta.

Google-Extended no decide la inclusión ni el ranking en Google Search. Para excluir contenido de AI Overviews y AI Mode, Google documenta un control separado en Search Console.

Bing permite elegir por separado entrenamiento y respuestas

Bing añade preferencias de entrenamiento por página, es decir, que valdrá la configuración de html y de x-robots. Para hacerlo de forma específica. En principio en lugar de la más o menos restrictiva prevalecerá "html o x-robots", pero creo que es pronto para decirlo hasta que no salga el estándar. 

Cabe decir que rechazar el entrenamiento no obliga a rechazar las citas en Copilot. Estas preferencias no cambian la elegibilidad para los resultados clásicos de Bing.

La etiqueta y la cabecera, solo para Bingbot

Las preferencias por página de Bing van en una meta robots o en la cabecera HTTP X-Robots-Tag, dirigidas a Bingbot y con el formato uso:valor. Para el entrenamiento los valores son allow y disallow; para el grounding, allow, disallowextended y disallow. Si una página dice sobre el entrenamiento algo distinto del robots.txt, manda la página. 

Estas etiquetas son solo estándar propuesto por parte de Microsoft: el borrador del IETF solo define el token de robots.txt, y otros proveedores no tienen por qué leerlas.

<!-- En el <head> de la página -->
<meta name="Bingbot" content="ai-training:disallow">
<meta name="Bingbot" content="ai-grounding:disallowextended">

# La misma decisión como cabeceras HTTP; valen también para PDF e imágenes
X-Robots-Tag: Bingbot: ai-training:disallow
X-Robots-Tag: Bingbot: ai-grounding:disallowextended

La cabecera se añade desde el servidor, igual que un noindex por X-Robots-Tag. En Apache basta con el .htaccess; en nginx hay que tocar la configuración y recargar el servicio:

# Apache (.htaccess), para toda la web
<IfModule mod_headers.c>
  Header add X-Robots-Tag "Bingbot: ai-training:disallow"
</IfModule>

# Apache, solo los PDF
<FilesMatch "\.pdf$">
  Header add X-Robots-Tag "Bingbot: ai-grounding:disallow"
</FilesMatch>

# nginx, para toda la web
add_header X-Robots-Tag "Bingbot: ai-training:disallow";

# nginx, solo una carpeta (dentro de un location hay que repetir
# las cabeceras del nivel superior, porque add_header las anula)
location ^~ /informes/ {
  add_header X-Robots-Tag "Bingbot: ai-grounding:disallowextended";
}

Se usa Header add y no Header set para no pisar un X-Robots-Tag que ya exista, por ejemplo con un noindex. Como con cualquier etiqueta de página, Bing tiene que poder rastrear la URL para leerla: una ruta bloqueada en robots.txt no puede declarar nada.

Las nuevas opciones sustituirán a NoArchive y NoCache para estos usos. El calendario anunciado es:

• 15 de diciembre de 2026: se abre una preferencia temporal de grounding en Bing Webmaster Tools para las webs que ya usen NoArchive o NoCache en esa fecha.
• 1 de febrero de 2027: empieza la aplicación de las preferencias nuevas cuando Bing las descubra al rastrear.
• 1 de marzo de 2027: NoArchive y NoCache dejan de interpretarse como preferencias de entrenamiento o grounding.
• 30 de septiembre de 2027: caduca la protección temporal que no haya sido reemplazada antes por las preferencias de página detectadas en un nuevo rastreo.

Para quien ya limita esos usos en Bing, la tarea es revisar la migración: publicar las preferencias nuevas y, si quiere mantener la restricción de grounding durante la transición, registrar también la opción temporal antes del 1 de marzo. Para el entrenamiento no habrá opción temporal. En Google, conviene revisar primero las reglas explícitas de Google-Extended y decidir sobre sus dos usos. El token común reduce trabajo entre proveedores, pero no iguala sus efectos.