Web Crawler Benchmark per Alimentare l'IA con i Siti Web

Abbiamo confrontato quattro API di crawling su tre domini di difficoltà variabile a tre livelli di profondità massima (5, 10, 20) con un limite di 1.000 pagine, misurando copertura della scansione, tempo di esecuzione, scoperta dei link, qualità dei link markdown e accuratezza dell'estrazione del titolo.

Se intendi:

• Trasformare pagine web in dati strutturati, consulta la nostra guida al web scraping.
• Effettuare il crawling di interi siti web, continua a leggere.

Benchmark dei web crawler

Puoi leggere la nostra metodologia di benchmark.

Pagine scansionate medie vs costo per 1.000 pagine

Pagine scansionate nei domini per profondità massima

Firecrawl ha scansionato costantemente 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 scansionare in alcun dominio.

Apify ha dimostrato le prestazioni più costanti, raggiungendo il limite massimo di crawling di 1.000 pagine su ogni dominio a ogni livello di profondità senza alcuna difficoltà apparente, anche su siti fortemente protetti come Amazon.

Cloudflare ha mostrato un comportamento incoerente nei test:

• Su theregister.com alla profondità massima 5, ha scansionato solo 100 pagine, ma alla profondità massima 20 ha raggiunto quasi 1.000 pagine.
• Come abbiamo osservato nei test precedenti, Cloudflare occasionalmente esegue la scansione 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. Alla profondità massima 10 su theregister.com si è verificato esattamente questo problema: Cloudflare ha scansionato solo 1 pagina prima di fermarsi.
• Su entrepreneur.com, Cloudflare ha scansionato 780 pagine alla profondità 5, è aumentato a 885 alla profondità 10, ma poi è diminuito bruscamente a sole 172 pagine alla profondità 20. Questo calo potrebbe essere correlato allo scheduler di crawling di Cloudflare che deprioritizza o manda in timeout le catene di link più profonde, oppure potrebbe riflettere un limite di concorrenza interna che causa la terminazione prematura del processo quando la frontiera di crawling diventa troppo grande a profondità più elevate.
• Su amazon.com, Cloudflare ha scansionato 905 pagine alla profondità 5, ma il numero è diminuito costantemente all'aumentare della profondità massima, scendendo a 809 alla profondità 10 e 795 alla profondità 20, suggerendo che configurazioni di crawling più profonde possono indurre Cloudflare a dedicare più tempo all'overhead di scoperta 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 scansionato 1.000 pagine alla profondità 5 ma ha mostrato lievi cali a profondità più elevate (896 alla profondità 10, 983 alla profondità 20), probabilmente a causa del raggiungimento del timeout di 7 ore prima di completare la scansione completa a livelli più profondi; tutte le esecuzioni di Nimble si sono concluse con uno stato di timeout. Amazon si è rivelato più impegnativo:

• Alla profondità 5 è riuscito a scansionare solo 319 pagine, ma alla profondità 10 è balzato a 988 pagine, per poi scendere a 906 alla profondità 20
• Questa incoerenza riflette probabilmente la combinazione dei meccanismi di protezione anti-bot di Amazon e dei vincoli di timeout di Nimble, per cui le scansioni più profonde richiedono più tempo per elaborare ogni pagina e possono incontrare più sfide anti-bot lungo il percorso

Tempo di esecuzione nei domini per profondità massima

Firecrawl è stato il provider più veloce in tutti i domini, completando le scansioni in meno di 5 minuti, tipicamente tra 75 e 265 secondi. Questa velocità ha un costo in termini di copertura, poiché Firecrawl ha scansionato anche il minor numero di pagine. In sostanza, finisce 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, pari a 8.300-15.900 secondi (2-4 ore), riflettendo le strutture dei siti 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 i suoi conteggi di crawling incoerenti:

