Cloudflare bloquea los crawlers de IA por defecto: qué significa para tu sitio
Cloudflare pasó a bloquear crawlers de IA por defecto en julio de 2025 y aplica nuevos valores por defecto a las páginas con publicidad el 15 de septiembre de 2026. Qué cambió, cuánto te cuesta en citas de IA y cómo permitir y verificar los crawlers que sí quieres.
Si tu dominio llegó a Cloudflare después del 1 de julio de 2025, es muy probable que los crawlers de IA estén bloqueados y que nadie te avisara. Ese día Cloudflare puso los dominios nuevos en denegación por defecto, en septiembre de 2025 añadió un vocabulario de robots.txt para el uso del contenido, y a partir del 15 de septiembre de 2026 bloquea por defecto el tráfico de entrenamiento y de agente en las páginas con publicidad. La respuesta correcta no es volver a encenderlo todo. Es elegir por nombre los crawlers que quieres y después comprobar que las peticiones que llevan esos nombres son auténticas.
Qué cambió Cloudflare en realidad, y cuándo
1 de julio de 2025. Cloudflare proclamó el Content Independence Day y se convirtió en el primer gran proveedor de infraestructura que bloquea crawlers de IA por defecto. Su nota de prensa de ese día describía el giro sin rodeos: los dominios nuevos de la red deniegan el acceso a los crawlers de IA salvo que el propietario lo habilite de forma explícita. De opt-out a opt-in. Cloudflare sitúa su propia cuota de tráfico web en torno al 20 por ciento, así que un único cambio de valor por defecto movió una porción grande de la web de golpe. Más de un millón de clientes existentes ya habían activado el bloqueo de un clic desde septiembre de 2024. Junto a ello llegó Pay Per Crawl en beta, que permite responder a un crawler con un HTTP 402 Payment Required en lugar de contenido.
El argumento de Cloudflare era una proporción. Midiendo el tráfico de junio de 2025, situó la relación entre rastreos y visitas devueltas en 1.700:1 para OpenAI y 73.000:1 para Anthropic, frente a 14:1 en la búsqueda de Google. Muchísima descarga, muy poco tráfico de vuelta.
28 de agosto de 2025. La beta AI Audit pasó a llamarse AI Crawl Control y salió a disponibilidad general: una vista por crawler de quién descargó qué, interruptores de allow y block por operador, y respuestas 402 personalizadas en los planes de pago.
24 de septiembre de 2025. Cloudflare publicó la Content Signals Policy bajo licencia CC0, con un generador en ContentSignals.org. Añade a robots.txt una línea que describe cómo puede usarse el contenido después de obtenerlo, algo que robots.txt nunca cubrió. Tres señales, cada una en yes, no o sin valor:
User-Agent: *
Content-Signal: search=yes, ai-train=no
Allow: /
Cloudflare escribió esa política en el robots.txt gestionado de más de 3,8 millones de dominios. Donde
el entrenamiento ya estaba bloqueado, el valor por defecto publicado fue search=yes, ai-train=no,
dejando ai-input deliberadamente sin valor en lugar de denegado.
1 de julio de 2026. Cloudflare dividió el comportamiento de los bots en tres clasificaciones y las
puso a disposición de todos los clientes, incluido el plan gratuito: Search (recoger e indexar
contenido para responder preguntas más tarde), Agent (actuar en tiempo real en nombre de una persona)
y Training (tomar contenido para entrenar o afinar un modelo). También fijó una fecha. El
15 de septiembre de 2026 Search sigue permitido por defecto, mientras que Training y Agent quedan
bloqueados por defecto en las páginas que muestran publicidad. Esos valores se aplican a clientes
nuevos, a sitios nuevos de clientes existentes y a cuentas del plan gratuito que no hayan cambiado la
opción antes de la fecha límite. Un crawler que mezcla propósitos sin separarlos se rige por la regla
más restrictiva aplicable a cualquiera de sus comportamientos. Content Signals ganó un cuarto
parámetro, use=, con los valores immediate, reference y full. Y Pay Per Crawl se convirtió en
Pay Per Use, que paga cuando el contenido aparece de verdad en una respuesta en lugar de cuando un bot
descarga una página, con Ceramic.ai y You.com como primeros socios.
| Control | Dónde vive | Qué hace en realidad |
|---|---|---|
| robots.txt gestionado | Panel de Cloudflare, gratis | Publica una petición. Los crawlers que cumplen la respetan, otros la ignoran |
Content Signals (search, ai-input, ai-train, use) | Línea en robots.txt | Declara los usos permitidos tras la descarga. Sigue siendo una petición, no un bloqueo |
| Interruptor Block AI Bots | Ajustes de seguridad | Aplicación en el edge. Amplia y tosca |
| AI Crawl Control | Panel propio | Allow, block o 402 por crawler, aplicado antes de que tu origen vea la petición |
| Valores por defecto de Search / Agent / Training | Se aplican desde el 15 de septiembre de 2026 | Aplicación por categoría, primero en páginas con publicidad |
| Pay Per Use | Programa de adhesión | Pago cuando tu contenido aparece en una respuesta |
El coste que nunca sale en tus analíticas
Un crawler bloqueado no genera una página de error que vayas a mirar nunca. Ni rebote, ni 500, ni ticket de soporte. El asistente simplemente responde con la página de otro, y tú te enteras meses después, cuando el citado es un competidor.
Esto pesa más cada trimestre. El artículo de Cloudflare del 6 de agosto de 2026 sobre answer engine optimisation señalaba que menos de la mitad de todas las peticiones de páginas HTML provienen ya de un humano. Si los bots de recuperación no llegan a tu documentación, tu página de precios o tus comparativas, faltas en el conjunto de fuentes del que tiran los motores de respuesta. Bloquear un crawler de entrenamiento y bloquear uno de recuperación parecen el mismo interruptor en un panel. No son la misma decisión, y solo una de ellas protege algo que te importa.
La distinción que conviene interiorizar: los crawlers de entrenamiento se llevan tu contenido una vez y no devuelven nada por petición. El tráfico de recuperación y de agente es un lector que llega con una pregunta ahora mismo. GPTBot entrena. OAI-SearchBot indexa para respuestas. ChatGPT-User descarga una página porque una persona preguntó por ella hace treinta segundos. La misma empresa, tres tokens, tres intercambios muy distintos.
robots.txt es una petición. El edge es una decisión.
Esta es la línea que la mayoría de propietarios difumina. Disallow: / en robots.txt es un cartel en
la puerta. Los operadores serios lo leen y se dan la vuelta. El resto lo lee como una lista de rutas
interesantes, o no lo lee. Content Signals pertenece a la misma categoría: una declaración de
intenciones clara y legible por máquina cuyo valor es más jurídico y social que técnico.
Los controles de Cloudflare están una capa más abajo. La petición se rechaza en el edge antes de que tu origen la vea, con independencia de lo que el cliente creyera sobre robots.txt. Eso es realmente útil, y por eso mismo el valor por defecto pesa tanto. Una preferencia que nunca expresaste se está aplicando ahora en tu nombre.
La consecuencia práctica: tu robots.txt y tus reglas de edge tienen que decir lo mismo. Un sitio que
publica Allow: / para PerplexityBot mientras Cloudflare lo bloquea en el edge envía un mensaje
contradictorio a un operador que mide el cumplimiento.
Comprueba a qué red pertenece de verdad la IP de un crawler
Permite por token exacto los crawlers que quieres
No hagas coincidir la subcadena «bot». Ni «GPT». Permite tokens concretos, porque el token lleva el propósito:
| Crawler | Propósito | Cómo se verifica | Con los valores por defecto del 15 de septiembre en páginas con publicidad |
|---|---|---|---|
| GPTBot | Entrenamiento de modelos de OpenAI | Fichero de rangos de IP publicado | Comportamiento Training, bloqueado en páginas con publicidad |
| OAI-SearchBot | Indexación para los resultados de búsqueda de ChatGPT | Fichero de rangos de IP publicado | Comportamiento Search, sigue permitido |
| ChatGPT-User | Descarga en vivo lanzada por un prompt de usuario | Fichero de rangos de IP publicado | Comportamiento Agent, bloqueado en páginas con publicidad |
| PerplexityBot | Indexación para las respuestas de Perplexity | Fichero de rangos de IP publicado | Comportamiento Search, sigue permitido |
| Perplexity-User | Descarga en vivo en nombre de una persona | Fichero de rangos de IP publicado | Comportamiento Agent, bloqueado en páginas con publicidad |
| ClaudeBot | Entrenamiento de modelos de Anthropic | Fichero de rangos de IP publicado | Comportamiento Training, bloqueado en páginas con publicidad |
| Google-Extended | Solo token de exclusión de entrenamiento, nunca rastrea | Token de robots.txt, sin tráfico propio | Controla el uso para entrenamiento, no el acceso |
| CCBot | Recolección de datasets de Common Crawl | Sin rangos publicados ni convención DNS | Comportamiento Training, bloqueado en páginas con publicidad |
| Bytespider | Recolección de ByteDance | Sin método de verificación publicado | Comportamiento Training, bloqueado en páginas con publicidad |
La clasificación por bot de Cloudflare es la que gobierna su aplicación, así que consulta AI Crawl Control antes de dar por hecha una correspondencia. Nuestro directorio de crawlers de IA recoge los tokens User-Agent exactos, operadores, ficheros de rangos de IP publicados y el comportamiento ante robots.txt de 150 agentes, que es lo que necesitas para escribir reglas que no atrapen al bot equivocado por accidente.
Google-Extended es el ejemplo más claro de por qué importan los tokens. Nunca envía una petición. Existe solo para que puedas excluirte del uso para entrenamiento mientras Googlebot te sigue indexando con normalidad. Bloquearlo en el edge no consigue nada, porque allí no hay nada que bloquear.
Después, verifica lo que llega de verdad
Permitir GPTBot por User-Agent equivale a permitir cualquier cosa que escriba GPTBot en una
cabecera. Los scrapers lo saben desde hace años, y una allowlist basada en cadenas es una invitación.
Detrás de cada regla allow hace falta un paso de verificación.
La mayoría de los grandes operadores de IA publican ya ficheros JSON con rangos de IP, y los crawlers de búsqueda más antiguos admiten DNS inverso confirmado en ambos sentidos. El método varía según el operador, que es justo la parte incómoda: Googlebot y Bingbot resuelven, GPTBot y PerplexityBot publican rangos, Bytespider y CCBot no publican nada comprobable. Consulta verificar Googlebot para el patrón de DNS inverso en detalle.
Cuando un crawler declarado no puede verificarse, entran los signos habituales de respaldo: si la dirección es un rango de datacenter que no pertenece al operador que dice ser, si la huella TLS encaja con el cliente que declara, si las cabeceras son coherentes. Agentscan lo hace por petición, confirma en ambos sentidos los crawlers verificados, compara con rangos publicados y combina el origen de la IP con JA4 y señales headless para devolver humano, bot conocido, agente de IA o automatización maliciosa. Los veredictos se cachean, así que las comprobaciones repetidas vuelven en menos de 50 ms.
En resumen
Cloudflare ha movido el valor por defecto dos veces, y el segundo movimiento cae el 15 de septiembre de 2026. Comprueba cómo está configurada tu zona ahora en lugar de suponer cómo debería estar. Decide por separado sobre entrenamiento, recuperación y tráfico de agente, porque comprimir los tres en un único interruptor es justo lo que te borra en silencio de las respuestas de IA. Publica tu intención en robots.txt con Content Signals, aplica la política equivalente en el edge, permite por token exacto los crawlers que quieres, y verifica a cada uno contra rangos publicados o DNS inverso en lugar de contra una cabecera que puede escribir cualquiera.
FAQ