Cloudflare puede bloquear Googlebot si bloqueas crawlers de entrenamiento IA
Una regla para frenar rastreadores de entrenamiento puede afectar también al rastreo que necesitas para Search. El detalle está en la capa donde aplicas el bloqueo.
Mañana, 15 de septiembre de 2026, Cloudflare cambia el comportamiento de sus controles para crawlers de IA. El punto realmente importante para SEO no es que vaya a “bloquear la IA por defecto”, que sería una simplificación bastante torpe. Lo relevante es que Cloudflare aplicará la regla más restrictiva a los crawlers que considera de uso mixto, entre ellos Googlebot, BingBot y Applebot.
Eso significa que una configuración pensada para bloquear crawlers de Training puede terminar bloqueando también a Googlebot. No es una hipótesis de terceros. Cloudflare lo dice expresamente en su documentación.
Para un SEO técnico, la consecuencia es importante: el control de rastreo ya no está únicamente en robots.txt, meta robots o Search Console. También puede estar en la capa CDN/WAF, antes de que la petición llegue siquiera al servidor de origen.
Contexto
Durante años hemos tratado el rastreo de buscadores como una relación relativamente clara: Googlebot solicita una URL, el servidor responde, robots.txt define qué puede rastrear y las directivas de indexación controlan qué puede aparecer en Search.
La llegada de los sistemas de IA ha añadido otra capa. Ya no todos los bots rastrean con la misma finalidad. Un crawler puede buscar información para indexarla, otro puede recopilar contenido para entrenamiento y otro puede acceder a una web en tiempo real en nombre de un usuario.
Cloudflare ha decidido clasificar ese tráfico por comportamiento:
- Search: crawlers que recopilan o indexan contenido para responder preguntas posteriormente.
- Agent: sistemas automatizados que actúan en tiempo real en nombre de una persona.
- Training: crawlers que recopilan contenido para entrenar o ajustar modelos.
El problema aparece cuando un mismo crawler realiza más de una función.
Qué cambia exactamente el 15 de septiembre de 2026
Cloudflare anunció el 1 de julio de 2026 que, a partir del 15 de septiembre, los nuevos dominios que entren en Cloudflare tendrán Training y Agent bloqueados por defecto en las páginas que muestren publicidad. Search seguirá permitido.
El cambio también se extiende a clientes Free existentes que no hayan modificado previamente esa configuración.
Hasta aquí, el impacto SEO sería limitado y bastante lógico: se diferencia entre rastreo para descubrimiento y rastreo para entrenamiento.
La parte crítica está en los crawlers multipropósito.
Cloudflare establece que cuando un crawler participa en varias categorías se aplicará la regla más restrictiva. La compañía cita expresamente a Googlebot, Applebot y BingBot como ejemplos de crawlers que combinan Search con Training.
Por tanto, si un sitio configura Training como bloqueado, Cloudflare puede bloquear también Googlebot.
Hechos confirmados
- Cloudflare separa el tráfico automatizado en Search, Agent y Training. Esto forma parte de sus nuevos controles de AI Crawl Control y está documentado oficialmente.
- Search permanece permitido por defecto. El cambio no consiste en bloquear los motores de búsqueda de forma general. Cloudflare deja Search permitido por defecto y bloquea Training y Agent en determinadas configuraciones y páginas.
- Los crawlers multipropósito se someten a la regla más restrictiva. Cloudflare afirma que Googlebot, Applebot y BingBot pueden ser tratados como crawlers multipropósito.
- Bloquear Training puede terminar bloqueando Googlebot. Cloudflare indica que los clientes que seleccionen bloquear Training también bloquearán crawlers multipropósito que participen en esa categoría, incluido Googlebot, salvo que configuren la excepción correspondiente.
- Google ofrece Google-Extended como control separado. Google explica que Google-Extended permite limitar determinados usos del contenido en Gemini y Vertex AI sin afectar a la inclusión del sitio en Google Search ni actuar como señal de ranking.
- Google Search y las funciones de IA de Search siguen dependiendo de Googlebot. La documentación de Google sobre AI Overviews y AI Mode indica que una página debe estar indexada y ser elegible para mostrarse en Google Search. Google recomienda expresamente permitir el rastreo en robots.txt y también en la infraestructura CDN o de hosting.
La diferencia técnica que importa: robots.txt frente a la capa de red
Aquí está la parte más interesante para SEO técnico.
Google-Extended es una preferencia de uso. No es un crawler HTTP independiente. Google indica que no tiene su propio user-agent de petición. El rastreo puede realizarse mediante los user-agents existentes de Google y Google-Extended actúa como token de control.
Eso permite una separación lógica:
Googlebot puede seguir rastreando para Search.
Google-Extended puede indicar que determinados usos relacionados con Gemini no están permitidos.
Cloudflare opera en otro nivel.
Si Cloudflare decide bloquear una petición de Googlebot en el edge porque ese crawler también está clasificado como Training, Googlebot no llega al origen. No hay documento que procesar, ni robots.txt que interpretar después, ni HTML que renderizar.
Para un SEO esto cambia el orden mental del diagnóstico:
Llevamos años entrando demasiado pronto en la cadena y mirando robots.txt, canonicals o noindex. Con la proliferación de controles anti-bot, eso ya no basta.
Qué se ha interpretado fuera de las fuentes oficiales
Diversos análisis SEO han descrito el cambio como una “trampa” para Googlebot o como un cambio que podría sacar sitios de Google.
La idea general es correcta, pero conviene evitar dos exageraciones.
Primera exageración: “Cloudflare bloqueará Googlebot por defecto”.
No exactamente.
El nuevo comportamiento depende de la configuración del dominio, del tipo de cuenta, de si se han cambiado previamente los ajustes y, en el caso de los nuevos defaults, de páginas que muestran publicidad. Un sitio de pago existente que no haya bloqueado Training no debería asumir que mañana dejará de ser rastreado.
Segunda exageración: “Bloquear IA equivale a desaparecer de Google”.
Tampoco.
Depende de qué se esté bloqueando. Es perfectamente posible expresar preferencias sobre entrenamiento mediante mecanismos como Google-Extended sin impedir el rastreo normal de Googlebot.
La interpretación más útil es otra: una configuración de infraestructura pensada para controlar IA puede tener efectos secundarios sobre SEO si el proveedor agrupa varios usos detrás del mismo crawler.
Cómo yo lo veo
Este cambio tiene más valor como señal de arquitectura que como noticia puntual.
Durante mucho tiempo, los equipos SEO han considerado la infraestructura anti-bot como una preocupación de sistemas o seguridad. Eso ya no es sostenible.
Cloudflare, Akamai, Fastly, Imperva o cualquier capa de protección situada delante del servidor pueden modificar la accesibilidad real de los crawlers. Además, con la aparición de agentes, bots de búsqueda, crawlers de entrenamiento y crawlers de uso mixto, esas reglas serán cada vez más complejas.
La consecuencia es clara: la auditoría SEO técnica debería incorporar una revisión explícita de políticas de bots en CDN y WAF.
No basta con validar robots.txt.
Implicaciones prácticas para SEO técnico
Primero, revisar la configuración real en Cloudflare.
Especialmente:
- AI Crawl Control.
- Configuración de Search, Agent y Training.
- Legacy “Block AI bots”.
- Excepciones para crawlers multipropósito.
- Reglas personalizadas de WAF o Bot Management.
Segundo, comprobar acceso desde Google.
Después del cambio conviene revisar:
- Search Console Crawl Stats.
- URL Inspection sobre páginas importantes.
- Logs del servidor.
- Cloudflare Security Events.
- Errores 403 o 429 asociados a crawlers verificados.
Hay que recordar algo incómodo: si Cloudflare bloquea la petición antes del origen, puede no aparecer nada en los logs del servidor. La ausencia de Googlebot también es una señal.
Tercero, verificar que Googlebot sea realmente Googlebot.
El user-agent se puede falsificar. Para investigar bloqueos o crear excepciones conviene utilizar los mecanismos oficiales de verificación de Google, como rangos IP publicados o reverse DNS.
Cuarto, separar decisiones de Search y Training.
Si el objetivo del negocio es mantener visibilidad orgánica pero limitar el entrenamiento de modelos, bloquear Googlebot en el edge es una solución demasiado agresiva.
Google-Extended existe precisamente para separar algunos de esos usos sin afectar a Search.
Quinto, documentar estas políticas como parte de SEO.
Un cambio de seguridad realizado por IT puede provocar una caída orgánica semanas después y acabar diagnosticándose como si fuera un problema de contenido, indexación o algoritmo. El clásico deporte corporativo de que cada equipo rompa algo que pertenece al otro.
Aplicación a comparadores, travel y car rental
Aquí sí existe una relación directa.
Los comparadores y webs de travel suelen tener tres características:
- muchas URLs transaccionales;
- gran dependencia del rastreo frecuente;
- infraestructura CDN y protección anti-bot relativamente agresiva.
En car rental, además, las páginas de destino pueden depender de inventario, precios, aeropuertos, oficinas y combinaciones geográficas que cambian con frecuencia.
Una reducción importante del rastreo de Googlebot puede tardar en convertirse en pérdida de rankings, pero antes puede provocar otros síntomas:
- actualización más lenta de páginas;
- reprocesamiento más lento de canonicals;
- menor velocidad para descubrir nuevas rutas o destinos;
- retraso en cambios de títulos, contenido o enlazado interno;
- problemas en grandes arquitecturas programáticas donde Google necesita rastrear millones de combinaciones.
Para un comparador grande, yo añadiría una alerta específica de crawl health.
No solo “¿Google está indexando?”, sino:
- ¿cuántas peticiones verificadas de Googlebot recibimos al día?
- ¿qué códigos reciben?
- ¿qué porcentaje llega a categorías, destinos y fichas transaccionales?
- ¿ha cambiado el patrón tras una modificación de CDN, WAF o bot management?
En webs grandes, detectar una caída de rastreo el día uno es mucho más barato que detectarla a través de una caída de tráfico tres semanas después.
Qué haría hoy
- Identificar todos los dominios detrás de Cloudflare.
- Revisar AI Crawl Control antes del 15 de septiembre.
- Confirmar que Search está permitido.
- Revisar cualquier bloqueo de Training y comprobar cómo trata los crawlers multipropósito.
- Revisar el antiguo ajuste “Block AI bots” si sigue activo.
- Tomar una línea base de Crawl Stats y, si existen, logs de Googlebot de los últimos siete días.
- Repetir la comparación entre el 16 y el 18 de septiembre.
Para acabar el café
La noticia no es que Cloudflare “vaya a bloquear Google”.
La noticia útil para SEO es que una política pensada para controlar el uso de contenido por sistemas de IA puede impedir el rastreo del buscador si se aplica en una capa de infraestructura que no puede separar las distintas funciones de un mismo crawler.
Google intenta separar esos usos mediante controles como Google-Extended.
Cloudflare intenta separarlos clasificando el comportamiento de los crawlers.
Cuando ambas taxonomías no encajan, el riesgo cae sobre el propietario del sitio.
Para SEO técnico, la lección es bastante concreta: a partir de ahora, revisar acceso de crawlers significa revisar robots.txt, pero también CDN, WAF, bot management y logs de edge.
Fuentes y lecturas
Cloudflare Blog. “Your site, your rules: new AI traffic options for all customers” - https://blog.cloudflare.com/content-independence-day-ai-options/
Cloudflare Developers. “Block AI Bots” - https://developers.cloudflare.com/bots/additional-configurations/block-ai-bots/
Cloudflare Press Release. “Cloudflare Allows the Agentic Internet to Flourish with a Simple Philosophy: Your Content, Your Rules” - https://www.cloudflare.com/press/press-releases/2026/cloudflare-allows-the-agentic-internet-to-flourish-with-a-simple-philosophy-your-content-your-rules/
Google Search Central. “AI features and your website” - https://developers.google.com/search/docs/appearance/ai-features
Google Crawling Infrastructure. “Google’s common crawlers” - https://developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers
Google Crawling Infrastructure. “Things to Know about Google’s Web Crawling” - https://developers.google.com/crawling/docs/about-crawling
Lectura secundaria: Lalit Patel. “Cloudflare’s 15 September AI crawler change could block Googlebot. Here’s what to check” - https://lalitondigital.com/blog/cloudflare-ai-crawler-change-googlebot/