• Su theregister.com alla profondità 10, ha completato in solo 1 secondo, poiché ha scansionato solo 1 pagina prima di fermarsi.
• Su entrepreneur.com alla profondità 20, ha terminato in 10 secondi dopo aver scansionato solo 172 pagine.
• Quando Cloudflare completa una scansione completa, i tempi variano da 3.500 a 25.200 secondi.
• All'aumentare della profondità massima, Cloudflare sembra dare priorità al raggiungimento delle pagine più profonde rispetto all'ampiezza, scansionando meno pagine ma completando più rapidamente. Su amazon.com, il tempo di esecuzione è sceso da 25.200 secondi (timeout) alla profondità 5 a soli 5.660 secondi alla profondità 20, mentre anche le pagine scansionate sono diminuite da 905 a 795. Ciò suggerisce che il crawler di Cloudflare cambia strategia a profondità più elevate, dedicando meno tempo alla scoperta ampia e più alla navigazione in profondità.

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 aveva completato senza timeout. Nel benchmark completo con profondità di 5-20 e un limite di 1.000 pagine, ha costantemente eseguito fino al raggiungimento del timeout. Nonostante ciò, Nimble è comunque riuscito a scansionare un numero elevato di pagine nella maggior parte dei casi (~900-1.000 su theregister.com ed entrepreneur.com), il che significa che continua a effettuare il crawling attivamente durante le 7 ore ma semplicemente non segnala mai il completamento.

Tasso di riempimento del testo dei link per provider e profondità massima

Per valutare la qualità dell'output markdown, abbiamo misurato quale percentuale di link nel markdown di ciascun provider contiene testo di ancoraggio, ossia la porzione di testo cliccabile di un link. Un testo di ancoraggio mancante (ad es., [](/about) invece di [About Us](/about)) significa che il crawler non è riuscito a extract l'etichetta del link.

• Nimble: 100% a tutte le profondità
• Cloudflare: 91-94%
• Firecrawl: 90%
• Apify: 77-78%, circa 1 link su 5 con testo di ancoraggio mancante

La profondità di crawling ha avuto un impatto minimo sui tassi di riempimento per qualsiasi provider, suggerendo che si tratta di una caratteristica del motore di parsing di ciascun provider piuttosto che di un'impostazione di crawling.

Tasso di riempimento del testo dei link per provider e 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% in tutti i domini.
• Apify ha mostrato la variazione maggiore, 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 ha più difficoltà con i siti ricchi di contenuti che hanno strutture di navigazione complesse.
• Firecrawl ha ottenuto i migliori risultati su theregister.com (98%) ma è sceso all'81% su entrepreneur.com, seguendo un andamento simile a Apify.
• Cloudflare è stato il più costante dopo Nimble, rimanendo tra 89 e 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 intensivo di menu di navigazione annidati e di elementi di contenuto dinamico che sono più difficili da convertire in modo pulito in markdown.

Totale dei link nell'output markdown per dominio e profondità massima

La varianza nel conteggio dei link tra i provider è stata costantemente elevata (74-97%), indicando che i provider extract numeri molto diversi di link dalle stesse pagine. Per ottenere una visione più dettagliata di questa disparità, abbiamo misurato il conteggio totale dei link markdown per provider.

• Apify ha restituito il maggior numero di link in assoluto, in particolare su amazon.com con oltre 420K link alla 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 del contenuto della pagina.
• Cloudflare ha raggiunto un picco di 303K su entrepreneur.com alla profondità 10 ma è sceso a 53K alla 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 in totale 3-40K link, con una media di 5-28 link per pagina rispetto a 60-420 per altri provider. Sulla homepage di entrepreneur.com, Nimble ha restituito 13 link contro i 434 di Cloudflare, limitati ai titoli degli articoli principali. Il suo tasso di riempimento del 100% riflette il fatto che tutti i link inclusi avevano testo di ancoraggio, piuttosto che indicare una copertura completa dei link. Nimble non produce link markdown standard. Il suo conteggio include link HTML escaped trovati nell'output markdown.

