El robots.txt solo frena a quien se porta bien

Por Kike Gandia · Amenazas · 9 min de lectura

El archivo robots.txt es una cortesía, no una barrera. Le dice a los rastreadores qué rutas no deberían visitar: los que respetan las reglas obedecen y los que no, siguen. Lo medimos en uno de nuestros sitios públicos, con un robots.txt que lo cerraba todo, y el reparto de visitas fue el contrario al que cualquiera habría diseñado: el rastreador que el sitio quería conservar no apareció y otro, que no formaba parte del plan, generó casi la mitad del tráfico.

La idea en treinta segundos

• Un robots.txt con «Disallow: /» no impidió que un rastreador de Meta pidiera 14.776 páginas en diez horas, y el servidor las sirvió todas con éxito.
• robots.txt es un acuerdo voluntario: solo lo cumple quien quiere. No es un control de acceso.
• Además es público: si escondes rutas en él, las estás señalando.
• El control real está en el servidor: verificar quién es cada rastreador, limitar la tasa y decidir por ruta.

Qué medimos

En septiembre de 2026 analizamos diez horas del registro de accesos de un sitio público cuyo robots.txt decía «Disallow: /» para todos: ningún rastreador debía pasar de la puerta. Fue una sola ventana de un solo sitio, así que sirve de ilustración y no de estadística general.

32.383

Peticiones en la ventana (10 horas de registro)

14.776

Del rastreador de Meta (user-agent meta-externalagent)

0

Peticiones de Googlebot (ninguna en la ventana de diez horas)

1 cada 2,4 s

Ritmo medio del rastreador de Meta (cálculo sobre las 14.776 peticiones en 10 horas)

Peticiones recibidas en la ventana de diez horas. Todas las del rastreador de Meta obtuvieron respuesta correcta (código 200). Fuente: registro de accesos propio de QuantumSec, septiembre de 2026.

Dicho de otra forma: el rastreador del buscador, el que el sitio quería conservar, no pidió nada. El que no formaba parte del plan, y que no ofrece visibilidad en búsquedas, generó casi la mitad del tráfico total. Y todas sus peticiones se atendieron con éxito: el servidor hizo el trabajo que el robots.txt pretendía evitar.

Qué dice el dato y qué no

Lo que sí muestra En esta ventana, en este sitio

• Un rastreador con user-agent meta-externalagent pidió miles de páginas pese al «Disallow: /».
• El servidor respondió 200 a todas esas peticiones: nada en el servidor las frenó.
• No hubo ninguna petición de Googlebot.

Lo que no muestra Conviene no sacar de aquí más de lo que hay

• Que Googlebot «obedeciera»: diez horas sin visitas también pueden significar que no le tocaba pasar. Google guarda en caché el robots.txt hasta unas 24 horas.
• Que el rastreador fuera de verdad de Meta: el user-agent lo declara el cliente. Hay que comprobar la red de origen.
• Qué hace Meta con las páginas, ni por qué no respetó la regla.
• Que ocurra igual en otro sitio u otro mes.

Una ventana, un sitio: sirve de alarma, no de estadística.

Por eso en este artículo no decimos que Googlebot «cumpliera»: decimos que no apareció. La diferencia importa. Lo que sí está medido, y es suficiente para actuar, es que una regla en robots.txt no frenó nada de lo que no quiso frenarse.

Qué es (y qué no es) el robots.txt

El protocolo de exclusión de robots está estandarizado desde 2022 en la RFC 9309, y el propio estándar lo dice con claridad: las reglas no son una forma de autorización de acceso, y el protocolo no sustituye a las medidas de seguridad del contenido. Es un convenio entre quien publica y quien rastrea.

Hay además una segunda pega: el archivo está en una URL fija y es legible por cualquiera. Si en él pones «Disallow: /admin-antiguo/» para que no se indexe, acabas de decirle a todo el mundo que esa ruta existe. En una auditoría web, robots.txt es de los primeros ficheros que leemos, precisamente porque suele listar lo que su dueño preferiría que nadie mirase.

Por qué ocurre

