Tu robots.txt dice que sí y tu firewall dice que no

Un robots.txt no abre ni cierra nada. Es un cartel en la puerta. Dice a quién le gustaría al dueño que entrara, y los rastreadores serios lo respetan. Pero quien decide de verdad quién pasa no es el cartel: es la infraestructura que hay delante del servidor.

De ahí sale uno de los fallos más frecuentes que vemos, y también el más difícil de detectar desde dentro: un robots.txt impecable, con permiso explícito para todos los rastreadores de IA, y un cortafuegos que los echa antes de que lleguen a leerlo.

Nadie decidió bloquearlos

Esto casi nunca es una decisión. Es un ajuste heredado, o un valor por defecto que nadie revisó. Las causas se repiten:

• «Bot Fight Mode» activado en Cloudflare. Es un interruptor, está a un clic y suena bien. Lo que hace es devolver un desafío a tráfico automatizado que no esté en su lista de bots verificados.
• Reglas gestionadas del WAF. Los paquetes de reglas por defecto incluyen categorías tipo «scrapers» o «herramientas automatizadas» que barren mucho más de lo que su nombre sugiere.
• Un plugin de seguridad de WordPress. Varios traen listas negras de user-agent que se actualizan solas, y algunas de esas listas metieron a los rastreadores de IA en el mismo saco que los scrapers de contenido.
• Limitación por frecuencia. Un rastreador que pide veinte páginas seguidas parece un ataque si el umbral está puesto para un humano leyendo.
• Bloqueo geográfico. Si tu web solo admite tráfico desde España, ten en cuenta que los rastreadores salen de centros de datos, casi siempre fuera. Filtrar por país los filtra a ellos.

Hay además un cambio de fondo que conviene conocer: en julio de 2025 Cloudflare pasó a bloquear rastreadores de IA por defecto en los dominios nuevos, y ofreció a los existentes activarlo con un clic. Si tu web se montó después de esa fecha detrás de Cloudflare, la pregunta no es si alguien lo activó, sino si alguien lo desactivó.

Lo que ve el rastreador cuando no pasa

Un bloqueo se manifiesta de tres maneras, y no son igual de graves porque no son igual de visibles.

Un 403 o un 401. El servidor deniega el acceso a los agentes que no reconoce. Es honesto, al menos: el rastreador se va sabiendo que lo han echado. En nuestro diagnóstico este es el caso que marcamos como bloqueo, porque no hay ambigüedad.

Un 503 con página de espera. El clásico «Just a moment…» mientras se resuelve un desafío. Un navegador lo pasa en dos segundos y el usuario ni se entera. Un rastreador de IA no: no ejecuta el JavaScript del desafío y no resuelve un CAPTCHA. Para él, ahí se acaba la web.

Un 200 que no es tu página. Este es el peor, y es el que casi ninguna herramienta trata bien. El desafío se sirve con estado 200 y con HTML propio. Todo parece correcto: hay respuesta, hay código de éxito, hay contenido. Solo que el contenido no es tu web.

Ese último caso es el que produce diagnósticos disparatados. Una herramienta que lea ese cuerpo sin comprobar de qué es cuerpo te dirá que tu web no tiene H1, ni JSON-LD, ni meta description, sin haberlos visto nunca. Te describe la página del cortafuegos y te la factura como tuya.

Por eso en nuestro motor hay una regla que no se negocia: cuando lo que llega no es el contenido del sitio, las comprobaciones que dependen del cuerpo se declaran no concluyentes y salen del cálculo. No cuentan como cero. Acusar a una web de un fallo que no hemos podido observar es peor que no dar el dato.

Cómo comprobarlo en tu propia web, en dos minutos

La prueba es una comparación: pide la misma página dos veces, una como navegador y otra como rastreador, y mira si te contestan lo mismo.

curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36" \
  
Inicio


curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" \
  https://tudominio.es/

Si el primero devuelve 200 y el segundo 403 o 503, ya lo tienes. Repite con PerplexityBot y con ClaudeBot: no siempre se comportan igual, porque las listas de bots verificados no son las mismas en todas partes.

Y para cazar el caso del 200 engañoso, mira el cuerpo en lugar del código:

curl -s -A "Mozilla/5.0 (compatible; OAI-SearchBot/1.0; +https://openai.com/searchbot)" \
  https://tudominio.es/ | grep -i -E "just a moment|challenge-platform|datadome|incapsula"

Cualquier coincidencia significa que te están sirviendo un desafío, no tu web.

Una advertencia sobre esto: declarar un user-agent ajeno para probar tu propio sitio es legítimo y es la única forma de reproducir lo que pasa. Hacerlo contra webs de terceros ya es suplantación. Nosotros no lo hacemos: analizamos con nuestro propio agente identificado y detectamos la firma del desafío en lo que nos llega —Cloudflare, Imperva, DataDome, Akamai, Sucuri, PerimeterX y la cabecera cf-mitigated—, que es información suficiente sin fingir ser nadie.

