Cloudflare redefine cómo clasifica los crawlers de IA
Cloudflare acaba de introducir un cambio relevante en la forma en que los crawlers de inteligencia artificial son clasificados y gestionados.
Y para los equipos de SEO, contenido, seguridad y marketing digital, no es un ajuste menor.
En su segundo “Content Independence Day”, Cloudflare ha evolucionado desde un enfoque más simple —bloquear o permitir todos los bots de IA— hacia un modelo mucho más granular basado en comportamiento.
La pregunta ya no es únicamente: “¿Este bot es de IA?”
Ahora la pregunta clave es: ¿Qué está haciendo este bot con mi contenido, qué almacena y cómo puede reutilizarlo o redistribuirlo?
Tres tipos de uso que los propietarios web pueden controlar
Cloudflare pasa a distinguir tres grandes casos de uso para los crawlers de IA. Esta clasificación estará disponible incluso para el plan Free:
Search
Este caso hace referencia a los bots que indexan contenido para responder consultas posteriormente.
Es el comportamiento más cercano al rastreo tradicional de los motores de búsqueda, ya que puede generar tráfico de referencia hacia el sitio web. Por este motivo, Search estará permitido por defecto.
Agent
Aquí entran los bots que actúan en tiempo real en nombre de una persona.
Por ejemplo, agentes como ChatGPT-User, Gemini o Claude interactuando a través de un navegador como Chrome para ejecutar acciones solicitadas por un usuario.
Training
Este caso cubre los crawlers que acceden al contenido con el objetivo de absorberlo de forma permanente para entrenar o mejorar modelos de IA.
Es, probablemente, el uso que más preocupa a editores, medios, marcas y propietarios de contenido, ya que implica una reutilización profunda del contenido publicado.
El cambio clave: nuevas reglas por defecto desde el 15 de septiembre de 2026
El punto con mayor impacto para SEO llega con los nuevos valores por defecto que Cloudflare aplicará el 15 de septiembre de 2026.
En las páginas que muestran anuncios, los usos Training y Agent estarán bloqueados por defecto, mientras que Search seguirá permitido para nuevos dominios que se incorporen a Cloudflare.
Hasta aquí, el cambio parece razonable. Sin embargo, hay un detalle especialmente importante:
Los crawlers multipropósito serán bloqueados según todos sus comportamientos.
Esto significa que, si un bot se utiliza tanto para Search como para Training, y se bloquea Training, ese crawler podría quedar bloqueado también.
En la práctica, crawlers combinados como Googlebot, Applebot o Bingbot pueden verse afectados si se clasifican como bots que cumplen varias funciones. Para los equipos SEO, esto abre un riesgo claro: bloquear sin querer crawlers necesarios para la indexación orgánica.
Dicho de otro modo: una regla diseñada para impedir el entrenamiento de modelos podría terminar afectando a la visibilidad en buscadores.
Qué deben hacer los equipos SEO
Antes del 15 de septiembre de 2026, conviene revisar la configuración de seguridad y rastreo en Cloudflare.
El objetivo es claro:
Evitar que una política de bloqueo sobre Training afecte accidentalmente a la indexación del sitio.
Las organizaciones que dependen del tráfico orgánico deberían auditar cuanto antes:
- Qué crawlers están permitidos o bloqueados.
- Si existen reglas específicas para bots de IA.
- Cómo se clasifican los crawlers multipropósito.
- Si los bots relevantes para Search siguen teniendo acceso.
- Qué impacto podrían tener los nuevos valores por defecto en nuevos dominios o configuraciones futuras.
Nuevas señales para robots.txt: use=immediate, use=reference y use=full
Cloudflare también introduce una nueva señal de uso que amplía los Content Signals en robots.txt.
Esta señal permite expresar preferencias sobre cómo puede utilizarse el contenido:
use=immediate El bot puede acceder al contenido para una respuesta inmediata, pero no debería almacenarlo.
use=reference El bot puede indexar, extraer fragmentos y enlazar de vuelta al contenido original. Este pasa a ser el nuevo valor por defecto.
use=full El bot puede resumir y reproducir el contenido de forma más completa.
Es importante destacar que estas señales son preferencias declaradas, no bloqueos técnicos estrictos. Funcionan como una capa de comunicación entre propietarios de sitios y operadores de bots, pero no sustituyen a las reglas de seguridad, firewall o control de acceso.
La verificación de bots también cambia
Otro cambio relevante es el significado de “Verified”.
Hasta ahora, un bot verificado podía interpretarse como un bot de confianza o permitido por defecto. Con el nuevo enfoque, Verified ya no significa automáticamente permitido.
Ahora, la verificación indica que un bot puede ser considerado admisible dentro de su categoría, pero su acceso dependerá de las políticas configuradas para ese tipo de comportamiento.
Además, los bots que reproduzcan contenido completo no podrán obtener el estado de Verified. Y si un bot abusa de las señales declaradas, puede perder su estado verificado.
BotBase: un nuevo directorio para entender quién rastrea tu sitio
Cloudflare también presenta BotBase, un directorio searchable para clientes Enterprise Bot Management.
Este directorio permitirá consultar los bots rastreados, su clasificación y un identificador de detección que se podrá copiar para crear reglas de seguridad.
Para equipos de seguridad, SEO técnico y plataforma, esto puede convertirse en una herramienta útil para entender mejor qué bots acceden al sitio, con qué propósito y bajo qué clasificación.
Transitive trust: confianza a través de intermediarios
Cloudflare también está experimentando con un concepto llamado transitive trust.
La idea es utilizar el header Forwarded, definido en RFC 7239, para que las decisiones de confianza se mantengan incluso cuando una solicitud pasa por capas intermedias.
Un ejemplo sería:
Forwarded: for="openai";use="reference"
Esto permitiría indicar no solo quién está detrás de la solicitud, sino también el tipo de uso previsto del contenido.
Aunque todavía se trata de un experimento, apunta hacia un modelo más transparente para gestionar el acceso de agentes, crawlers e intermediarios en la web.
La conclusión: el control sobre los bots de IA será más granular
El mensaje de fondo es claro: estamos entrando en una etapa en la que el control sobre los crawlers de IA será mucho más detallado.
La era en la que “búsqueda” y “entrenamiento” podían tratarse como si fueran el mismo tipo de rastreo empieza a quedar atrás.
Para los equipos SEO, esto implica una nueva responsabilidad: no basta con permitir o bloquear bots de IA de forma genérica. Hay que entender qué hace cada crawler, qué categoría tiene, qué reglas se le aplican y qué impacto puede tener en la visibilidad orgánica.
Si gestionas el acceso de crawlers a tu sitio web, revisa tus reglas de Training cuanto antes.
Porque una configuración mal ajustada podría terminar bloqueando algo más que el entrenamiento de modelos: podría afectar directamente a tu indexación en buscadores.
Información basada en la publicación Content Independence Day, one year on: building the business model for the agentic Internet