• El robots.txt no impone nada: depende de la voluntad del rastreador.
• Cada empresa decide si lo respeta; quienes recogen datos para entrenar modelos tienen incentivos distintos a los de un buscador, que depende de que los sitios le dejen pasar.
• El nombre que un rastreador declara (su user-agent) lo escribe él: puede ser cualquiera, incluido el de Googlebot.
• Un cierre total en robots.txt apaga el SEO que sí se quería y no frena a quien no obedece: el coste lo paga solo el cumplidor.
• Nada en el servidor distingue por defecto a un rastreador de un visitante: si nadie lo configura, todos reciben respuesta.

Cómo saber quién es quién

Antes de decidir qué hacer con un rastreador hay que saber si es quien dice ser. Los buscadores grandes publican cómo comprobarlo:

# 1) Resolución inversa de la IP sospechosa (ejemplo de la documentación de Google)
host 66.249.66.1
# -> crawl-66-249-66-1.googlebot.com

# 2) Comprueba que ese nombre devuelve la misma IP
host crawl-66-249-66-1.googlebot.com

Un «Googlebot» cuya IP no pasa esta prueba es un impostor: alguien que usa un nombre de confianza para colarse.

Cómo mirar tu propio registro

En un servidor con nginx y el formato de registro por defecto (combinado), unas pocas líneas bastan para ver quién genera más tráfico y qué le contesta tu servidor.

# Peticiones por user-agent
awk -F'"' '{print $6}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

# Códigos de respuesta que recibe cada user-agent
awk -F'"' '{split($3,a," "); print a[1], $6}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

# Desde qué IPs llega uno concreto (sustituye el nombre)
grep 'nombre-del-rastreador' /var/log/nginx/access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -10

Si en la lista aparece algo que no reconoces con muchas peticiones, el siguiente paso es comprobar desde qué red llega: un user-agent se puede escribir a mano; la red de origen, no. Si tu web va detrás de un CDN o un proxy inverso, la IP del registro será la del proxy: busca la real en la cabecera X-Forwarded-For o configura el registro para guardarla.

Lo que conviene cambiar

1. 1. Mide antes de decidir
   Mira el registro de accesos: qué user-agents generan más peticiones y a qué rutas. Sin ese dato, se bloquea a ciegas.
2. 2. Verifica quién es quién
   Comprueba que el que dice ser Googlebot lo es, con la consulta inversa de DNS y los rangos oficiales. Un «Googlebot» que no viene de Google es un impostor.
3. 3. Distingue tipos de rastreador
   Buscadores, vistas previas de redes sociales, herramientas de SEO, rastreadores de entrenamiento de IA y bots desconocidos no merecen el mismo trato.
4. 4. Aplica la política en el servidor
   El corte real se hace en el proxy o el cortafuegos de aplicaciones, no en robots.txt. Por dominio y por ruta: lo comercial puede abrir más que lo interno.
5. 5. Limita la tasa
   Aunque se deje pasar, un límite de peticiones por origen protege el servicio de picos.
6. 6. Saca de robots.txt lo que no deba estar
   Si hay rutas sensibles listadas, protégelas con autenticación y quítalas del archivo.
7. 7. Revisa de forma periódica
   Los nombres y los rangos cambian. Una revisión trimestral basta para no quedarse atrás.

Un ejemplo de control en nginx

Este fragmento hace dos cosas: frena a un rastreador por su user-agent y limita la tasa de peticiones por IP. Es un punto de partida, no una receta cerrada: ajusta los valores a tu tráfico real.

# En el bloque http { ... }
limit_req_zone $binary_remote_addr zone=por_ip:10m rate=5r/s;

map $http_user_agent $rastreador_no_deseado {
    default 0;
    ~*nombre-del-rastreador 1;   # sustituye por el user-agent que quieras frenar
}

# En el bloque server { ... }
location / {
    if ($rastreador_no_deseado) { return 403; }
    limit_req zone=por_ip burst=20 nodelay;
}