Dónde mirar si el bloqueo aparece

En Cloudflare, por orden de probabilidad: Security → Bots (Bot Fight Mode y, si lo tienes, la configuración de Super Bot Fight Mode para «Definitely automated»), el apartado de rastreadores de IA, las reglas gestionadas del WAF, y las reglas de limitación de frecuencia. En el panel de eventos de seguridad puedes filtrar por user-agent y ver, con fecha y hora, qué regla concreta echó a quién. Es el sitio donde se acaban las hipótesis.

Si el bloqueo viene del alojamiento o de un plugin, el orden es el mismo: busca primero la lista de user-agent, después el límite de peticiones.

Bloquear no siempre está mal

Conviene decirlo, porque el sector tiende a tratar esto como si solo hubiera una respuesta correcta. Hay motivos legítimos para cerrar la puerta: el rastreo de IA consume ancho de banda que pagas tú, y hay editores que han decidido que su contenido no viaja gratis. Eso es una postura, no un error.

Lo que casi nunca es una postura es el estado en el que están la mayoría de las webs que analizamos: bloqueadas de lado, por un ajuste que nadie eligió, mientras el robots.txt jura lo contrario. Si decides bloquear, bloquea a propósito. Y si lo haces, sepáralo bien: cerrar el rastreo de entrenamiento no te cuesta ninguna cita; cerrar el rastreo de respuesta sí, y ahí es donde se pierde tráfico sin enterarse.

Dos preguntas, no una

Al final todo se reduce a esto. ¿Lo permites sobre el papel? Lo dice tu robots.txt. ¿Llega en la práctica? Lo dice tu infraestructura. La primera pregunta se responde abriendo un archivo de texto. La segunda hay que provocarla.

Nuestro diagnóstico gratuito hace las dos: calcula las reglas de robots.txt agente por agente y, al mismo tiempo, comprueba qué se recibe realmente al pedir tus páginas. Cuando las dos respuestas no coinciden, esa contradicción es el resultado más útil que te vamos a dar.

Preguntas frecuentes

¿Cómo sé si mi cortafuegos está bloqueando a los rastreadores de IA?

Pide la misma página dos veces con curl, una declarando un user-agent de navegador y otra el de un rastreador como OAI-SearchBot, y compara. Si la primera devuelve 200 y la segunda 403 o 503, tienes un bloqueo. Si las dos devuelven 200, busca en el cuerpo de la respuesta marcas como «Just a moment», challenge-platform o datadome: significan que te están sirviendo un desafío en lugar de tu web.

Mi robots.txt permite el acceso. ¿Por qué aun así no me leen?

Porque el robots.txt no abre ni cierra nada: es un cartel en la puerta, y quien decide quién pasa es la infraestructura que hay delante del servidor. Un «Bot Fight Mode» activado en Cloudflare, una regla del WAF, un plugin de seguridad, un límite de peticiones o un filtro por país pueden echar al rastreador antes de que llegue a leer el archivo que le da permiso.

Si la web devuelve HTTP 200, ¿está todo bien?

No necesariamente, y es el caso más peligroso. Un desafío anti-bot puede servirse con estado 200 y con HTML propio: hay respuesta, hay código de éxito y hay contenido, solo que el contenido no es tu web. Una herramienta que lea ese cuerpo sin comprobar de qué es cuerpo te dirá que tu página no tiene H1, ni JSON-LD, ni meta description, sin haberlos visto nunca.

¿Bloquear GPTBot me quita visibilidad en ChatGPT?

No. GPTBot recoge texto para entrenar modelos, y bloquearlo es una decisión editorial legítima que no cuesta ninguna cita. Lo que sí cuesta visibilidad es bloquear los rastreadores de respuesta —OAI-SearchBot, ChatGPT-User, PerplexityBot—, porque son los que leen tu web en vivo cuando alguien pregunta, y de ahí salen las citas con enlace.

¿Está mal bloquear a los rastreadores de IA?

No, siempre que sea una decisión. El rastreo consume ancho de banda que pagas tú, y hay editores que han decidido que su contenido no viaja gratis. El problema es el estado en el que está la mayoría de las webs: bloqueadas de lado, por un ajuste que nadie eligió, mientras el robots.txt jura lo contrario.

¿Dónde miro en Cloudflare si aparece un bloqueo?

Por orden de probabilidad: el apartado de bots dentro de Security (Bot Fight Mode y la configuración de Super Bot Fight Mode), la sección de rastreadores de IA, las reglas gestionadas del WAF y las reglas de limitación de frecuencia. En el panel de eventos de seguridad puedes filtrar por user-agent y ver, con fecha y hora, qué regla concreta echó a quién.