Cuando proteger el repositorio lo vuelve invisible: Cloudflare, bots e indexación académica
Proteger una plataforma académica de ataques, scraping indiscriminado y tráfico automatizado es una necesidad. El problema aparece cuando, en nombre de esa protección, terminamos bloqueando también a los agentes que necesitamos para que nuestros contenidos sean encontrados.
Un repositorio institucional, un portal de revistas o una plataforma de datos de investigación puede estar perfectamente disponible para una persona y, al mismo tiempo, resultar prácticamente invisible para Google Scholar u otros sistemas que dependen de procesos automatizados de rastreo.
La paradoja es evidente: podemos tener una plataforma más protegida y, simultáneamente, una infraestructura académica menos visible.
No todos los bots son iguales
Durante años utilizamos la palabra bot casi como sinónimo de amenaza. Hoy esa simplificación resulta problemática.
Un bot puede intentar explotar una vulnerabilidad, realizar scraping intensivo o probar credenciales. Pero también puede ser Googlebot, un sistema de monitoreo, un agregador académico, un cosechador de metadatos o un crawler utilizado para construir un índice.
Cloudflare reconoce explícitamente esta diferencia. Su documentación actual distingue bots verificados y clasifica distintos comportamientos automatizados. En el ámbito de la inteligencia artificial, diferencia incluso entre crawlers destinados a búsqueda, agentes que actúan en representación de usuarios y sistemas que recopilan información para entrenamiento.
El problema, por tanto, no consiste en decidir simplemente entre permitir bots o bloquear bots. Consiste en determinar qué automatizaciones necesitamos permitir y cuáles queremos detener.
Google Scholar también es un robot
Esto parece obvio, pero tiene consecuencias importantes. Google Scholar explica en sus propias directrices que utiliza software automatizado —robots o crawlers— para encontrar documentos académicos, recuperar sus páginas y actualizar periódicamente la información existente en su índice.
Además, establece algo especialmente relevante para repositorios y revistas: las páginas deben estar disponibles tanto para los usuarios como para los crawlers. Si sus robots no pueden recuperar los documentos debido a errores del servidor, configuraciones incorrectas, lentitud excesiva u otros problemas de acceso, algunos contenidos pueden dejar de aparecer en Google o Google Scholar.
Google también advierte que robots.txt no debe impedir que sus robots accedan a los artículos ni a las páginas utilizadas para descubrirlos. Y recomienda que los documentos puedan encontrarse siguiendo enlaces HTML simples, sin depender de formularios, procesos JavaScript o mecanismos que dificulten la navegación automática.
No estamos hablando solamente de SEO. Estamos hablando de infraestructura de descubrimiento académico.
Cuando entra Cloudflare
Cloudflare puede ser extremadamente útil frente a ataques DDoS, tráfico automatizado abusivo, intentos de explotación y otras amenazas. El problema no es utilizar Cloudflare. El problema aparece cuando se implementan reglas demasiado generales.
Por ejemplo, Bot Fight Mode detecta patrones asociados con bots y puede responder mediante desafíos computacionales. Cloudflare señala además que algunas modalidades de protección pueden afectar tráfico legítimo automatizado, como APIs o aplicaciones.
Un navegador convencional puede superar un desafío basado en JavaScript, cookies u otros mecanismos interactivos. Un crawler académico puede no hacerlo.
Desde el punto de vista humano, entonces, todo funciona: abrimos DSpace, OJS o Dataverse y vemos el contenido. Desde el punto de vista de una máquina, la situación puede ser muy distinta. Ese es uno de los problemas más difíciles de detectar porque el sitio no está caído.
Seguridad e indexación no deberían competir
La propia documentación de Cloudflare entrega una pista importante sobre cómo abordar este problema. Sus reglas permiten reconocer bots verificados y crear excepciones para motores de búsqueda antes de ejecutar reglas generales de bloqueo o desafío.
Cloudflare incluye como ejemplo explícito permitir Googlebot, Bingbot y otros bots verificados mientras se desafía otro tráfico automatizado. También recomienda crear excepciones para bots legítimos antes de desplegar reglas restrictivas.
Esto cambia completamente el enfoque. En vez de:
bot → bloquear
Deberíamos pensar en algo más parecido a:
agente automatizado → identificar → comprender su función → decidir política de acceso.
La seguridad de una plataforma académica necesita ser selectiva.
El problema se está haciendo más complejo
La aparición masiva de crawlers asociados con inteligencia artificial está haciendo que muchas instituciones endurezcan sus políticas de acceso automatizado. Tiene sentido.
No necesariamente queremos que cualquier sistema copie millones de documentos, genere cargas innecesarias sobre la infraestructura o reutilice contenidos sin considerar políticas de acceso. Pero aquí aparece un nuevo riesgo: responder al problema mediante bloqueos generales.
Cloudflare mismo ha evolucionado hacia políticas más diferenciadas. Su configuración permite tratar separadamente crawlers de búsqueda, agentes y crawlers destinados al entrenamiento de modelos.
La distinción es importante porque bloquear entrenamiento de IA no debería significar automáticamente bloquear descubrimiento académico.
¿Cómo saber si tenemos un problema?
Una de las primeras pruebas debería ser observar la plataforma desde fuera. No basta con abrirla desde un navegador institucional.
Conviene revisar periódicamente cuántos documentos aparecen en Google Scholar, verificar muestras conocidas, inspeccionarrobots.txt, revisar códigos HTTP entregados a crawlers y analizar los eventos registrados por Cloudflare.
Google Scholar recomienda precisamente utilizar búsquedas sobre el dominio para diagnosticar problemas de indexación. Si aparecen pocos documentos, metadatos incorrectos o contenidos que antes estaban presentes desaparecen, puede existir un problema de crawling o interpretación bibliográfica. Una vez corregido, la recuperación tampoco necesariamente es inmediata: Google advierte que algunos cambios pueden tardar desde días hasta varios meses en reflejarse. Por eso el monitoreo tiene que ser continuo.
La visibilidad también es parte de la infraestructura
Durante mucho tiempo hemos pensado en la infraestructura de un repositorio principalmente en términos de servidores, almacenamiento, respaldos, bases de datos y seguridad.
Pero un repositorio académico tiene una característica particular: su valor depende también de que otras máquinas puedan leerlo.
Google Scholar, motores de búsqueda, agregadores, sistemas de descubrimiento, recolectores OAI-PMH, servicios bibliométricos y futuras aplicaciones basadas en inteligencia artificial dependen de diferentes formas de acceso automatizado.
Una plataforma que solamente funciona para personas está cumpliendo solo una parte de su propósito.
Por eso quizás debamos incorporar una nueva dimensión a nuestras políticas de seguridad: además de medir ataques bloqueados, disponibilidad del servidor o tiempo de respuesta, deberíamos medir capacidad de descubrimiento e indexación.
La pregunta ya no debería ser simplemente:
¿Está funcionando el repositorio?
También deberíamos preguntarnos:
¿Pueden encontrarlo y comprenderlo las máquinas de las que depende su visibilidad?
Proteger la infraestructura académica es indispensable. Protegerla hasta volverla invisible es otra cosa.
Fuentes: Google mantiene sus directrices técnicas para inclusión en Google Scholar y su ayuda sobre cobertura e indexación. Cloudflare documenta sus bots verificados, las reglas para permitir motores de búsqueda y otros bots legítimos y sus políticas actuales para crawlers de IA.
Este contenido es de semantica y se publica bajo licencia CC BY-NC-SA 4.0.