¿Los asistentes de IA respetan robots.txt? Un estudio con 200 pruebas

Un preprint publicado en julio de 2026 probó diez asistentes de IA en 200 ensayos controlados y encontró diferencias importantes en su forma de aplicar robots.txt. Claude y Mistral mostraron el patrón de permitir y bloquear más consistente en las configuraciones ensayadas. Copilot, DeepSeek, Diffy Chat, Gemini, Grok y Qwen accedieron a páginas sin que el servidor registrara una solicitud previa de robots.txt; varios recuperaron además contenido de rutas bloqueadas.

El resultado no es una clasificación permanente de productos. Es una observación fechada de modos, cuentas y sistemas de recuperación concretos que pueden cambiar sin aviso. Su conclusión práctica es más limitada y útil: un editor no puede dar por hecho que robots.txt controle de forma fiable todas las visitas realizadas durante una consulta a un asistente de IA.

Qué hace robots.txt y qué no puede hacer

Una web publica robots.txt en una dirección conocida para indicar a los agentes automatizados qué rutas pueden rastrear y cuáles deberían evitar. El Protocolo de Exclusión de Robots está estandarizado en el RFC 9309 y admite reglas generales o específicas para un user-agent, el identificador con el que un rastreador se presenta ante el servidor.

El archivo comunica una política; no funciona como una contraseña, un muro de pago o un firewall. No impide técnicamente una petición. Acceder a una URL bloqueada demuestra que no se siguió la regla de rastreo publicada, pero no establece por sí solo que el acceso fuera ilícito. Esa valoración depende de la normativa aplicable, la finalidad de la recuperación y el uso posterior de los datos.

La distinción se vuelve esencial cuando los asistentes incorporan búsqueda y navegación. Como explicamos en nuestra guía sobre cómo eligen fuentes los LLM, una respuesta puede proceder de la memoria del modelo, un índice de búsqueda, una copia en caché, una visita directa o una combinación de esas rutas. El usuario ve una respuesta; el editor puede recibir una cadena mucho más compleja de solicitudes.

Cómo probaron los investigadores a los asistentes

Gabriel Lopez-Fonseca, David Rodriguez, Stefan Bechtold y Jose M. Del Alamo diseñaron un experimento en dos fases con infraestructura web bajo su control. Evaluaron ChatGPT, Claude, Copilot, DeepSeek, Diffy Chat, Gemini, Grok, Mistral, Perplexity y Qwen.

En cada prueba anotaron si el sistema solicitaba robots.txt, si visitaba la página objetivo, qué user-agent aparecía en los registros, cuántas peticiones generaba y si la respuesta contenía el código correcto. Utilizar dominios diferentes en ambas fases redujo el riesgo de que una caché o indexación anterior contaminara la evaluación.

Este diseño desde el servidor es el principal punto fuerte del trabajo. El código correcto demuestra que el sistema tuvo acceso al contenido, mientras que los registros confirman si contactó realmente con el servidor controlado. Ambas señales permiten separar la recuperación de la generación de la respuesta.

Los resultados se dividen en tres patrones

1. Claude y Mistral mostraron el comportamiento esperado más claro

Claude accedió a todas las páginas permitidas y a ninguna de las bloqueadas. Cuando una regla impedía la visita, informó al usuario de que robots.txt bloqueaba la recuperación. Mistral también evitó las ubicaciones denegadas. Cometió algunos errores al confundir identificadores similares en las pruebas permitidas, pero su patrón de acceso respetó las restricciones.

Perplexity quedó cerca de este grupo, aunque no fue completamente consistente. Evitó la carpeta bloqueada para su agente, pero accedió una vez durante la condición que denegaba todo acceso y mostró el código correspondiente en una sección posterior. También recuperó páginas permitidas sin trasladar siempre su contenido a la respuesta.

2. Seis asistentes accedieron sin una solicitud observada de robots.txt

Copilot, DeepSeek, Diffy Chat, Gemini, Grok y Qwen visitaron páginas durante las pruebas activas sin que el servidor registrara una solicitud compatible de robots.txt. Los autores revisaron además el historial anterior y no encontraron una consulta previa que explicara el comportamiento.

DeepSeek devolvió el código correcto en las cuatro condiciones, incluidas las rutas bloqueadas. Gemini mostró un patrón parecido, con una respuesta inventada. Qwen realizó menos visitas en las condiciones con identificadores genéricos, pero respondió correctamente siempre que recuperó la página.

Grok destacó por la amplificación de peticiones. En cuatro grupos de cinco pruebas, el servidor contabilizó 52, 48, 48 y 50 accesos a las páginas objetivo. Grok devolvió el código correcto en todos los ensayos, pero unas pocas interacciones visibles originaron muchas más visitas. Durante la semana siguiente volvió a páginas utilizadas en el experimento y generó 173 accesos adicionales.

3. La recuperación y la respuesta visible no siempre coincidieron

Copilot accedió a todas las páginas solicitadas, incluidas las bloqueadas, pero nunca mostró el código correcto al usuario. Una auditoría limitada a leer la conversación habría pasado por alto esas peticiones del servidor.

ChatGPT mostró el problema inverso en la configuración elegida. Solicitó robots.txt una vez, pero no visitó ninguna página objetivo ni dio una respuesta correcta, tampoco cuando el acceso estaba permitido. Los autores advierten acertadamente que esto no demuestra cumplimiento: un sistema que falla tanto en las páginas permitidas como en las bloqueadas no ha probado que aplique la regla.

Por eso el cumplimiento debe evaluarse como un patrón con controles positivos y negativos. Evitar una página bloqueada solo es significativo si el sistema también puede recuperar una página comparable cuando está permitida. De lo contrario, un fallo de recuperación y el respeto de la política parecen lo mismo.

