Lo que el cortafuegos oculta a sus logs: el punto ciego de los bloqueos en el edge

Un responsable de sitio abre sus logs, busca GPTBot, ClaudeBot o PerplexityBot, no encuentra nada y concluye que las IA no se interesan por su contenido. La conclusión es casi siempre falsa, y por una razón mecánica: cuando un cortafuegos o un CDN rechaza una petición, esta se detiene en la periferia de la red, en el edge, y nunca llega al servidor de origen. No existe, por tanto, en ningún log de origen. El silencio de los logs no significa que los robots estén ausentes; puede significar exactamente lo contrario.

Cómo puede desaparecer una petición

En un sitio servido tras un CDN como Cloudflare, cada petición atraviesa varias capas antes de llegar al servidor. El cortafuegos de aplicaciones, descrito en la documentación del WAF de Cloudflare, evalúa reglas y puede bloquear, redirigir o mostrar un desafío. Un módulo de gestión de robots, detallado en la documentación Bots, clasifica el tráfico automatizado y le aplica una política. Desde 2024, estas plataformas ofrecen bloquear los robots de IA con un clic, como anunciaba Cloudflare en su entrada sobre el bloqueo de los robots de IA, y muchos sitios activaron la opción sin medir qué hacía.

Toda petición detenida a ese nivel recibe una respuesta fabricada por el CDN, por lo común un código 403 o una página de desafío. El servidor de origen no ve nada. Los logs de Apache, de nginx o de la aplicación no la contienen, y una herramienta de análisis de logs que solo lee el origen no puede contarla.

Los tres errores de razonamiento que esto produce

1. «Ninguna IA viene a nuestro sitio.» Es el más frecuente. El sitio recibe visitas en realidad, pero cada visita se rechaza aguas arriba. Una regla activada por precaución, a veces por un proveedor, a veces por una casilla marcada en una interfaz, corta en silencio cualquier posibilidad de ser citado.
2. «Nuestra tasa de éxito de rastreo es del 100 %.» Un panel que cuenta las respuestas 200 servidas por el origen muestra una puntuación perfecta, porque solo llegan hasta allí las peticiones aceptadas. La tasa real, bloqueos incluidos, puede ser muy baja.
3. «El robot no respeta nuestro robots.txt.» Si el robots.txt lo sirve el origen pero la primera petición del robot se bloquea en el edge, nunca lo ha leído. Se acusa al robot de un comportamiento cuya causa es local.

Cómo comprobar lo que ocurre en el edge

Las comprobaciones, de la más sencilla a la más completa:

• Releer la configuración del CDN. Reglas WAF, modo de gestión de robots, opciones de «bloquear los robots de IA», listas de user-agents rechazados. Hay que leerla tal como está, no tal como uno cree haberla ajustado: en un sitio que auditamos este verano, una regla de bloqueo heredada de una configuración anterior cortaba robots que nadie del equipo pensaba estar bloqueando.
• Probar con los user-agents reales. Enviar uno mismo una petición a una página pública declarando el user-agent de cada robot de IA, desde fuera de la red, y mirar el código de respuesta y quién lo emite. Un 403 firmado por el CDN cuando el origen responde 200 es la prueba directa del bloqueo en el edge.
• Leer los logs del CDN, no solo los del origen. Los grandes CDN exponen estadísticas de tráfico que incluyen las peticiones rechazadas, por regla y por user-agent, y a veces por ruta. Ahí es donde aparecen los robots que se creían ausentes. En Cloudflare, estos datos son accesibles desde la interfaz y por API con un token que tenga el permiso de lectura Zone Analytics; en un plan gratuito, el desglose por ruta obliga a pasar por la API.

Un caso medido

En otro sitio, industrial, auditado el mismo verano, los logs de origen no mostraban ninguna petición de robot de IA durante varias semanas, y el panel de rastreo indicaba una tasa de éxito perfecta. Los logs del CDN contaban otra cosa: varios centenares de peticiones de robots de IA rechazadas con un 403 por una regla del cortafuegos, de las que nadie tenía traza. La conclusión inicial, «las IA no vienen», era el reverso exacto de la realidad: venían, con regularidad, y se marchaban sin leer nada. El sitio no aparecía en ninguna respuesta generada, no por falta de interés de los motores, sino por un ajuste de seguridad. El diagnóstico llevó una hora; podría no haberse hecho nunca.

La trampa de la dirección IP

Un segundo efecto del CDN complica la lectura de los logs de origen: la dirección IP que ve el servidor es la del CDN, no la del visitante, salvo que el servidor esté configurado para leer la cabecera que transporta la dirección original. Cuando falta ese ajuste, todos los visitantes, humanos y robots, parecen venir de unas pocas decenas de direcciones pertenecientes al CDN. Las verificaciones de autenticidad descritas en nuestro artículo sobre el reverse DNS y los rangos de IP se vuelven imposibles, y un robot auténtico puede pasar por un impostor, o al revés. Una cabecera propietaria añadida por el CDN sobrevive por lo común a todos los saltos intermedios allí donde una cabecera genérica puede sobrescribirse. En Cloudflare es CF-Connecting-IP; la cabecera genérica, X-Forwarded-For, puede ser reescrita por cualquier intermediario. Pida a su proveedor de alojamiento el nombre exacto de la que añade, y compruebe que llega efectivamente al log de origen.

Qué política sostener

La cuestión de fondo es editorial: un medio que quiere ser citado por las IA no tiene ninguna razón para bloquear en el edge sus robots de búsqueda y de lectura. Bloquear el entrenamiento es una decisión legítima, pero se toma en el robots.txt, user-agent por user-agent, como explicamos en «robots.txt e IA», y no con un interruptor que rechaza todo lo que se parezca a una IA. Un bloqueo en el edge solo tiene sentido ante tráfico abusivo demostrado: volúmenes anómalos, suplantación de identidad, scrapers que ignoran el robots.txt.

Queda una precaución: tampoco conviene bloquear a los suplantadores con una regla amplia sobre el user-agent. Una regla que rechaza todo «GPTBot» procedente de una dirección fuera de los rangos publicados por OpenAI parece prudente; en la práctica rechaza también las peticiones legítimas el día en que OpenAI añade un rango que la lista local todavía no tiene. La respuesta correcta a la suplantación es la medición y la limitación de velocidad, no el rechazo ciego.

Qué significa medir, una vez levantado el bloqueo

Cuando el edge deja pasar, los logs de origen vuelven a ser una fuente fiable, a condición de que transporten la dirección original y conserven el user-agent completo. Se puede entonces contar, por robot y por uso (entrenamiento, búsqueda, lectura bajo demanda), qué leen realmente las IA: qué páginas, con qué frecuencia, con qué código de respuesta. Es esa lectura, y no un panel de origen, la que permite afirmar que un contenido llega a los motores generativos. Detallamos el método en «Leer un access log en 30 minutos».

El principio está ahí: un log de origen solo prueba lo que ha llegado hasta el origen. Todo lo rechazado antes no deja ninguna traza en él, y es justamente eso lo que hay que ir a buscar a otra parte antes de concluir nada sobre las IA.