Ten en cuenta su límite: filtrar solo por user-agent frena a quien no se molesta en cambiarlo. Si el operador publica sus rangos de red, combínalo con una regla por red; y si no, vigila el comportamiento (ritmo, rutas, horas) y no el nombre.

Cómo cortar sin regalar información

Rechazar con un error claro tiene un inconveniente: avisa al otro de que hay un bloqueo y puede volver con otra identidad. En sitios públicos que se quiera proteger de rastreadores no deseados, conviene valorar respuestas que no revelen la regla y que no malgasten recursos propios. Un 403 dice «sé quién eres»; un 429 dice «vas demasiado rápido» y enseña el umbral; cerrar la conexión sin respuesta (en nginx, el código 444) cuesta menos. Cada caso tiene su equilibrio entre ocultar, proteger la capacidad y no estorbar a visitantes reales.

Lo que no recomendamos. Cargas maliciosas, bombas de descompresión o cualquier respuesta ofensiva contra un rastreador. Defender un sitio no consiste en atacar a quien lo visita, y puede acarrear responsabilidades legales.

Para una pyme: tres acciones que caben en una tarde

• Descarga el registro de accesos de los últimos días y cuenta las peticiones por user-agent.
• Comprueba que los Googlebot y Bingbot que ves en el registro son los verdaderos, con la verificación oficial de cada buscador.
• Configura en tu proxy o servicio de protección web una regla para los rastreadores de IA que no quieras, con base en su user-agent y, mejor, en sus rangos de red publicados.

Preguntas frecuentes

¿Debo borrar mi robots.txt?

No. Sigue siendo útil para ordenar el rastreo de los buscadores y para quien lo respeta. Lo que no debe hacerse es confiarle seguridad.

¿Sirve meter en Disallow las rutas sensibles?

Al contrario: las anuncia. Lo sensible se protege con autenticación, no con una petición educada.

¿Bloquear rastreadores de IA afecta a mi posicionamiento?

Depende de cuál. Los rastreadores de entrenamiento de modelos suelen ser distintos de los de búsqueda, y Google, por ejemplo, separa el rastreo para buscar del permiso para entrenar con el token Google-Extended, que según su documentación no influye en el posicionamiento. Comprueba siempre la documentación de cada operador antes de bloquear.

¿Cuánto tarda un cambio en robots.txt en notarse?

Los buscadores guardan el archivo en caché, en el caso de Google hasta unas 24 horas, así que el efecto no es inmediato. Es otra razón para no depender de él en una emergencia.

Lo que no sabemos

Esta medición no dice por qué ese rastreador no respetó la regla ni qué hace con los datos. Tampoco permite generalizar: otra ventana, otro sitio o otro mes podrían dar un reparto distinto. Es una foto útil como alarma, no una conclusión definitiva. El siguiente paso sería repetirla con varios días de registro y con más sitios, y comprobar la red de origen de cada rastreador.

Siguiente paso

En QuantumSec ayudamos a medir el tráfico automatizado de un sitio, a distinguir bots legítimos de los demás y a definir una política de acceso. Puedes hablar con QuantumSec o escribirnos desde contacto. Si lo que te preocupa es lo que tu web enseña sin querer, lo vemos en una auditoría de pentesting web.

Servicio relacionado

ciberinteligencia y análisis de tráfico

Temas de este artículo

#robots-txt #Rastreadores #Bots #Inteligencia-artificial #Logs #Nginx

Seguir leyendo

• Jev y los modelos System 1: cuando la IA deja de escribir y empieza a decidir
• ¿Esto puedo subírselo a la IA? Clasifica el dato antes de pegarlo
• Implantar IA en la empresa sin abrir un agujero: control, gobernanza y medición
• Análisis del Hackeo a Bybit (III) : Implicaciones y Futuro de la Seguridad Cripto Tras el Hackeo de Bybit
• Cómo Compartir Credenciales y Archivos Cifrados de Forma Segura con Terceros

Fuentes

• RFC 9309: Robots Exclusion Protocol (IETF, 2022)
• Google: verificar el rastreo de Googlebot
• Google: introducción a robots.txt

Midamos el tráfico de tu web