Cloudflare se prepara para un cambio significativo que afectará a grandes porciones de la web, buscando proteger a editores y proveedores al situar el tráfico automatizado en tres categorías: búsqueda, agente o entrenamiento. El objetivo es dar a los clientes más control sobre cuánta actividad de bots están dispuestos a permitir.

A partir de septiembre de 2026, los nuevos dominios de Cloudflare bloquearán de forma predeterminada a rastreadores de agentes y de entrenamiento en páginas que muestran anuncios, argumentando que los editores necesitan visitantes humanos para generar ingresos publicitarios.

Sin embargo, existen importantes desafíos para implementar un sistema así. Muchos rastreadores relevantes, como Googlebot, son multipropósito y no encajan claramente en una de las tres categorías. En el peor de los casos, podría impedirse cualquier tráfico automatizado hacia un sitio, incluso si algunas categorías estuviesen permitidas.

Cloudflare vs. Google: una batalla en la que los editores podrían ser los verdaderos perdedores

Preocupa que Googlebot desempeñe un papel clave en el descubrimiento y la actualización de páginas para Google Search; bloquear su acceso podría afectar la indexación del contenido.

Las páginas que rechacen Googlebot por la razón de bloquear al menos una de esas tres categorías podrían perder visibilidad en búsquedas, con implicaciones comerciales relevantes.

A pesar de las desventajas de bloquear tráfico automatizado, muchos sostienen que hacerlo ayuda a proteger la propiedad intelectual, reduce la demanda de infraestructura de hosting ante picos de tráfico impredecibles y otorga a los propietarios mayor control sobre el uso de su información.

Andy Mollison, Director de Búsqueda e Innovación en Varn Search Marketing, describe la situación como un «juego de alto riesgo» entre Cloudflare y Google, pero más importante aún, como una situación en la que los editores terminan llevando la peor parte.

Conversé con Mollison para entender cómo deberían actuar editores y empresas para equilibrar la protección de su contenido con la visibilidad en línea.

• Aquí va una reflexión sobre si Google quiere que esto suceda para enviar un mensaje duro a quienes bloquean bots de IA. ¿Podría verse como una especie de desafío extremo entre sistemas?

Cloudflare y Google se encuentran en una especie de tanteo de alto riesgo. En papel parece desequilibrado, y en la práctica podría no favorecer a Cloudflare.

Una razón simple para que Google no ceda es que los únicos perdedores serían los clientes de Cloudflare, principalmente los editores.

La gente seguirá usando Google, sin notar que una parte sustancial de la web podría quedar fuera de los resultados de búsqueda. Por otro lado, los clientes de Cloudflare que dependan de ingresos por anuncios podrían ver un descenso abrupto del tráfico.

La meta podría ser loable: permitir que los editores protejan su contenido frente a usos indebidos por IA. Sin embargo, establecer la opción por defecto de «bloquear todos los bots de IA» podría dañar a quienes no pueden seguir cada movimiento de Cloudflare, pagando el precio final.

• ¿Cuál es el peor escenario para editores, B2B, marcas de consumo y, en última instancia, para los consumidores?

El escenario más negativo es que todas las páginas con anuncios que utilizan Cloudflare queden bloqueadas para Google Search, reduciendo notablemente la visibilidad orgánica y, como consecuencia, los ingresos por publicidad y acuerdos de afiliados.

Los consumidores podrían no notar de inmediato, pero con el tiempo podrían cuestionar por qué dejan de ver resultados de ciertos editores.

• Cloudflare, en su Día de la Independencia de Contenidos, explicó la lógica detrás de la decisión mientras concede soberanía a los editores; ¿por qué adopta esta postura?

La respuesta, en resumen, es económica. El CEO de Cloudflare afirmó que, por primera vez en la historia de internet, las máquinas generan más tráfico que las personas. Los rastreadores de IA consumen una gran parte del presupuesto de rastreo en los servidores, por lo que Cloudflare necesita más recursos para gestionarlo.

El costo es tal vez la razón principal, aunque la autonomía es otra capa: Cloudflare quiere dar a los editores la capacidad de decidir el nivel de indexación que reciben sus contenidos, según la finalidad del robot de IA. Por ejemplo, podría bloquearse el contenido para su inclusión en modelos de entrenamiento de IA, pero seguir disponible para búsquedas en plataformas de IA a nivel de página.

• ¿Muestras contradictorias de Google y por qué es difícil entenderlas?

Es un tema técnico; Cloudflare ha promovido con insistencia un archivo llms.txt para indicar qué partes del sitio pueden ser abiertas a rastreadores de IA. Esto podría aclarar qué se permite y qué no. En cambio, Google afirma que no recomienda usar llms.txt en su orientación para desarrolladores, pero también ha creado documentación en su guía de Agencia de Navegación sobre cómo configurar llms.txt.

La confusión radica en que Google dice no usar llms.txt, pero proporciona documentación para su uso. Esto genera una desalineación entre los equipos de desarrollo de Google y dificulta a los dueños de sitios saber qué postura adoptar. Si Google puede rastrear sin el archivo, o si lo necesita, no puede ser ambas cosas a la vez.

• ¿Por qué querrían las marcas y editores bloquear el tráfico de IA?

Una gran parte de las búsquedas ya no termina en clics, lo que para los editores implica una caída notable del tráfico y, por ende, de los ingresos por anuncios y afiliados. Por tanto, bloquear su contenido de cara a IA podría parecer una estrategia para forzar la visita directa. Sin embargo, es probable que los usuarios sigan empleando búsquedas de IA y que obtengan información de otras fuentes, haciéndose más perjudicial que beneficioso.

• ¿Otros actores podrían unirse a este enfoque?

A día de hoy, no hay confirmación definitiva de que Akamai, Amazon u otros proveedores sigan el mismo camino. Cloudflare parece aprovechar la situación para diferenciarse y generar ruido. Habrá que esperar para ver si la medida se generaliza.