Tasso di presenza del titolo tra i provider

La somiglianza dei titoli tra i provider ha mostrato una deviazione inferiore all'1% in tutti i test e domini, confermando che quando i provider extract un titolo, restituiscono costantemente lo stesso risultato. Anche il tasso di presenza del titolo è rimasto tra 98 e 100% in tutti i livelli di profondità massima, dimostrando che la profondità di crawling non ha un impatto significativo sull'estrazione del titolo.

Se suddivisi per dominio, sono emerse alcune differenze:

Su entrepreneur.com e theregister.com, la maggior parte dei provider ha raggiunto tassi di presenza del titolo tra il 99 e il 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%. Questo è in linea con la protezione anti-bot più severa di Amazon, che può bloccare o distorcere le risposte delle pagine, inducendo alcuni provider a restituire pagine senza titoli estraibili.

Funzionalità delle migliori API di web crawler

Decodo offre il crawling tramite /crawl, un endpoint della sua Web Data API. Tutti gli endpoint della Web Data API funzionano con un'unica API e un'unica API key. Un processo /crawl raccoglie fino a 10.000 pagine e restituisce ogni pagina come Markdown o HTML.

• Gli utenti impostano la profondità massima, filtrano i percorsi con espressioni regolari e mantengono la scansione su un host, i suoi sottodomini o tutti i domini.
• Il crawler utilizza la sitemap, i link delle pagine o entrambi, e richiede le pagine da un paese e una localizzazione selezionati.
• Una durata massima arresta il processo e conserva le pagine raccolte fino a quel momento.
• Una pagina che fallisce senza JavaScript riceve un ulteriore tentativo con il rendering JavaScript.

L'endpoint /map elenca fino a 147.000 URL da una pagina e dalla sitemap di primo livello del sito senza recuperare il contenuto, così una scansione può indirizzarsi solo ai percorsi selezionati. Il piano gratuito include 10.000 richieste al mese senza carta di credito.

Apify esegue il crawling dei siti web tramite Website Content Crawler, un Actor sulla piattaforma Apify. Per impostazione predefinita recupera le pagine statiche tramite semplice HTTP e passa a un browser headless per le pagine che richiedono JavaScript. Gli utenti possono anche eseguirlo in modalità solo browser o solo HTTP.

• Gli utenti impostano gli URL di inizio, la profondità massima, le pagine massime e i modelli di URL da includere o escludere, e possono aggiungere sitemap per la scoperta.
• Una data “modificato dal” limita le nuove scansioni alle pagine modificate.
• Un selettore CSS rimuove navigazione, intestazioni e piè di pagina prima della conversione.
• Il crawler restituisce testo, Markdown, HTML e screenshot e può scaricare file PDF, Word ed Excel collegati.

Apify collega l'output a LangChain, LlamaIndex, Pinecone e Qdrant e offre il crawler come strumento MCP.

Cloudflare offre un endpoint /crawl nel suo servizio Browser Rendering. Un processo copre fino a 100.000 pagine, viene eseguito per un massimo di sette giorni e i risultati restano disponibili per 14 giorni.

• Il crawler trova le pagine tramite sitemap, link delle pagine o entrambi e filtra gli URL con pattern wildcard.
• Esegue il rendering delle pagine in un browser headless per impostazione predefinita e può invece recuperare HTML semplice senza JavaScript.
• L'output è HTML, Markdown o JSON.

Il crawler rispetta robots.txt, incluso crawl-delay, e si identifica con uno user agent fisso. Cloudflare afferma di non aggirare CAPTCHA o protezioni anti-bot.

L'endpoint /crawl di Firecrawl scopre ed esegue lo scraping delle sottopagine di un URL di partenza e restituisce Markdown, HTML o JSON per ogni pagina.

