Benchmark de rastreadores web para alimentar sitios web a la IA
Evaluamos cuatro APIs de rastreo en tres dominios de dificultad variable, con tres niveles de profundidad máxima (5, 10, 20) y un límite de 1.000 páginas, midiendo la cobertura de rastreo, el tiempo de ejecución, el descubrimiento de enlaces, la calidad de los enlaces en markdown y la precisión de extracción de títulos.
Si su objetivo es:
- Convierta páginas web en datos estructurados; consulte nuestra guía sobre web scraping.
- Rastree sitios web completos, continúe leyendo.
Benchmark de rastreadores web
Puede consultar nuestra metodología de benchmark.
Promedio de páginas rastreadas frente al coste por 1.000 páginas
Páginas rastreadas en los dominios según la profundidad máxima
Firecrawl rastreó de manera consistente alrededor de 100 páginas en theregister.com independientemente de la profundidad máxima, aproximadamente 90 páginas en entrepreneur.com en todos los niveles de profundidad, y solo alrededor de 30 páginas en amazon.com, probablemente debido a la agresiva protección contra bots de Amazon. En particular, aumentar la profundidad máxima prácticamente no afectó al número de páginas que Firecrawl pudo rastrear en ninguno de los dominios.
Apify demostró el rendimiento más constante, alcanzando el límite máximo de rastreo de 1.000 páginas en todos los dominios y en todos los niveles de profundidad sin dificultad aparente, incluso en sitios muy protegidos como Amazon.
Cloudflare mostró un comportamiento inconsistente en las pruebas:
- En theregister.com con una profundidad máxima de 5, rastreó solo 100 páginas, pero con una profundidad máxima de 20 alcanzó casi 1.000 páginas.
- Como observamos en pruebas anteriores, Cloudflare a veces rastrea solo 1 página y luego finaliza el trabajo por completo. Confirmamos que no se trata de un problema de caché (la caché estaba desactivada) y lo probamos con tiempos de espera entre ejecuciones de hasta 1 minuto, pero el comportamiento persistió. Con una profundidad máxima de 10 en theregister.com, ocurrió exactamente este problema: Cloudflare rastreó solo 1 página antes de detenerse.
- En entrepreneur.com, Cloudflare rastreó 780 páginas con profundidad 5, aumentó a 885 con profundidad 10, pero luego cayó bruscamente a solo 172 páginas con profundidad 20. Esta caída podría estar relacionada con el programador de rastreo de Cloudflare, que reduce la prioridad o agota el tiempo de las cadenas de enlaces más profundas, o podría reflejar un límite de concurrencia interno que hace que el trabajo termine prematuramente cuando la frontera de rastreo crece demasiado en profundidades mayores.
- En amazon.com, Cloudflare rastreó 905 páginas con profundidad 5, pero la cifra disminuyó de forma constante a medida que aumentaba la profundidad máxima, cayendo a 809 con profundidad 10 y a 795 con profundidad 20, lo que sugiere que las configuraciones de rastreo más profundas pueden hacer que Cloudflare dedique más tiempo a la sobrecarga de descubrimiento de enlaces que a la recuperación real de páginas.
Nimble alcanzó o se acercó al límite de 1.000 páginas en theregister.com en todos los niveles de profundidad (1.000 / 1.000 / 999). En entrepreneur.com, rastreó 1.000 páginas con profundidad 5, pero mostró ligeras caídas en profundidades mayores (896 con profundidad 10, 983 con profundidad 20), posiblemente porque se alcanzó el tiempo de espera de 7 horas antes de completar el rastreo completo en niveles más profundos; todas las ejecuciones de Nimble terminaron con un estado de tiempo de espera. Amazon resultó más desafiante:
- Con profundidad 5 solo consiguió 319 páginas, pero con profundidad 10 saltó a 988 páginas y luego bajó a 906 con profundidad 20
- Esta inconsistencia probablemente refleja la combinación de los mecanismos de protección contra bots de Amazon y las limitaciones de tiempo de espera de Nimble, ya que los rastreos más profundos tardan más en procesar cada página y pueden encontrar más desafíos antibots por el camino
Tiempo de ejecución en los dominios según la profundidad máxima
Firecrawl fue el proveedor más rápido en todos los dominios, completando los rastreos en menos de 5 minutos, normalmente entre 75 y 265 segundos. Esta velocidad tiene el coste de una menor cobertura, ya que Firecrawl también fue el que menos páginas rastreó. En esencia, termina rápido porque se detiene pronto.
Apify tardó alrededor de 2.200-2.400 segundos (~40 minutos) en theregister.com independientemente de la profundidad. En entrepreneur.com y amazon.com, los tiempos de ejecución fueron significativamente mayores, de 8.300 a 15.900 segundos (2-4 horas), lo que refleja estructuras de sitio más grandes y complejas. A pesar de los tiempos más largos, Apify alcanzó de forma constante el límite de 1.000 páginas, lo que lo convierte en el más fiable en términos de relación cobertura-tiempo.
Cloudflare mostró tiempos que reflejan sus recuentos inconsistentes de rastreo:
- En theregister.com con profundidad 10, completó en solo 1 segundo, porque solo rastreó 1 página antes de detenerse.
- En entrepreneur.com con profundidad 20, terminó en 10 segundos tras rastrear solo 172 páginas.
- Cuando Cloudflare completa un rastreo completo, los tiempos oscilan entre 3.500 y 25.200 segundos.
- A medida que aumenta la profundidad máxima, Cloudflare parece priorizar alcanzar páginas más profundas frente a la amplitud, rastreando menos páginas pero completando más rápido. En amazon.com, el tiempo de ejecución bajó de 25.200 segundos (tiempo de espera agotado) con profundidad 5 a solo 5.660 segundos con profundidad 20, mientras que las páginas rastreadas también disminuyeron de 905 a 795. Esto sugiere que el rastreador de Cloudflare cambia su estrategia en profundidades mayores, dedicando menos tiempo al descubrimiento amplio y más al recorrido profundo.
Nimble alcanzó el tiempo de espera de 7 horas (25.200 segundos) en todas y cada una de las ejecuciones en todos los dominios y niveles de profundidad. Esto es notable porque en nuestras pruebas rápidas anteriores con una profundidad máxima de 1, Nimble completó sin agotar el tiempo de espera. En el benchmark completo con profundidades de 5 a 20 y un límite de 1.000 páginas, se ejecutó de forma constante hasta alcanzar el tiempo de espera. A pesar de ello, Nimble consiguió rastrear un gran número de páginas en la mayoría de los casos (~900-1.000 en theregister.com y entrepreneur.com), lo que significa que rastrea activamente durante las 7 horas pero simplemente nunca indica la finalización.
Tasa de relleno del texto de los enlaces por proveedor según la profundidad máxima
Para evaluar la calidad de la salida en markdown, medimos qué porcentaje de enlaces en el markdown de cada proveedor contienen texto ancla, la parte de texto en la que se puede hacer clic de un enlace. La ausencia de texto ancla (por ejemplo, [](/about) en lugar de [About Us](/about)) significa que el rastreador no pudo extraer la etiqueta del enlace.
- Nimble: 100 % en todas las profundidades
- Cloudflare: 91-94 %
- Firecrawl: 90 %
- Apify: 77-78 %, aproximadamente 1 de cada 5 enlaces carece de texto ancla
La profundidad de rastreo tuvo un impacto mínimo en las tasas de relleno de cualquier proveedor, lo que sugiere que se trata de una característica del motor de análisis de cada proveedor más que de una configuración de rastreo.
Tasa de relleno del texto de los enlaces por proveedor según el dominio
Observar las tasas de relleno en los distintos dominios revela cómo la complejidad del sitio afecta a la calidad de extracción de enlaces de cada proveedor.
- Nimble mantuvo un 100 % en todos los dominios.
- Apify mostró la mayor variación: 89 % en amazon.com, pero bajó al 66 % en entrepreneur.com, lo que significa que a un tercio de sus enlaces en ese sitio les faltaba el texto ancla. Esto sugiere que a Apify le cuesta más con sitios con mucho contenido y estructuras de navegación complejas.
- Firecrawl obtuvo su mejor resultado en theregister.com (98 %), pero bajó al 81 % en entrepreneur.com, siguiendo un patrón similar al de Apify.
- Cloudflare fue el más constante después de Nimble, manteniéndose entre 89 y 94 % independientemente del dominio.
Entrepreneur.com resultó ser el dominio más difícil para la extracción de texto de enlaces; tanto Apify (66 %) como Firecrawl (81 %) obtuvieron allí sus puntuaciones más bajas, probablemente debido al uso intensivo de menús de navegación anidados y elementos de contenido dinámico que son más difíciles de convertir limpiamente en markdown.
Total de enlaces en la salida de markdown en los dominios según la profundidad máxima
La variación en el número de enlaces entre proveedores fue sistemáticamente alta (74-97 %), lo que indica que los proveedores extraen cantidades muy diferentes de enlaces de las mismas páginas. Para obtener una visión más detallada de esta disparidad, medimos el número total de enlaces de markdown por proveedor.
- Apify devolvió la mayor cantidad de enlaces en general, sobre todo en amazon.com, con más de 420K enlaces con profundidad 5 (~423 por página). En entrepreneur.com se estabilizó en torno a 63K independientemente de la profundidad. Su salida incluye rastreadores de anuncios y píxeles de seguimiento junto con los enlaces de contenido de la página.
- Cloudflare alcanzó un pico de 303K en entrepreneur.com con profundidad 10, pero bajó a 53K con profundidad 20. En la misma página de inicio de entrepreneur.com, Cloudflare extrajo 434 enlaces en comparación con Apify, que tiene 143, capturando menús de navegación completos y submenús.
- Firecrawl devolvió de manera consistente entre 5 y 9K enlaces en todas las configuraciones, limitado por su bajo número de páginas.
- Nimble devolvió entre 3 y 40K enlaces en total, con una media de 5 a 28 enlaces por página, frente a los 60-420 de otros proveedores. En la página de inicio de entrepreneur.com, Nimble devolvió 13 enlaces, frente a Cloudflare, que tiene 434, limitados a los titulares de los artículos principales. Su tasa de relleno del 100 % refleja que todos los enlaces que incluyó tenían texto ancla, en lugar de indicar una cobertura integral de enlaces. Nimble no genera enlaces de markdown estándar. Su recuento incluye enlaces HTML escapados que se encuentran dentro de la salida de markdown.
Tasa de presencia de títulos por proveedor
La similitud de los títulos entre proveedores mostró una desviación inferior al 1 % en todas las pruebas y dominios, lo que confirma que, cuando los proveedores extraen un título, devuelven de forma constante el mismo resultado. La tasa de títulos presentes también se mantuvo entre el 98 y el 100 % en todos los niveles de profundidad máxima, lo que demuestra que la profundidad de rastreo no tiene un impacto significativo en la extracción de títulos.
Al desglosar por dominio, surgieron algunas diferencias:
En entrepreneur.com y theregister.com, la mayoría de los proveedores alcanzaron tasas de títulos presentes del 99-100 %. Amazon.com fue el único dominio donde aparecieron diferencias significativas: Firecrawl bajó al 93 % y Nimble al 95.9 %, mientras que Apify mantuvo el 99.6 %. Esto concuerda con la mayor protección contra bots de Amazon, que puede bloquear o distorsionar las respuestas de las páginas y provocar que algunos proveedores devuelvan páginas sin títulos extraíbles.
¿Qué es un rastreador web?
Un rastreador web, a veces llamado «spider» o «agente», es un bot que navega por Internet para indexar contenido.
Los rastreadores han ido más allá de los motores de búsqueda y ahora sirven como capa de datos agéntica. Actúan como los ojos de agentes de IA autónomos como Claude Code y OpenAI Operator, ayudando con tareas en tiempo real como la investigación competitiva y las transacciones de varios pasos.
¿Qué hace un rastreador web?
El rastreo web se dividió en tres modos, cada uno diseñado para un objetivo de rastreo diferente.
- Modo de descubrimiento (tradicional): Los bots de los motores de búsqueda, como Googlebot, rastrean URLs para indexarlas y ayudan a las personas a encontrar resultados a través de los motores de búsqueda.
- Modo de recuperación (RAG): Los bots de IA como ChatGPT-User o PerplexityBot obtienen páginas específicas en tiempo real para responder a los prompts de los usuarios. Utilizan markdown en lugar de HTML para ajustarse a los límites de tokens del modelo de IA.
- Modo agéntico (orientado a la acción): Este nuevo tipo de rastreador en 2026 hace más que solo leer contenido. Mediante el Model Context Protocol (MCP), estos bots pueden interactuar con sitios web para reservar vuelos o ejecutar comandos de software.
En el pasado, los rastreadores usaban selectores como XPath o CSS para extraer datos. La extracción nativa de IA se ha convertido en la norma.
Herramientas como Firecrawl y Crawl4AI utilizan instrucciones en lenguaje natural para encontrar datos. En lugar de escribir reglas para cada elemento, los desarrolladores pueden pedir al rastreador que «extraiga el precio del producto», y la IA encontrará el valor correcto incluso si cambia el código del sitio web.
Construir o comprar rastreadores web en la era de la IA
1. Crear tu propio rastreador
Ideal para proteger la propiedad intelectual principal y permitir una personalización profunda. Actualmente, crearlo requiere desarrollar una capa de agente propietaria, no solo escribir scripts básicos de Scrapy.
- Cuándo crear: Elija este enfoque si su rastreador proporciona una ventaja competitiva única. Por ejemplo, créelo usted mismo si está desarrollando un motor de búsqueda especializado o si necesita un control total sobre datos sensibles o regulados.
- El conjunto de herramientas: Ya no es necesario empezar desde cero. Los desarrolladores ahora aprovechan el Model Context Protocol (MCP) para permitir que los agentes de IA internos interactúen con la web.
2. Uso de herramientas de rastreo web y APIs
Las herramientas gestionadas han evolucionado de simples scrapers a agentes autónomos.
- Extracción sin mantenimiento: Las herramientas modernas como Kadoa y Firecrawl utilizan IA con autorreparación. Usted especifica los datos requeridos, como «Precio del producto», en lugar de su ubicación en el código. Si el diseño del sitio web cambia, la herramienta se adapta automáticamente.
- Cumplimiento como servicio: Muchos proveedores ofrecen cumplimiento integrado con la Ley de IA de la UE. Gestionan los registros de auditoría requeridos y las comprobaciones de exclusión voluntaria de derechos de autor, que son difíciles de implementar de forma independiente.
- Rapidez para obtener valor: Comprar una plataforma puede llevar su proyecto del concepto a la producción en cuestión de semanas.
¿Son legales los rastreadores web?
En general, el rastreo web es legal, pero dependiendo de cómo y qué rastree, podría encontrarse rápidamente en un problema legal. Cuatro pilares principales determinan si el rastreo (y el scraping que normalmente le sigue) es legal:
1. Público frente a privado: Rastree únicamente datos que estén disponibles públicamente sin necesidad de una cuenta.
2. Información personal: Evite la información de identificación personal (PII; nombres, correos electrónicos y direcciones) a menos que tenga una base legal.
3. Salud del servidor: Utilice límites de frecuencia para evitar ralentizar el servidor; evite «DDOSing» de un sitio web.
4. Derechos de autor: Los artículos y las imágenes están protegidos por derechos de autor, pero los hechos (precios, fechas) no.
¿Cuál es la diferencia entre rastreo web y web scraping?
El web scraping consiste en utilizar rastreadores web para escanear y almacenar todo el contenido de una página web concreta. En otras palabras, el web scraping es un caso de uso específico del rastreo web para crear un dataset específico, como extraer todas las noticias financieras para el análisis de inversiones y buscar nombres de empresas concretos.
Tradicionalmente, una vez que un rastreador web ha rastreado e indexado todos los elementos de la página web, un web scraper extraía los datos de la página web indexada. Sin embargo, hoy en día los términos scraping y rastreo se utilizan indistintamente, con la diferencia de que rastreador tiende a referirse más a los rastreadores de motores de búsqueda. A medida que empresas distintas de los motores de búsqueda empezaron a utilizar datos web, el término web scraper comenzó a sustituir al término rastreador web.
Añadir como fuente preferida¿Cuáles son los retos del rastreo web?
1. Frescura de la base de datos
El contenido de los sitios web se actualiza con regularidad. Las páginas web dinámicas, por ejemplo, cambian su contenido en función de las actividades y los comportamientos de los visitantes. Esto significa que el código fuente del sitio web no permanece igual después de rastrear el sitio. Para ofrecer la información más actualizada al usuario, el rastreador web debe volver a rastrear esas páginas con más frecuencia.
2. Trampas para rastreadores
Los sitios web emplean diferentes técnicas, como las trampas para rastreadores, para impedir que los rastreadores web accedan y rastreen determinadas páginas. Una trampa para rastreadores, o trampa de araña, hace que un rastreador web realice un número infinito de solicitudes y quede atrapado en un círculo vicioso de rastreo. Los sitios web también pueden crear trampas para rastreadores de forma no intencionada. En cualquier caso, cuando un rastreador se encuentra con una trampa, entra en algo parecido a un bucle infinito que desperdicia los recursos del rastreador.
3. Ancho de banda de red
Descargar un gran número de páginas web irrelevantes, utilizar un rastreador web distribuido o volver a rastrear muchas páginas web tiene como resultado un alto consumo de capacidad de red.
4. Páginas duplicadas
Los bots de rastreo web suelen rastrear todo el contenido duplicado de la web; sin embargo, solo se indexa una versión de una página. El contenido duplicado dificulta que los bots de los motores de búsqueda determinen qué versión del contenido duplicado indexar y posicionar. Cuando Googlebot descubre un grupo de páginas web idénticas en los resultados de búsqueda, indexa y selecciona solo una de esas páginas para mostrarla en respuesta a la consulta de búsqueda de un usuario.
Las 3 mejores prácticas de rastreo web
1. Cortesía / Tasa de rastreo
Los sitios web establecen una tasa de rastreo para limitar el número de solicitudes que realizan los bots de rastreo web. La tasa de rastreo indica cuántas solicitudes puede hacer un rastreador web a su sitio web en un intervalo de tiempo determinado (por ejemplo, 100 solicitudes por hora). Permite a los propietarios de sitios web proteger el ancho de banda de sus servidores web y reducir la sobrecarga del servidor. Un rastreador web debe respetar el límite de rastreo del sitio web de destino.
2. Cumplimiento de robots.txt
Un archivo robots.txt es un archivo de texto situado en la raíz de un sitio web que indica a los rastreadores qué páginas pueden o no pueden visitar. Es un estándar voluntario, lo que significa que los bots que lo cumplen lo respetan, pero no impide técnicamente el acceso. Seguir el robots.txt de un sitio web se considera una buena práctica y, en muchas jurisdicciones, ignorarlo puede exponerle a riesgos legales o de reputación.
3. Rotación de IP
Los sitios web emplean diferentes técnicas anti-scraping, como los CAPTCHA, para gestionar el tráfico de los rastreadores y reducir las actividades de web scraping. Por ejemplo, la huella digital del navegador es una técnica de seguimiento utilizada por los sitios web para recopilar información sobre los visitantes, como la duración de la sesión o las páginas vistas.
Este método permite a los propietarios de sitios web detectar el «tráfico no humano» y bloquear la dirección IP del bot. Para evitar la detección, puede integrar proxies rotativos, como residenciales proxies, en su rastreador web.
Metodología del benchmark de rastreadores web
Probamos cuatro APIs de rastreo (Apify, Nimble, Cloudflare, Firecrawl) en tres dominios de dificultad variable: amazon.com (protección intensa contra bots), entrepreneur.com (sitio de contenido complejo) y theregister.com (sitio de noticias).
Configuración compartida
Todos los proveedores recibieron los mismos ajustes básicos para garantizar una comparación justa:
- Sitemap: Desactivado, los proveedores deben descubrir las páginas solo a través de enlaces HTML
- Enlaces externos: Desactivado, los rastreadores permanecen dentro del dominio objetivo
- Subdominios: Activado, se siguen las páginas de subdominios (por ejemplo, india.entrepreneur.com)
- Renderizado de JavaScript: Activado, todos los proveedores utilizan un navegador headless
- Caché: Desactivada
- Límite de páginas: 1.000 páginas por ejecución
- Tiempo de espera: 7 horas (25.200 segundos)
- Gestión del límite de frecuencia: espera de 20 segundos con hasta 3 reintentos en HTTP 429
Cada proveedor se probó en tres niveles de profundidad máxima (5, 10, 20) en los tres dominios, con un total de 36 ejecuciones de rastreo. Los proveedores se probaron de forma secuencial (no en paralelo), cada combinación se ejecutó una vez y el estado del rastreo se consultó cada 1 segundo.
Apify se configuró con el actor website-content-crawler utilizando Playwright/Firefox como navegador headless. El acceso a los subdominios se controló mediante patrones glob y se utilizó el proxy integrado de Apify para todas las solicitudes.
Nimble, Cloudflare y Firecrawl se configuraron utilizando sus respectivas APIs REST con los ajustes compartidos descritos anteriormente. No se aplicaron configuraciones adicionales específicas de cada proveedor más allá de los parámetros estandarizados.
Para Cloudflare, utilizamos el plan Workers Paid. El coste indicado refleja lo que gastamos para rastrear 1.000 páginas con este plan. Cloudflare cobra en función del tiempo de renderizado del navegador y no del número de páginas.
Para Firecrawl, utilizamos el plan Hobby. El coste indicado es la cantidad prorrateada de 1.000 créditos de entre los créditos incluidos en este plan. El coste efectivo por página varía según el nivel del plan y si se compran paquetes de créditos adicionales.
Cita este benchmark
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{Benchmark de rastreadores web para alimentar sitios web a la IA}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/web-crawler}},
note = {AIMultiple. Recuperado el 11 de Agosto de 2026}
}Registro de cambios
9 actualizaciones- 2026
Se eliminaron las secciones de tendencias del sector, tipos de rastreadores y ejemplos de rastreo web.
Añadido un benchmark de cuatro API de rastreo en tres dominios y tres niveles de profundidad, con gráficos de cobertura, velocidad, enlaces y títulos.
Añadida una sección de metodología que detalla la configuración de rastreo con cuatro proveedores, tres dominios y tres niveles de profundidad.
Se añadió una sección, ¿Son legales los rastreadores web?, al artículo.
Se actualizó la sección "¿Qué es un rastreador web?" con nuevas tendencias y modos de operación.
- 2024
Se actualizó el año en la sección "Los mejores rastreadores web".
- 2023
Se añadió un resumen rápido de los mejores rastreadores web de 2023 a la introducción.
Eliminada la sección "¿Por qué es importante el rastreo web?".
Se amplió la introducción con una definición de rastreador web y web scraping.
El trabajo de Cem en AIMultiple ha sido citado por publicaciones líderes mundiales como Business Insider, Forbes, Morning Brew y Washington Post, empresas globales como Deloitte y HPE, ONG como World Economic Forum y organizaciones supranacionales como European Commission. [1], [2], [3], [4], [5]
A lo largo de su carrera, Cem trabajó como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.
Dirigió la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando al CEO. También lideró el crecimiento comercial de la empresa de deep tech Hypatos, que alcanzó unos ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.
Cem participa habitualmente en conferencias internacionales de tecnología. Se graduó en Bogazici University como ingeniero informático y tiene un MBA de Columbia Business School.
Siguiente para leer
Las mejores alternativas a Firecrawl: características y precios
Archivo web APIs: 4 proveedores principales probados y comparados
Los 6 mejores raspadores de Apple App Store: Bright Data, SerpAPI y Zyte
Top 5 Comparación de APIs de extracción de ofertas de empleo
Benchmark MFT: Files.com, Diplomat MFT, Cerberus y Serv-U Probados
Los 6 mejores scrapers de LLM: ChatGPT, Perplexity y Gemini
Comentarios 1
Comparte tus ideas
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.
Hi Cem, I think there is a misunderstanding regarding the robots.txt role in the crawling context. The web bots can crawl any website when indexing is allowed without having the robots.txt somewhere on their top domain, subdomains and ports and so on. The role of a robots.txt is to keep control of the traffic from web bots so the website is not overloaded by requests.