El dilema que rompió la web abierta
Durante años, los dueños de sitios vivieron un trade-off cruel: dejar que los crawlers de uso mixto (Applebot, Googlebot, Bingbot) indexaran tu contenido para búsqueda — lo que también significaba permitir entrenamiento de modelos — o bloquear todo y perder visibilidad en Google.
Es un pésimo trato. Menos del 1% de los sitios en Cloudflare bloquean bots de búsqueda, pero el 17% intenta activamente bloquear entrenamiento. Esa diferencia lo dice todo: los publishers quieren ser encontrados, solo no quieren ser consumidos.
El problema es estructural. Una directiva en robots.txt es solo una petición educada. No identifica quién está rastreando, no clasifica por qué, y no detiene a un crawler que simplemente la ignora. La respuesta de Cloudflare es resolverlo en la capa de red — publicar la preferencia, identificar el crawler, clasificar la intención, bloquear a los que ignoran, y reportar en Radar lo que cada operador realmente hace.
Qué cambió de verdad el 15 de septiembre
Cloudflare retiró el viejo toggle "Block AI Bots" y puso en su lugar tres controles granulares, aplicados a nivel de dominio (zona):
- Search — rastreo para construir índice de búsqueda
- Training — rastreo para entrenar o hacer fine-tune de un modelo
- Agent — agentes dirigidos por el usuario que buscan páginas en nombre de un humano
La configuración nueva que importa es Disallow AI Training. Publica una directiva Disallow: vía Bot Preference Sync en tu robots.txt, mantiene a los crawlers de uso mixto Accountable habilitados para búsqueda, y bloquea a todo crawler exclusivo de entrenamiento (Amazon, Anthropic, Meta, OpenAI).
Tabla de migración (legado → nuevo)
| "Block AI" legado | Search | Training | Agent |
|---|---|---|---|
| Desactivado | Allow | Allow | Allow |
| Block | Allow | Disallow AI Training | Block on pages with ads |
| Block on pages with ads | Allow | Disallow AI Training | Block on pages with ads |
Si ya tenías Training configurado como Block o Block on pages with ads, ambos migran a Disallow AI Training — preservando el efecto práctico sin tumbar la búsqueda.
Presets recomendados para dominios nuevos
| Configuración | Sin monetización por anuncios | Con anuncios |
|---|---|---|
| Preference Sync | Activado | Activado |
| Search | Allow | Allow |
| Training | Allow | Disallow AI Training |
| Agent | Allow | Block on pages with ads |
Los sitios con anuncios reciben el preset más restrictivo porque el ingreso por anuncio requiere que un humano realmente llegue a la página. El entrenamiento reemplaza esa visita con una respuesta sintetizada; los agentes buscan la página sin nadie ahí para ver el anuncio.
Operador por operador: qué funciona hoy de verdad
No todos los crawlers "Accountable" son iguales. La designación reconoce tanto capacidades ya entregadas como compromisos con fecha límite — o sea, parte de esto es promesa hasta que llegue la fecha.
Applebot
Opt-out de entrenamiento vía regla Disallow para Applebot-Extended en robots.txt. Preferencias de AI Summary se pueden expresar vía directiva nosnippet en el HTML de la página. El contenido con paywall puede marcarse para excluirlo del output generativo.
Gap: Todavía no tiene herramienta de inspección a nivel de URL. Apple compartió detalles de una solución en progreso para el año que viene. Afirmaron que deshabilitar entrenamiento no impacta el ranking de búsqueda.
# robots.txt — opt-out de entrenamiento Applebot
User-agent: Applebot-Extended
Disallow: /
Googlebot
Opt-out vía Disallow para Google-Extended en robots.txt, más un toggle en Search Console para excluir contenido de los resultados generativos. Google provee métricas para búsqueda y para resultados de AI summary.
Gap: Herramientas de transparencia a nivel de URL para Google-Extended están "previstas para las próximas semanas" — todavía no entregadas.
# robots.txt — opt-out de entrenamiento Googlebot (búsqueda intacta)
User-agent: Google-Extended
Disallow: /
Bingbot
Hoy solo soporta opt-out de entrenamiento vía meta tag NOARCHIVE o la herramienta Block URLs / Content Removal de Microsoft. Preferencia de no-training vía robots.txt está prevista para principios de 2027.
Aviso crítico: Hasta que eso salga, seleccionar Disallow AI Training en Cloudflare no va a comunicar automáticamente una preferencia de no-training a Bing vía robots.txt. Es el mismo comportamiento práctico del viejo Training Block.
<!-- Opt-out de entrenamiento por página para Bingbot -->
<meta name="robots" content="NOARCHIVE">
Crawlers exclusivos de entrenamiento (Amazon, Anthropic, Meta, OpenAI)
Estos operadores separan sus crawlers de Search y Training, así que Cloudflare puede bloquear el de entrenamiento sin tocar la búsqueda. Sin dilema, sin negociación.
Limitaciones y lo que nadie está diciendo en voz alta
1. "Accountable" es designación de marketing, no estándar
Cloudflare inventó el término. No existe RFC del IETF para esto. Los requisitos son autodefinidos y la fiscalización es "vamos a monitorearlo en Radar". Es mejor que nada, pero no es un régimen de compliance.
2. El compromiso de Bing para 2027 es demasiado lejos
Si eres publisher y dependes de Disallow AI Training hoy, Bingbot sigue entrenando con tu contenido hasta que Microsoft entregue soporte a robots.txt. La meta tag NOARCHIVE es por página y fácil de olvidar.
3. AI Summaries es la mitad no resuelta
Los controles actuales son binarios: permites o bloqueas summaries. Cloudflare admite que es "instrumento bruto" y dice que el próximo foco es dejarte controlar cuánto de tu contenido aparece en un summary. Esa capacidad todavía no existe — es meta declarada para principios del año que viene.
4. Los datos de conversión cortan para los dos lados
Números de la propia Cloudflare: más de la mitad de los consumidores leen summaries en la Búsqueda, y esos consumidores tienen 40%+ más probabilidad de terminar su búsqueda después de leer uno. Pero el tráfico referido por IA convierte de 3× a 5× más que el tráfico de búsqueda tradicional. Menos visitas, más intención. Si eso es bueno o malo depende enteramente de tu modelo de negocio — un publisher financiado por impresiones de anuncio y un retailer DTC van a sacar conclusiones opuestas de los mismos datos.
5. Los agentes todavía no tienen directiva
No existe estándar establecido para expresar preferencias de Disallow a agentes. Cloudflare está esperando a que ai-prefs y propuestas similares maduren. Hasta entonces, el control de agente se limita a "Block on pages with ads" o nada.
Próximos pasos
- Audita tu configuración actual a nivel de dominio (zona) en Security Settings. Si nunca tocaste los controles granulares, fuiste migrado con base en tu estado legado de Block AI Bots — verifica que coincida con tu intención.
- Si quieres crawlers de uso mixto fuera por completo, ahora tienes que seleccionar Block explícitamente. Eso detiene a Applebot, Bingbot y Googlebot — búsqueda incluida.
- Sigue la especificación
ai-prefsen el IETF. Ahí es donde está pasando la batalla real de interoperabilidad. - Si construyes infraestructura adyacente a crawlers, lee el deep dive del AI SDK 7 para entender cómo los frameworks de agentes están evolucionando junto con estos controles.
- Para pipelines de embedding multilingüe y RAG que ingieren contenido web, el breakdown del IBM Granite Embedding Multilingual R2 cubre las implicaciones del lado del modelo en las restricciones de datos de entrenamiento.
Resumiendo
El Disallow AI Training de Cloudflare es el primer intento serio de romper el falso binario entre "indexado" y "entrenado". El mecanismo técnico — clasificación a nivel de red + sincronización de preferencia en robots.txt — tiene la forma correcta. Los gaps son reales: la fecha de 2027 de Bing, la transparencia a nivel de URL que falta de Apple y Google, y el problema completamente no resuelto de los AI Summaries.
Si operas un sitio de contenido, la acción inmediata es simple: verifica tu configuración migrada y, si monetizas con anuncios, asegúrate de que Disallow AI Training esté activado. Si construyes sobre datos de crawler, empieza a diseñar para un mundo donde el acceso de entrenamiento es opt-in, no default.