• Gli utenti impostano un limite di pagine, una profondità di scoperta e filtri di percorso regex.
• La scansione può estendersi a percorsi padre, sottodomini o un salto di link esterni.
• Il crawler combina la sitemap con i link delle pagine, oppure utilizza solo uno dei due.
• Un parametro prompt trasforma un'istruzione in linguaggio naturale in impostazioni di crawling.

I risultati arrivano tramite polling, eventi webhook per pagina o un watcher SDK, e restano disponibili per 24 ore.

Nimble Crawl esegue ogni scansione come processo in background fino a 10.000 pagine e 20 salti di link, e restituisce HTML o Markdown per ogni pagina.

• Gli utenti filtrano i percorsi con espressioni regolari e scelgono se seguire i sottodomini.
• Il crawler utilizza la sitemap, i link delle pagine o entrambi come fonte.
• Gli URL che differiscono solo nei parametri di query possono contare come una sola pagina.
• Ogni scansione può essere eseguita da un paese e una localizzazione selezionati.

Una chiamata di stato riporta quante pagine sono in attesa, completate o non riuscite, e il contenuto di ogni pagina proviene dalla propria chiamata di risultato. I callback vengono attivati quando la scansione inizia, per ogni pagina e alla fine.

Metodologia di benchmark dei web crawler

Abbiamo testato quattro API di crawling (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 identiche impostazioni di base 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 es., india.entrepreneur.com)
• Rendering JavaScript: abilitato, tutti i provider utilizzano un browser headless
• Cache: disabilitata
• Limite di pagine: 1.000 pagine per esecuzione
• Timeout: 7 ore (25.200 secondi)
• Gestione del rate limit: attesa di 20 secondi con fino a 3 tentativi su 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 crawling. I provider sono stati testati in sequenza (non in parallelo), ogni combinazione è stata eseguita una volta e lo stato della scansione è stato interrogato ogni 1 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 il proxy integrato di Apify è stato utilizzato per tutte le richieste.

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 per provider oltre ai parametri standardizzati.

Per Cloudflare, abbiamo utilizzato il piano Workers Paid. Il costo riportato riflette quanto abbiamo speso per eseguire la scansione 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 previsti da questo piano. Il costo effettivo per pagina varia a seconda del livello del piano e dell'eventuale acquisto di pacchetti di crediti aggiuntivi.

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  = {{Web Crawler Benchmark per Alimentare l'IA con i Siti Web}},
  year   = {2026},
  month  = oct,
  howpublished    = {\url{https://aimultiple.com/web-crawler}},
  note   = {AIMultiple. Consultato il 22 ottobre 2026}
}

Registro delle modifiche

9 aggiornamenti

Tutte9Generale8Metodologia1

202620242023

1. 7 apr

   Rimosse le sezioni su tendenze del settore, tipi di crawler ed esempi di web crawling.

2. 6 apr

   Aggiunto un benchmark di quattro API di crawling su tre domini e tre livelli di profondità, con grafici su copertura, velocità, link e titoli.

3. 6 apr

   Aggiunta una sezione metodologia che descrive la configurazione di crawling su quattro fornitori, tre domini e tre livelli di profondità.

4. 25 feb

   Aggiunta una sezione, I web crawler sono legali?, all'articolo.

5. 11 feb

   Aggiornata la sezione "Cos'è un web crawler?" con nuove tendenze e modalità operative.

Cem Dilmegani

Analista principale

Segui

Cem è analista principale presso AIMultiple dal 2017.

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.

Visualizza il profilo completo

Revisionato tecnicamente da

Nazlı Şipi

Ricercatrice IA

Segui

Nazlı è un'analista di dati presso AIMultiple. Ha precedente esperienza nell'analisi dei dati in diversi settori, dove ha lavorato per trasformare dataset complessi in informazioni operative.

Visualizza il profilo completo

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.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento

Aggeliki

Jan 12, 2022 at 16:15

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.

Rispondere