Los user-agents genéricos debilitan el control del editor

Varios asistentes llegaron al servidor mediante identificadores genéricos o difíciles de atribuir. Todos los que utilizaron un user-agent genérico o no identificable en el experimento accedieron a páginas sin pedir robots.txt durante las pruebas activas.

Esto crea un problema operativo incluso antes de entrar en el debate jurídico. Un editor solo puede escribir una regla específica cuando la petición identifica al proveedor o componente de recuperación. El tráfico que parece proceder de un navegador genérico dificulta aplicar políticas selectivas, limitar el volumen o investigar una incidencia.

El estudio muestra además por qué “el asistente” no siempre es la unidad adecuada. La petición puede proceder de un rastreador convencional, una herramienta activada por el usuario, un navegador integrado, un socio de búsqueda o un sistema de indexación. Cada componente puede utilizar una identidad y una interpretación distinta de las reglas.

Qué deberían medir los editores y los equipos SEO

El trabajo permite construir un marco práctico que separa tres capas:

1. Acceso al servidor. Registrar user-agents, rutas, fechas, volumen y si el sistema consultó robots.txt.
2. Evidencia de recuperación. Usar marcadores nuevos y específicos de cada página para comprobar si el asistente obtuvo el contenido solicitado.
3. Resultado visible. Medir si la respuesta menciona la marca, cita el dominio, enlaza la página o reproduce correctamente su información.

Cada capa responde a una pregunta distinta. Una visita no garantiza una cita y una respuesta no revela todas las peticiones anteriores. Por esta razón, las métricas de visibilidad en buscadores de IA deberían separar menciones, citas, prominencia y fuentes utilizadas en lugar de comprimirlo todo en una única puntuación.

Para que la auditoría sea reproducible conviene crear páginas nuevas que todavía no estén indexadas, mantener estable la regla, ejecutar casos permitidos y bloqueados, repetir cada prompt y conservar los registros sin procesar. Tampoco debe atribuirse un proveedor solo por el texto del user-agent cuando este publique un método adicional de verificación, como la comprobación de IP o DNS inverso.

¿Basta robots.txt para proteger contenido frente a la IA?

No. Sigue siendo una forma útil y ligera de comunicar preferencias de rastreo, pero no es un mecanismo de cumplimiento forzoso. Cuando resulte imprescindible impedir el acceso, el editor necesitará autenticación, un firewall de aplicaciones web, filtrado de IP, límites de tráfico u otro control activo del servidor.

Estas medidas tienen costes. Requieren más mantenimiento, pueden bloquear automatizaciones legítimas y añadir fricción a usuarios humanos. Si las señales ligeras se ignoran con frecuencia, los editores pueden levantar más barreras y reducir la apertura de la web para todos.

Otros archivos como llms.txt responden a un objetivo diferente: ayudar a los modelos a descubrir el contenido y el contexto que una web prefiere ofrecer. Ninguno de los dos formatos garantiza el control del acceso.

Importancia jurídica: una prueba, no una sentencia

El paper analiza el derecho de autor y las excepciones de minería de textos y datos en la Unión Europea, incluidas las reservas de derechos legibles por máquinas previstas en el artículo 4 de la Directiva sobre derechos de autor en el mercado único digital. También reconoce que el efecto jurídico de una regla de robots.txt depende del caso y todavía presenta incertidumbres.

Esa prudencia es importante. El experimento aporta evidencia sobre si se respetó una regla publicada; no decide si una petición concreta infringió derechos de autor, incumplió un contrato o vulneró otra norma. Los registros son un dato para el análisis técnico y jurídico, no una conclusión legal automática.

Limitaciones del estudio

Los asistentes son sistemas cerrados y los investigadores no pudieron determinar qué componente interno realizó cada petición. El prompt estandarizado afirmaba además que el usuario era propietario de la web. Esa redacción pudo favorecer la recuperación, aunque no alteraba las reglas del servidor ni autenticaba al usuario.

Los resultados están limitados en el tiempo. Los proveedores pueden cambiar modelos, herramientas de navegación, filtros, cachés, user-agents y rutas de red sin aviso. Otra cuenta, plan, país o fecha podría producir un comportamiento diferente. El texto es un preprint de arXiv y no una publicación final revisada por pares; sus autores indican que los datos procesados y los registros saneados se publicarán cuando el artículo sea aceptado.

Estas limitaciones justifican una auditoría continua y reproducible, no ignorar el hallazgo. La aportación más sólida del estudio es el método: observar el servidor, probar condiciones complementarias y separar lo que se recupera de lo que el asistente responde.

La conclusión práctica

Merece la pena publicar robots.txt, pero debe tratarse como una preferencia declarada, no como una barrera garantizada. Los editores necesitan telemetría del servidor para saber qué agentes visitan su contenido. Los equipos de marca y SEO necesitan monitorizar respuestas para comprobar si el material recuperado se convierte en una mención o una cita.

La combinación de ambas perspectivas ofrece una imagen más completa del descubrimiento mediado por IA. Los registros explican el acceso; el seguimiento repetido de respuestas explica la visibilidad. Ninguno sustituye al otro.

Fuente

Do Generative AI Assistants Respect robots.txt? Tracing Web Access Beyond Visible Answers, Gabriel Lopez-Fonseca, David Rodriguez, Stefan Bechtold y Jose M. Del Alamo, arXiv:2607.14447v2, revisado el 19 de julio de 2026.

Sigue leyendo: cómo funciona ChatGPT Search · cómo eligen fuentes los LLM.