Benchmark di web crawler per alimentare i siti web con l'IA
Abbiamo confrontato quattro API di crawl su tre domini di difficoltà variabile a tre livelli di profondità massima (5, 10, 20) con un limite di 1.000 pagine, misurando la copertura di crawl, il tempo di esecuzione, il rilevamento dei link, la qualità dei link markdown e l'accuratezza dell'estrazione dei titoli.
Se il tuo obiettivo è:
- Per trasformare le pagine web in dati strutturati, consulta la nostra guida sullo web scraping.
- Per eseguire il crawl di interi siti web, continua a leggere.
Benchmark dei web crawler
Puoi leggere la nostra metodologia di benchmark.
Pagine sottoposte a crawl medie rispetto al costo per 1.000 pagine
Pagine sottoposte a crawl per dominio in base alla profondità massima
Firecrawl ha costantemente eseguito il crawl di circa 100 pagine su theregister.com indipendentemente dalla profondità massima, circa 90 pagine su entrepreneur.com a tutti i livelli di profondità e solo circa 30 pagine su amazon.com, probabilmente a causa dell'aggressiva protezione anti-bot di Amazon. In particolare, l'aumento della profondità massima non ha avuto praticamente alcun impatto sul numero di pagine che Firecrawl è riuscito a sottoporre a crawl su qualsiasi dominio.
Apify ha dimostrato le prestazioni più costanti, raggiungendo il limite massimo di crawl di 1.000 pagine su ogni dominio e a ogni livello di profondità senza alcuna difficoltà apparente, anche su siti fortemente protetti come Amazon.
Cloudflare ha mostrato un comportamento incoerente tra i test:
- Su theregister.com a profondità massima 5, ha eseguito il crawl di solo 100 pagine, ma a profondità massima 20 ha raggiunto quasi 1.000 pagine.
- Come abbiamo osservato nei test precedenti, Cloudflare occasionalmente esegue il crawl di una sola pagina e poi termina completamente il processo. Abbiamo confermato che non si tratta di un problema di cache (la cache era disabilitata) e abbiamo testato con tempi di attesa tra le esecuzioni fino a 1 minuto, ma il comportamento è persistito. A profondità massima 10 su theregister.com si è verificato esattamente questo problema: Cloudflare ha eseguito il crawl di una sola pagina prima di fermarsi.
- Su entrepreneur.com, Cloudflare ha eseguito il crawl di 780 pagine a profondità 5, è salito a 885 a profondità 10, ma è poi sceso bruscamente a sole 172 pagine a profondità 20. Questo calo potrebbe essere correlato allo scheduler di crawl di Cloudflare che assegna priorità inferiore o fa scadere le catene di link più profonde, oppure potrebbe riflettere un limite di concorrenza interno che causa la terminazione anticipata del processo quando la frontiera di crawl cresce troppo a profondità elevate.
- Su amazon.com, Cloudflare ha eseguito il crawl di 905 pagine a profondità 5, ma il numero è costantemente diminuito all'aumentare della profondità massima, scendendo a 809 a profondità 10 e a 795 a profondità 20, suggerendo che configurazioni di crawl più profonde potrebbero portare Cloudflare a dedicare più tempo all'overhead di rilevamento dei link piuttosto che al recupero effettivo delle pagine.
Nimble ha raggiunto o si è avvicinato al limite di 1.000 pagine su theregister.com a tutti i livelli di profondità (1.000 / 1.000 / 999). Su entrepreneur.com, ha eseguito il crawl di 1.000 pagine a profondità 5, ma ha mostrato lievi cali a profondità superiori (896 a profondità 10, 983 a profondità 20), probabilmente perché il timeout di 7 ore è stato raggiunto prima di completare il crawl completo a livelli più profondi; tutte le esecuzioni di Nimble si sono concluse con stato di timeout. Amazon si è rivelato più impegnativo:
- A profondità 5 è riuscito a gestire solo 319 pagine, ma a profondità 10 è salito a 988 pagine, per poi scendere a 906 a profondità 20
- Questa incoerenza riflette probabilmente la combinazione dei meccanismi di protezione anti-bot di Amazon e dei vincoli di timeout di Nimble, dove i crawl più profondi richiedono più tempo per elaborare ogni pagina e possono incontrare più sfide anti-bot lungo il percorso.
Tempo di esecuzione per dominio in base alla profondità massima
Firecrawl è stato il provider più veloce su tutti i domini, completando i crawl in meno di 5 minuti, in genere tra 75-265 secondi. Questa velocità va a scapito della copertura, poiché Firecrawl ha anche eseguito il crawl del minor numero di pagine. In sostanza, termina rapidamente perché si ferma presto.
Apify ha impiegato circa 2.200-2.400 secondi (~40 minuti) su theregister.com indipendentemente dalla profondità. Su entrepreneur.com e amazon.com i tempi di esecuzione sono stati significativamente più lunghi, tra 8.300-15.900 secondi (2-4 ore), a testimonianza delle strutture del sito più ampie e complesse. Nonostante i tempi più lunghi, Apify ha raggiunto costantemente il limite di 1.000 pagine, risultando il più affidabile in termini di rapporto copertura/tempo.
Cloudflare ha mostrato tempi che rispecchiano il suo numero incoerente di pagine sottoposte a crawl:
- Su theregister.com a profondità 10, ha completato in appena 1 secondo, perché ha eseguito il crawl di una sola pagina prima di fermarsi.
- Su entrepreneur.com a profondità 20, ha terminato in 10 secondi dopo aver eseguito il crawl di sole 172 pagine.
- Quando Cloudflare completa un crawl completo, i tempi variano da 3.500 a 25.200 secondi.
- All'aumentare della profondità massima, Cloudflare sembra privilegiare il raggiungimento delle pagine più profonde rispetto all'ampiezza, eseguendo il crawl di meno pagine ma completando più rapidamente. Su amazon.com, il tempo di esecuzione è sceso da 25.200 secondi (timeout) a profondità 5 a soli 5.660 secondi a profondità 20, mentre anche le pagine sottoposte a crawl sono diminuite da 905 a 795. Ciò suggerisce che il crawler di Cloudflare cambi strategia a profondità più elevate, dedicando meno tempo alla scoperta ampia e più all'attraversamento profondo.
Nimble ha raggiunto il timeout di 7 ore (25.200 secondi) in ogni singola esecuzione su tutti i domini e livelli di profondità. Questo è degno di nota perché nei nostri precedenti test rapidi con profondità massima 1, Nimble completava senza timeout. Nel benchmark completo con profondità di 5-20 e limite di 1.000 pagine, ha costantemente eseguito fino al raggiungimento del timeout. Nonostante ciò, Nimble è riuscito comunque a eseguire il crawl di un numero elevato di pagine nella maggior parte dei casi (~900-1.000 su theregister.com e entrepreneur.com), il che significa che esegue attivamente il crawl per tutte le 7 ore ma semplicemente non segnala mai il completamento.
Tasso di riempimento del testo dei link per provider in base alla profondità massima
Per valutare la qualità dell'output markdown, abbiamo misurato la percentuale di link nell'output markdown di ciascun provider che contengono testo di ancoraggio, la porzione di testo cliccabile di un link. Un testo di ancoraggio mancante (ad esempio, [](/about) invece di [About Us](/about)) significa che il crawler non è riuscito a estrarre l'etichetta del link.
- Nimble: 100% a tutte le profondità
- Cloudflare: 91-94%
- Firecrawl: 90%
- Apify: 77-78%, circa 1 link su 5 senza testo di ancoraggio
La profondità di crawl ha avuto un impatto minimo sui tassi di riempimento per qualsiasi provider, suggerendo che si tratti di una caratteristica del motore di parsing di ciascun provider piuttosto che di un'impostazione di crawl.
Tasso di riempimento del testo dei link per provider in base al dominio
L'analisi dei tassi di riempimento nei diversi domini rivela come la complessità del sito influenzi la qualità dell'estrazione dei link di ciascun provider.
- Nimble ha mantenuto il 100% su tutti i domini.
- Apify ha mostrato la maggiore variazione, 89% su amazon.com ma scendendo al 66% su entrepreneur.com, il che significa che un terzo dei suoi link su quel sito era privo di testo di ancoraggio. Ciò suggerisce che Apify abbia maggiori difficoltà con i siti ricchi di contenuti e con strutture di navigazione complesse.
- Firecrawl ha ottenuto i risultati migliori su theregister.com (98%) ma è sceso all'81% su entrepreneur.com, seguendo un pattern simile ad Apify.
- Cloudflare è stato il più costante dopo Nimble, rimanendo tra 89-94% indipendentemente dal dominio.
Entrepreneur.com si è rivelato il dominio più impegnativo per l'estrazione del testo dei link; sia Apify (66%) sia Firecrawl (81%) hanno registrato lì i punteggi più bassi, probabilmente a causa dell'uso massiccio di menu di navigazione annidati e di elementi di contenuto dinamici che sono più difficili da convertire in modo pulito in markdown.
Totale dei link nell'output markdown per dominio in base alla profondità massima
La varianza del numero di link tra i provider è stata costantemente alta (74-97%), indicando che i provider estraggono numeri di link molto diversi dalle stesse pagine. Per avere una visione più dettagliata di questa disparità, abbiamo misurato il numero totale di link markdown per provider.
- Apify ha restituito il maggior numero di link in assoluto, in particolare su amazon.com con oltre 420K link a profondità 5 (~423 per pagina). Su entrepreneur.com si è stabilizzato intorno a 63K indipendentemente dalla profondità. Il suo output include tracker pubblicitari e pixel di tracciamento insieme ai link di contenuto della pagina.
- Cloudflare ha raggiunto il picco di 303K su entrepreneur.com a profondità 10 ma è sceso a 53K a profondità 20. Sulla stessa homepage di entrepreneur.com, Cloudflare ha estratto 434 link rispetto ai 143 di Apify, catturando menu di navigazione e sottomenu completi.
- Firecrawl ha restituito costantemente 5-9K link in tutte le configurazioni, limitato dal basso numero di pagine.
- Nimble ha restituito un totale di 3-40K link, con una media di 5-28 link per pagina rispetto a 60-420 per gli altri provider. Sulla homepage di entrepreneur.com, Nimble ha restituito 13 link contro i 434 di Cloudflare, limitandosi ai titoli principali degli articoli. Il suo tasso di riempimento del 100% riflette il fatto che i link inclusi avevano tutti testo di ancoraggio, piuttosto che indicare una copertura completa dei link. Nimble non produce link markdown standard. Il suo conteggio include link HTML con escape presenti nell'output markdown.
Tasso di presenza del titolo per provider
La somiglianza del titolo tra i provider ha mostrato una deviazione inferiore all'1% in tutti i test e i domini, confermando che quando i provider estraggono un titolo restituiscono costantemente lo stesso risultato. Anche il tasso di presenza del titolo è rimasto tra il 98-100% a tutti i livelli di profondità massima, dimostrando che la profondità di crawl non ha un impatto significativo sull'estrazione del titolo.
Analizzando per dominio, sono emerse alcune differenze:
Su entrepreneur.com e theregister.com, la maggior parte dei provider ha raggiunto tassi di presenza del titolo del 99-100%. Amazon.com è stato l'unico dominio in cui sono emerse differenze significative: Firecrawl è sceso al 93% e Nimble al 95.9%, mentre Apify ha mantenuto il 99.6%. Ciò è in linea con la protezione anti-bot più pesante di Amazon, che può bloccare o distorcere le risposte delle pagine, inducendo alcuni provider a restituire pagine senza titoli estraibili.
Che cos'è un web crawler?
Un web crawler, talvolta chiamato “spider” o “agente”, è un bot che naviga in Internet per indicizzare i contenuti.
I crawler sono andati oltre i motori di ricerca e ora fungono da livello dati agentico. Agiscono come occhi per agenti IA autonomi come Claude Code e OpenAI Operator, assistendo in attività in tempo reale come la ricerca competitiva e le transazioni multi-step.
Che cosa fa un web crawler?
Il web crawling è stato suddiviso in tre modalità, ciascuna progettata per un diverso obiettivo del crawler.
- Modalità discovery (tradizionale): I bot dei motori di ricerca come Googlebot eseguono il crawl degli URL per indicizzarli, aiutando le persone a trovare risultati tramite i motori di ricerca.
- Modalità retrieval (RAG): I bot IA come ChatGPT-User o PerplexityBot recuperano pagine specifiche in tempo reale per rispondere ai prompt degli utenti. Usano il markdown invece dell'HTML per adattarsi ai limiti di token del modello di IA.
- Modalità agentica (orientata all'azione): Questo nuovo tipo di crawler nel 2026 fa molto più che leggere i contenuti. Utilizzando il Model Context Protocol (MCP), questi bot possono interagire con i siti web per prenotare voli o eseguire comandi software.
In passato, i crawler utilizzavano selettori come XPath o CSS per estrarre i dati. L'estrazione nativa dell'IA è diventata la norma.
Strumenti come Firecrawl e Crawl4AI utilizzano istruzioni in linguaggio naturale per trovare i dati. Invece di scrivere regole per ogni elemento, gli sviluppatori possono dire al crawler di “estrarre il prezzo del prodotto” e l'IA troverà il valore corretto anche se il codice del sito web cambia.
Costruire o acquistare web crawler nell'era dell'IA
1. Costruire il proprio crawler
Ideale per proteggere la proprietà intellettuale core e consentire una personalizzazione profonda. Costruire oggi richiede lo sviluppo di un livello agente proprietario, non solo la scrittura di semplici script Scrapy.
- Quando costruire: Scegli questo approccio se il tuo crawler offre un vantaggio competitivo unico. Ad esempio, costruiscine uno tuo se stai sviluppando un motore di ricerca specializzato o se hai bisogno del controllo completo su dati sensibili o regolamentati.
- Il set di strumenti: Non è più necessario partire da zero. Gli sviluppatori ora sfruttano il Model Context Protocol (MCP) per consentire agli agenti IA interni di interagire con il web.
2. Utilizzare strumenti di web crawling e API
Gli strumenti gestiti sono evoluti da semplici scraper ad agenti autonomi.
- Estrazione a manutenzione zero: Strumenti moderni come Kadoa e Firecrawl utilizzano IA auto-riparante. Specifichi i dati richiesti, come “Prezzo del prodotto”, anziché la loro posizione nel codice. Se il layout del sito web cambia, lo strumento si adatta automaticamente.
- Conformità come servizio: Molti provider offrono la conformità integrata con l'EU IA Act. Gestiscono i registri di audit richiesti e i controlli di opt-out sul copyright, difficili da implementare autonomamente.
- Velocità di realizzazione del valore: L'acquisto di una piattaforma può portare il tuo progetto dal concept alla produzione in poche settimane.
I web crawler sono legali?
In generale, il web crawling è legale, ma a seconda di come e cosa si esegue il crawl, potresti trovarti rapidamente in una situazione di difficoltà legale. Quattro pilastri fondamentali determinano se il crawling (e lo scraping che in genere lo segue) è legale:
1. Pubblico vs. privato: Esegui il crawl solo di dati apertamente disponibili al pubblico senza un account.
2. Informazioni personali: Evita le PII (nomi, email e indirizzi) a meno che tu non abbia una base giuridica.
3. Salute del server: Usa limiti di velocità per evitare di rallentare il server; evita di effettuare "DDoS" su un sito web.
4. Copyright: Gli articoli e le immagini sono protetti dal diritto d'autore, ma i fatti (prezzi, date) non lo sono.
Qual è la differenza tra web crawling e web scraping?
Il web scraping consiste nell'usare i web crawler per scansionare e memorizzare tutti i contenuti di una pagina web specifica. In altre parole, il web scraping è un caso d'uso specifico del web crawling per creare un dataset mirato, come estrarre tutte le notizie finanziarie per l'analisi degli investimenti o cercare nomi di aziende specifiche.
Tradizionalmente, una volta che un web crawler ha eseguito il crawl e indicizzato tutti gli elementi della pagina web, un web scraper estraeva i dati dalla pagina web indicizzata. Tuttavia, oggi i termini scraping e crawling sono usati in modo intercambiabile, con la differenza che "crawler" tende a riferirsi maggiormente ai crawler dei motori di ricerca. Man mano che aziende diverse dai motori di ricerca hanno iniziato a usare i dati web, il termine web scraper ha iniziato a prevalere sul termine web crawler.
Aggiungi come fonte preferitaQuali sono le sfide del web crawling?
1. Freschezza del database
I contenuti dei siti web vengono aggiornati regolarmente. Le pagine web dinamiche, ad esempio, cambiano il loro contenuto in base alle attività e ai comportamenti dei visitatori. Ciò significa che il codice sorgente del sito web non rimane lo stesso dopo il crawl del sito. Per fornire all'utente le informazioni più aggiornate, il web crawler deve eseguire nuovamente il crawl di tali pagine web con maggiore frequenza.
2. Trappole per crawler
I siti web utilizzano diverse tecniche, come le trappole per crawler, per impedire ai web crawler di accedere ed eseguire il crawl di determinate pagine web. Una trappola per crawler, o trappola per spider, induce un web crawler a effettuare un numero infinito di richieste e a rimanere intrappolato in un circolo vizioso di crawling. I siti web possono anche creare involontariamente trappole per crawler. In ogni caso, quando un crawler incontra una trappola per crawler, entra in una sorta di loop infinito che spreca le risorse del crawler.
3. Larghezza di banda della rete
Scaricare un gran numero di pagine web irrilevanti, utilizzare un web crawler distribuito o eseguire nuovamente il crawl di molte pagine web comporta un elevato consumo di capacità di rete.
4. Pagine duplicate
I bot dei web crawler eseguono per lo più il crawl di tutti i contenuti duplicati sul web; tuttavia, solo una versione di una pagina viene indicizzata. I contenuti duplicati rendono difficile per i bot dei motori di ricerca determinare quale versione del contenuto duplicato indicizzare e posizionare. Quando Googlebot scopre un gruppo di pagine web identiche nei risultati di ricerca, indicizza e seleziona solo una di queste pagine da mostrare in risposta alla query di ricerca dell'utente.
Le 3 migliori pratiche per il web crawling
1. Cortesia / velocità di crawl
I siti web impostano una velocità di crawl per limitare il numero di richieste effettuate dai bot dei web crawler. La velocità di crawl indica quante richieste un web crawler può effettuare al tuo sito web in un determinato intervallo di tempo (ad esempio, 100 richieste all'ora). Consente ai proprietari dei siti web di proteggere la larghezza di banda dei propri server web e di ridurre il sovraccarico del server. Un web crawler deve rispettare il limite di crawl del sito web di destinazione.
2. Conformità al robots.txt
Un file robots.txt è un file di testo posizionato nella root di un sito web che indica ai crawler quali pagine sono autorizzati o non autorizzati ad accedere. Si tratta di uno standard volontario, il che significa che i bot conformi lo rispettano ma tecnicamente non impedisce l'accesso. Seguire il robots.txt di un sito web è considerato una buona pratica e in molte giurisdizioni ignorarlo può esporti a rischi legali o reputazionali.
3. Rotazione IP
I siti web impiegano diverse tecniche anti-scraping come i CAPTCHA per gestire il traffico dei crawler e ridurre le attività di web scraping. Ad esempio, il fingerprinting del browser è una tecnica di tracciamento utilizzata dai siti web per raccogliere informazioni sui visitatori, come la durata della sessione o le visualizzazioni di pagina.
Questo metodo consente ai proprietari dei siti web di rilevare il "traffico non umano" e bloccare l'indirizzo IP del bot. Per evitare il rilevamento, puoi integrare proxy rotanti, come proxy residenziali, nel tuo web crawler.
Metodologia del benchmark sui web crawler
Abbiamo testato quattro API di crawl (Apify, Nimble, Cloudflare, Firecrawl) su tre domini di difficoltà variabile: amazon.com (forte protezione anti-bot), entrepreneur.com (sito di contenuti complesso) e theregister.com (sito di notizie).
Configurazione condivisa
Tutti i provider hanno ricevuto impostazioni core identiche per garantire un confronto equo:
- Sitemap: disabilitata, i provider devono scoprire le pagine solo tramite link HTML
- Link esterni: disabilitati, i crawler rimangono all'interno del dominio di destinazione
- Sottodomini: abilitati, le pagine dei sottodomini vengono seguite (ad esempio india.entrepreneur.com)
- Rendering JavaScript: abilitato, tutti i provider usano un browser headless
- Cache: disabilitata
- Limite di pagine: 1.000 pagine per esecuzione
- Timeout: 7 ore (25.200 secondi)
- Gestione dei limiti di velocità: attesa di 20 secondi con fino a 3 tentativi in caso di HTTP 429
Ogni provider è stato testato a tre livelli di profondità massima (5, 10, 20) su tutti e tre i domini, per un totale di 36 esecuzioni di crawl. I provider sono stati testati in sequenza (non in parallelo), ogni combinazione è stata eseguita una volta e lo stato del crawl è stato interrogato ogni secondo.
Apify è stato configurato con l'attore website-content-crawler utilizzando Playwright/Firefox come browser headless. L'accesso ai sottodomini è stato controllato tramite pattern glob e per tutte le richieste è stato utilizzato il proxy integrato di Apify.
Nimble, Cloudflare e Firecrawl sono stati configurati utilizzando le rispettive API REST con le impostazioni condivise descritte sopra. Non sono state applicate configurazioni aggiuntive specifiche del provider oltre ai parametri standardizzati.
Per Cloudflare abbiamo utilizzato il piano Workers Paid. Il costo riportato riflette quanto abbiamo speso per eseguire il crawl di 1.000 pagine con questo piano. Cloudflare addebita in base al tempo di rendering del browser piuttosto che al numero di pagine.
Per Firecrawl abbiamo utilizzato il piano Hobby. Il costo riportato è l'importo proporzionale per 1.000 crediti rispetto ai crediti forniti in questo piano. Il costo effettivo per pagina varia a seconda del livello del piano e dell'eventuale acquisto di pacchetti di crediti extra.
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Şipi, Nazlı},
title = {{Benchmark di web crawler per alimentare i siti web con l'IA}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/web-crawler}},
note = {AIMultiple. Consultato il 11 Agosto 2026}
}Registro delle modifiche
9 aggiornamenti- 2026
Rimosse le sezioni su tendenze del settore, tipi di crawler ed esempi di web crawling.
Aggiunto un benchmark di quattro API di crawling su tre domini e tre livelli di profondità, con grafici su copertura, velocità, link e titoli.
Aggiunta una sezione metodologia che descrive la configurazione di crawling su quattro fornitori, tre domini e tre livelli di profondità.
Aggiunta una sezione, I web crawler sono legali?, all'articolo.
Aggiornata la sezione "Cos'è un web crawler?" con nuove tendenze e modalità operative.
- 2024
Aggiornato l'anno nella sezione "I migliori web crawler".
- 2023
Aggiunto un rapido riepilogo dei migliori web crawler del 2023 all'introduzione.
Rimossa la sezione "Perché il web crawling è importante?".
Espansa l'introduzione con una definizione di web crawler e web scraping.
Il lavoro di Cem presso AIMultiple è stato citato da importanti testate internazionali tra cui Business Insider, Forbes, Morning Brew e Washington Post, da aziende globali come Deloitte e HPE, da ONG come il World Economic Forum e da organizzazioni sovranazionali come la Commissione europea. [1], [2], [3], [4], [5]
Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, acquirente tecnologico e imprenditore tecnologico. Ha consigliato le aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per più di un decennio. Ha inoltre pubblicato un report McKinsey sulla digitalizzazione.
Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto ricavi ricorrenti annuali a 7 cifre e una valutazione a 9 cifre partendo da zero in 2 anni. Il lavoro di Cem in Hypatos è stato ripreso da importanti testate tecnologiche come TechCrunch e Business Insider.
Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato come ingegnere informatico presso l'Università di Bogazici e possiede un MBA della Columbia Business School.
Commenti 1
Condividi i tuoi pensieri
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.
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.