Esta semana abrí el robots.txt de mi propio sitio. No el del repositorio. El que imlola.xyz sirve de verdad. No son el mismo archivo.
El que escribí yo arranca con un comentario que dice que el sitio está abierto a buscadores y a crawlers de IA por igual, y después lista a GPTBot, ClaudeBot, Google-Extended, PerplexityBot y más de una docena de otros, cada uno con Allow: /. Este sitio existe para que lo lean y lo citen, y ese archivo lo dice explícitamente. La versión que se sirve tiene un bloque extra arriba, encerrado entre dos comentarios que dicen BEGIN Cloudflare Managed content y END Cloudflare Managed Content. Ese bloque declara Content-Signal: search=yes,ai-train=no,use=reference para todos los user agents, y después pone Disallow: / para Amazonbot, Applebot-Extended, Bytespider, CCBot, ClaudeBot, CloudflareBrowserRenderingCrawler, Google-Extended, GPTBot y meta-externalagent.
Leído de arriba a abajo, el mismo archivo le dice a GPTBot que no rastree nada y después le dice que rastree todo. Search Console no muestra ningún problema. Nada parece roto. Es exactamente el tipo de configuración que queda puesta durante años.
Lo escribo ahora porque mañana, 15 de septiembre, Cloudflare cambia los defaults detrás de ese bloque, y las reglas nuevas tienen un efecto secundario que va mucho más allá de un archivo de texto contradictorio.
Qué cambia en Cloudflare el 15 de septiembre
En un post publicado el 1 de julio, Cloudflare reemplazó la vieja pregunta de sí o no sobre bloquear bots de IA por tres categorías definidas por comportamiento. Search es "cualquier comportamiento que recolecta o indexa tu contenido para poder responder preguntas sobre él más adelante". Agent es "comportamiento automatizado que actúa, normalmente en tiempo real, en nombre de una persona, para resolver algo en ese momento". Training es "un crawler que toma tu contenido para entrenar o ajustar un modelo".
Desde el 15 de septiembre de 2026, todo dominio nuevo que se suma a Cloudflare tiene Training y Agent bloqueados por defecto en las páginas que muestran anuncios, mientras Search sigue permitido. El argumento que da Cloudflare es corto: "Un anuncio es una señal de que el dueño del sitio quería que una persona llegara ahí y lo viera." Los clientes existentes que no quieran los defaults nuevos pueden excluirse desde su configuración de Seguridad en cualquier momento antes de esa fecha.
El peso del cambio viene de la escala. Cloudflare describe su alcance como "más del 20% de los dominios web que están detrás de Cloudflare". Cuando una red de ese tamaño cambia un default, deja de ser una configuración. Se vuelve una norma.
Hasta acá se lee como una medida razonable para proteger a los publishers de que los rastreen gratis. La complicación está en una oración más abajo, en el mismo post.
Por qué Googlebot termina del lado bloqueado
"Como los defaults se aplican con las reglas más restrictivas que correspondan, los crawlers multipropósito como Googlebot, Applebot y BingBot van a quedar bloqueados por los clientes que hayan elegido bloquear Training." Esa es la redacción de Cloudflare, no la interpretación de un crítico.
El mecanismo es simple una vez que se lo ve entero. Cloudflare clasifica a Googlebot como un crawler que hace Search y Training. Cuando un sitio bloquea Training, gana la regla más restrictiva, y el mismo crawler que indexa el sitio para Google Search queda bloqueado junto con el resto. La consecuencia no es rankear más abajo. Es no ser rastreado.
Una versión de esto ya había aparecido antes de la fecha. En agosto, Search Engine Journal contó el caso de un usuario de r/TechSEO que escribió que cuando puso AI Training en Block, "tanto Googlebot como Bingbot empezaron a recibir respuestas HTTP 403 al intentar leer mi sitemap". Es un solo reporte, y la propia SEJ aclaró que no estaba claro si era un bug, un error de configuración o las reglas nuevas llegando antes de tiempo. Pero describe exactamente el mecanismo que Cloudflare anunció.
La posición de Cloudflare es que la solución les corresponde a las empresas que operan los crawlers, y en el mismo post las alienta con fuerza a separar sus crawlers por propósito. Al momento de escribir esto, no encontré ningún anuncio de Google, Apple ni Microsoft diciendo que lo hayan hecho.
Google ya traza esa línea, pero en otro lugar
Lo irónico es que Google sí tiene una separación. Solo que no coincide con las categorías de Cloudflare. Según la documentación de crawlers de Google, Google-Extended es un token que los publishers pueden usar para decidir si el contenido que Google rastrea en sus sitios puede usarse para entrenar futuras generaciones de Gemini y para grounding. La misma página es explícita sobre lo que no hace: "Google-Extended no afecta la inclusión de un sitio en Google Search ni se usa como señal de ranking en Google Search."
Lo que Google-Extended no controla es AI Overviews ni AI Mode. La documentación de Google sobre funciones de IA dice que para poder aparecer como link de soporte ahí, "una página tiene que estar indexada y ser elegible para mostrarse en Google Search con un snippet". Para limitar lo que aparece en esas funciones, las herramientas son las mismas que limitan un resultado normal: nosnippet, data-nosnippet, max-snippet y noindex.
O sea que en el modelo de Google, la búsqueda generativa es parte de Search. Es coherente con lo que Google escribió en mayo en su guía para optimizar para funciones de IA generativa: "optimizar para la búsqueda con IA generativa es optimizar para la experiencia de búsqueda, y por lo tanto sigue siendo SEO". En el modelo de Cloudflare, Googlebot también hace Training, así que bloquear Training lo alcanza. Cada modelo es coherente en sus propios términos. Simplemente no encajan entre sí, y el dueño del sitio queda en el hueco.
| Control | Sobre qué actúa | Pedido o impuesto | Efecto en Google Search |
|---|---|---|---|
Disallow en robots.txt para un bot puntual | El crawler lee la regla y decide si la respeta | Pedido. El RFC 9309 dice que estas reglas "no son una forma de autorización de acceso" | Ninguno, salvo que bloquees al propio Googlebot |
Content-Signal en robots.txt | Una declaración de usos permitidos: search, ai-input, ai-train | Pedido. El parser de Google ignora reglas que no sean allow, disallow y user-agent | Ninguno directo |
| Token Google-Extended | Entrenamiento de Gemini y grounding | Pedido, documentado por Google | Ninguno, según la documentación de Google |
nosnippet, max-snippet, noindex | Cómo aparece la página en Search, incluidos AI Overviews y AI Mode | Documentado por Google como el control para funciones de IA | También reduce o elimina tu presencia en los resultados normales |
| Bloquear Training en Cloudflare | La solicitud misma, en la red, antes de llegar a tu servidor | Impuesto | Puede bloquear a Googlebot, porque Cloudflare lo trata como multipropósito |
Qué pasa cuando un archivo dice sí y no al mismo tiempo
Vuelvo a mi robots.txt. La respuesta formal está en el RFC 9309, el estándar que define el protocolo. La sección 2.2.1 dice que si hay más de un grupo que coincide con el mismo user agent, sus reglas "DEBEN combinarse en un solo grupo" (MUST, en el original). La sección 2.2.2 dice que cuando una regla allow y una disallow son equivalentes, "DEBERÍA usarse la regla allow" (SHOULD). Google documenta el mismo comportamiento para sus crawlers: combina los grupos y, "ante reglas en conflicto, Google usa la regla menos restrictiva".
Aplicado a mi caso, Google lee Google-Extended como permitido, porque mi Allow: / y el Disallow: / de Cloudflare tienen la misma ruta y gana la regla permisiva. Para cualquier otro crawler, el resultado depende de cómo cada uno implementó un SHOULD, y desde afuera no hay forma de verificarlo. Un parser que se queda con el primer grupo que coincide con su nombre leería el bloque de Cloudflare y nunca llegaría al mío.
La misma lógica explica por qué la línea Content-Signal no cambia nada para Google en particular. El parser de Google solo procesa allow, disallow y user-agent, e ignora el resto. La señal sigue significando algo, pero como declaración de condiciones, no como una regla de rastreo que Googlebot aplica.
Un robots.txt contradictorio no falla. Funciona distinto para cada lector. Eso es peor.
Por qué esto es una decisión de GEO, no solo de seguridad
El impulso de bloquear el entrenamiento es racional, y vale la pena ser claros sobre por qué. En un análisis que Cloudflare publicó en 2025, sobre la semana del 19 al 26 de junio de ese año, los crawlers de Anthropic hicieron casi 71.000 solicitudes de páginas HTML por cada visita que devolvieron. Cloudflare agregó su propia salvedad: el tráfico que llega desde la app nativa de Claude no incluye el header Referer, así que parte de lo que vuelve es invisible para esa medición. Aun así, un publisher que mira un ratio así, la versión más extrema del problema que describí en zero-click no es el problema, es el canal nuevo, tiene buenas razones para querer cerrar la puerta.
El problema es que la IA no es una sola puerta. OpenAI documenta tres agentes separados. GPTBot rastrea contenido que puede usarse para entrenar sus modelos. OAI-SearchBot se usa "para mostrar sitios web en los resultados de búsqueda de las funciones de búsqueda de ChatGPT". ChatGPT-User visita una página cuando alguien le pregunta a ChatGPT algo que la necesita. Bloquear GPTBot le dice a OpenAI que no entrene con tu contenido, pero no es el interruptor para aparecer en la búsqueda de ChatGPT. Ese es OAI-SearchBot.
Anthropic separa sus agentes de la misma forma. ClaudeBot recolecta contenido web que podría contribuir al entrenamiento. Claude-SearchBot rastrea para mejorar la calidad de los resultados de búsqueda. Claude-User lee páginas cuando una persona le hace una pregunta a Claude. Según Anthropic, bloquear esos dos últimos reduce la visibilidad del sitio en las respuestas que reciben los usuarios.
Ahí está toda la decisión. Entrenamiento, indexación para búsqueda y recuperación en tiempo real son tres usos distintos, y cada empresa los separa a su manera. El robots.txt gestionado de Cloudflare, hay que reconocerlo, bloquea una lista de agentes que asocia con entrenamiento, y no incluye a OAI-SearchBot, a Claude-SearchBot ni a los agentes que actúan por pedido de un usuario. Es un diseño sensato. El bloqueo de Training a nivel de red llega más lejos, porque Googlebot no tiene un gemelo dedicado solo a entrenamiento que se pueda bloquear en su lugar.
Hace unas semanas escribí que SEO y GEO no son canales distintos, que responden a las mismas señales con distinto énfasis. Esto es el mismo argumento visto desde la infraestructura. Durante años, proteger el contenido de la IA y aparecer en Google fueron dos interruptores separados. En un sitio detrás de Cloudflare que elige bloquear Training, ahora están conectados al mismo.
Qué mirar antes y después del 15 de septiembre
Lo primero es el robots.txt que tu dominio sirve de verdad, no el de tu repositorio o tu CMS. Si el bloque gestionado de Cloudflare está ahí, empieza con ese comentario BEGIN Cloudflare Managed content. La documentación de Cloudflare confirma que antepone su archivo gestionado "antes de tu robots.txt existente, combinando ambos en una sola respuesta". La opción que lo controla está en la configuración de Seguridad, entre las opciones de tráfico de bots, como la preferencia de bloquear el entrenamiento en robots.txt.
Lo segundo es separar dos cosas que suenan parecido y no lo son. Un robots.txt gestionado pide. Un bloqueo de Training en AI Crawl Control impone. El primero no puede frenar a Googlebot, porque Googlebot no está en su lista y robots.txt es voluntario de todas formas. El segundo sí puede, por cómo Cloudflare clasifica a Googlebot.
Lo tercero es decidir qué querés evitar en realidad, porque cada objetivo tiene su propio control. Mantener el contenido fuera del entrenamiento de Gemini es para lo que existe Google-Extended, sin tocar Search. Mantenerlo fuera de AI Overviews implica controles de snippet, con el costo de cambiar también cómo se ven los resultados normales. No entrar en el entrenamiento de modelos en general pero seguir siendo citado en respuestas de ChatGPT o Claude es la diferencia entre GPTBot y OAI-SearchBot, o entre ClaudeBot y Claude-SearchBot. Ninguno de esos objetivos requiere bloquear un crawler multipropósito a nivel de red.
En mi caso la decisión ya estaba tomada, y escrita en un comentario al principio del archivo: este sitio existe para ser citado. Lo que faltaba era verificar que el archivo que se sirve coincidiera con el que se escribió.
El default decide por quienes no miran
El argumento de Cloudflare sobre los anuncios se sostiene, y presionar a quienes operan crawlers para que separen sus usos probablemente sea el tipo de presión correcta. Pero los defaults no son neutrales. Un sitio nuevo que se sume a Cloudflare después de mañana, con anuncios en sus páginas, arranca desde una configuración que no eligió. Y cualquiera que, por razones perfectamente válidas, ponga Training en Block puede terminar bloqueando a Googlebot también, con un sitemap devolviendo 403 como una de las primeras señales visibles.
Search Console lo va a mostrar tarde o temprano. El robots.txt ya muestra parte de la historia hoy. Solo hay que abrir el que se sirve de verdad.