Benchmark dei crawler web 2026: dall'indicizzazione alla licenza agentica Intel

Abbiamo confrontato le prestazioni di quattro API di crawling su tre domini di diversa difficoltà (amazon.com, entrepreneur.com, theregister.com) a tre livelli di profondità massima (5, 10, 20) con un limite di 1.000 pagine, misurando la copertura di crawling, il tempo di esecuzione, l'individuazione dei link, la qualità dei link in formato Markdown e l'accuratezza dell'estrazione dei titoli.

Se il tuo obiettivo è:

• Trasforma le pagine web in dati strutturati: consulta la nostra guida sul web scraping .
• Esplora interi siti web, continua a leggere.

benchmark dei crawler web

È possibile consultare la nostra metodologia di benchmarking.

Numero medio di pagine scansionate rispetto al costo per 1.000 pagine

Pagine scansionate su diversi domini in base alla 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 antibot di Amazon. In particolare, l'aumento della profondità massima non ha avuto praticamente alcun impatto sul numero di pagine che Firecrawl è stato in grado di scansionare su qualsiasi dominio.

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

Cloudflare ha mostrato un comportamento incoerente nei vari test:

• Sul sito theregister.com, con una profondità massima di 5, ha scansionato solo 100 pagine, mentre con una profondità massima di 20 ha raggiunto quasi 1.000 pagine.
• Come osservato nei test precedenti, Cloudflare occasionalmente esegue la scansione di una sola pagina e poi termina completamente l'operazione. 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 persisteva. Con una profondità massima di 10 su theregister.com, si è verificato esattamente questo problema: Cloudflare ha eseguito la scansione di una sola pagina prima di fermarsi.
• Su entrepreneur.com, Cloudflare ha scansionato 780 pagine a una profondità di 5, aumentate a 885 a una profondità di 10, ma poi calate drasticamente a sole 172 pagine a una profondità di 20. Questo calo potrebbe essere correlato al fatto che lo scheduler di scansione di Cloudflare declassa o interrompe per timeout le catene di link più profonde, oppure potrebbe riflettere un limite di concorrenza interno che causa la terminazione prematura del processo quando la frontiera di scansione diventa troppo ampia a profondità maggiori.
• Su amazon.com, Cloudflare ha scansionato 905 pagine con una profondità di 5, ma il numero è diminuito costantemente all'aumentare della profondità massima, scendendo a 809 con una profondità di 10 e a 795 con una profondità di 20, suggerendo che configurazioni di scansione più profonde potrebbero far sì che Cloudflare impieghi più tempo nell'overhead di individuazione dei link piuttosto che nel 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 a profondità 5 ma ha mostrato lievi cali a profondità maggiori (896 a profondità 10, 983 a profondità 20), probabilmente a causa del timeout di 7 ore raggiunto prima del completamento della scansione completa a livelli più profondi, tutte le esecuzioni di Nimble sono terminate con uno stato di timeout. Amazon si è rivelato più impegnativo:

• Alla profondità 5 è riuscita a raggiungere solo 319 pagine, ma alla profondità 10 è balzata a 988 pagine, per poi scendere a 906 alla profondità 20.
• Questa incoerenza riflette probabilmente la combinazione dei meccanismi di protezione dai bot di Amazon e dei vincoli di timeout di Nimble, per cui le scansioni più approfondite impiegano più tempo per elaborare ogni pagina e potrebbero incontrare più sfide anti-bot lungo il percorso

Tempo di esecuzione nei domini in base alla profondità massima

Firecrawl è risultato il provider più veloce su tutti i domini, completando le scansioni in meno di 5 minuti, in genere tra 75 e 265 secondi. Questa velocità va a scapito della copertura, poiché Firecrawl ha anche scansionato il minor numero di pagine. In sostanza, termina rapidamente perché si ferma prima del previsto.

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 e 15.900 secondi (2-4 ore), a causa delle strutture dei siti più ampie e complesse. Nonostante i tempi più lunghi, Apify ha sempre raggiunto il limite di 1.000 pagine, risultando il più affidabile in termini di rapporto copertura/tempo.

Cloudflare ha mostrato una tempistica che rispecchia i suoi conteggi di scansione incoerenti:

• Su theregister.com, alla profondità 10, la scansione si è completata in appena 1 secondo, perché ha scansionato solo 1 pagina prima di fermarsi.
• Su entrepreneur.com, con una profondità di 20 pagine, la scansione è stata completata in 10 secondi dopo aver analizzato solo 172 pagine.
• Quando Cloudflare completa una scansione completa, i tempi variano da 3.500 a 25.200 secondi.
• Man mano che la profondità massima aumenta, Cloudflare sembra dare priorità al raggiungimento delle pagine più profonde rispetto all'esplorazione in ampiezza, scansionando meno pagine ma completando l'operazione più velocemente. Su amazon.com, il tempo di esecuzione è sceso da 25.200 secondi (timeout) a una profondità di 5 a soli 5.660 secondi a una profondità di 20, mentre anche il numero di pagine scansionate è diminuito da 905 a 795. Ciò suggerisce che il crawler di Cloudflare cambia strategia a profondità maggiori, dedicando meno tempo all'esplorazione in ampiezza e più tempo all'esplorazione profonda.

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 ha completato l'esecuzione senza timeout. Nel benchmark completo con profondità da 5 a 20 e un limite di 1.000 pagine, ha continuato a funzionare 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 e entrepreneur.com), il che significa che è rimasto attivo durante le 7 ore, ma non ha mai segnalato il completamento.

Tasso di riempimento del testo del link tra i vari fornitori in base alla profondità massima

Per valutare la qualità dell'output Markdown, abbiamo misurato la percentuale di link presenti nel Markdown di ciascun provider che contengono il testo di ancoraggio, ovvero la parte di testo cliccabile del 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% su tutte le profondità
• Cloudflare : 91-94%
• Firecrawl : 90%
• Apify : 77-78%, circa 1 link su 5 senza testo di ancoraggio

La profondità di scansione ha avuto un impatto minimo sui tassi di riempimento per qualsiasi provider, il che suggerisce che si tratti di una caratteristica del motore di analisi di ciascun provider piuttosto che di un'impostazione di scansione.

Tasso di riempimento del testo dei link tra i vari provider per dominio

Analizzando i tassi di riempimento su diversi domini, emerge come la complessità del sito influisca sulla qualità dell'estrazione dei link da parte di ciascun fornitore.

• Nimble mantenuto al 100% su tutti i domini.
• Apify ha mostrato la maggiore variabilità, pari all'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. Questo suggerisce che Apify ha 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 andamento simile a quello di Apify.
• Cloudflare è risultato il più costante dopo Nimble, mantenendosi tra l'89% e il 94% indipendentemente dal dominio.

Entrepreneur.com si è rivelato il dominio più difficile per l'estrazione del testo dei link: sia Apify (66%) che Firecrawl (81%) hanno ottenuto i punteggi più bassi, probabilmente a causa dell'ampio utilizzo di menu di navigazione annidati ed elementi di contenuto dinamici che sono più difficili da convertire in modo pulito in Markdown.

Numero totale di collegamenti nell'output Markdown tra i domini in base alla profondità massima

La variabilità nel numero di link tra i diversi fornitori è risultata costantemente elevata (74-97%), indicando che i fornitori estraggono un numero di link molto diverso dalle stesse pagine. Per ottenere una visione più dettagliata di questa disparità, abbiamo misurato il numero totale di link in formato Markdown per ciascun fornitore.

• Apify ha restituito il maggior numero di link in assoluto, in particolare su amazon.com con oltre 420.000 link a una profondità di 5 (circa 423 per pagina). Su entrepreneur.com si è stabilizzato intorno ai 63.000 indipendentemente dalla profondità. Il suo output include tracker pubblicitari e pixel di tracciamento oltre ai link al contenuto della pagina.
• Cloudflare ha raggiunto un picco di 303.000 visualizzazioni su entrepreneur.com a una profondità di 10, ma è sceso a 53.000 a una profondità di 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 su tutte le configurazioni, limitato dal suo basso numero di pagine.
• Nimble ha restituito un totale di 3-40.000 link, con una media di 5-28 link per pagina rispetto ai 60-420 degli altri provider. Sulla homepage di entrepreneur.com, Nimble ha restituito 13 link contro i 434 di Cloudflare, limitati ai titoli principali degli articoli. Il suo tasso di riempimento del 100% riflette il fatto che i link inclusi avevano tutti un testo di ancoraggio, piuttosto che indicare una copertura completa dei link. Nimble non produce link in formato Markdown standard. Il suo conteggio include i link HTML codificati trovati all'interno dell'output Markdown.

Tasso di interesse attuale tra i fornitori

La similarità dei titoli tra i diversi provider ha mostrato una deviazione inferiore all'1% in tutti i test e domini, confermando che quando i provider estraggono un titolo, restituiscono sempre lo stesso risultato. Anche la percentuale di titoli presenti è rimasta tra il 98% e il 100% per tutti i livelli di profondità massima di scansione, dimostrando che la profondità di scansione non ha un impatto significativo sull'estrazione dei titoli.

Analizzando i dati per ambito, sono emerse alcune differenze:

Su entrepreneur.com e theregister.com, la maggior parte dei fornitori ha raggiunto tassi di presenza del titolo pari al 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 le più rigide misure di protezione antibot di Amazon, che possono bloccare o distorcere le risposte delle pagine, causando ad alcuni fornitori la visualizzazione di pagine senza titoli estraibili.

Che cos'è un web crawler?

Un web crawler, a volte chiamato "spider" o "agente", è un bot che naviga in internet per indicizzare i contenuti.

I crawler si sono evoluti oltre i motori di ricerca e ora fungono da strato dati agentico. Agiscono come occhi per agenti di intelligenza artificiale autonomi come Claude Code e OpenAI Operator, assistendoli in attività in tempo reale come la ricerca di mercato e le transazioni a più fasi.

Che cosa fa un web crawler?

La scansione del web è stata suddivisa in tre modalità, ciascuna progettata per un obiettivo diverso del crawler.

1. Modalità di scoperta (tradizionale): i bot dei motori di ricerca come Googlebot eseguono la scansione degli URL per l'indicizzazione, aiutando le persone a trovare risultati tramite i motori di ricerca.
2. Modalità di recupero (RAG): i bot basati sull'IA come ChatGPT-User o PerplexityBot recuperano pagine specifiche in tempo reale per rispondere alle richieste degli utenti. Utilizzano il markdown anziché l'HTML per rispettare i limiti di token del modello di IA.
3. Modalità agente (orientata all'azione): questo nuovo tipo di crawler, previsto per il 2026, fa molto di 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 tramite intelligenza artificiale è ormai 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.

Nell'era dell'IA, conviene sviluppare internamente o acquistare web crawler?

1. Costruire il proprio veicolo cingolato

Ideale per proteggere la proprietà intellettuale fondamentale e consentire una personalizzazione approfondita. La creazione ora richiede lo sviluppo di un livello di agenti proprietario, non solo la scrittura di semplici script Scrapy.

• Quando sviluppare un crawler: scegli questo approccio se il tuo crawler ti offre un vantaggio competitivo unico. Ad esempio, sviluppane uno tu stesso se stai creando 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 di intelligenza artificiale interni di interagire con il web.

2. Utilizzo di strumenti e API per la scansione del web

Gli strumenti gestiti si sono evoluti da semplici scraper ad agenti autonomi.

• Estrazione senza manutenzione: strumenti moderni come Kadoa e Firecrawl utilizzano un'intelligenza artificiale auto-riparante. È sufficiente specificare i dati richiesti, come ad esempio "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 fornitori offrono la conformità integrata con la legge europea sull'intelligenza artificiale (AI Act). Gestiscono i registri di controllo obbligatori e i controlli di opt-out per il copyright, operazioni complesse da implementare autonomamente.
• Rapidità nel raggiungimento dei risultati: l'acquisto di una piattaforma può far passare il tuo progetto dall'idea alla produzione in poche settimane.

Figura 5: Spiegazione del funzionamento di un confine URL.

I crawler web sono legali?

In generale, la scansione del web è legale , ma a seconda di come e cosa si scansiona, si potrebbe rapidamente incorrere in problemi legali. Quattro pilastri principali determinano la legalità della scansione (e dello scraping che in genere ne consegue):

1. Pubblico vs. privato: analizza solo i dati accessibili al pubblico senza necessità di creare un account.

2. Informazioni personali: Evitate di fornire informazioni personali identificabili (nomi, indirizzi email e indirizzi postali) a meno che non abbiate una base giuridica valida.

3. Stato di salute del server: utilizzare limiti di frequenza per evitare di rallentare il server; evitare attacchi "DDoS" a un sito web.

4. Diritto d'autore : Articoli e immagini sono protetti da copyright, ma i dati (prezzi, date) non lo sono.

Qual è la differenza tra web crawling e web scraping?

Il web scraping consiste nell'utilizzo di web crawler per scansionare e memorizzare tutto il contenuto 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 ad esempio estrarre tutte le notizie finanziarie per l'analisi degli investimenti o cercare nomi di aziende specifiche.

Tradizionalmente, una volta che un web crawler aveva scansionato e indicizzato tutti gli elementi di una pagina web, un web scraper estraeva i dati dalla pagina indicizzata. Tuttavia, al giorno d'oggi i termini scraping e crawling vengono usati in modo intercambiabile, con la differenza che crawler tende a riferirsi più ai crawler dei motori di ricerca. Poiché anche aziende diverse dai motori di ricerca hanno iniziato a utilizzare i dati web, il termine web scraper ha gradualmente sostituito il termine web crawler.

Quali sono le sfide della scansione del web?

1. Aggiornamento del database

Il contenuto dei siti web viene aggiornato regolarmente. Le pagine web dinamiche, ad esempio, modificano il loro contenuto in base alle attività e ai comportamenti dei visitatori. Ciò significa che il codice sorgente del sito web non rimane invariato dopo la scansione. Per fornire all'utente le informazioni più aggiornate, il crawler deve scansionare nuovamente le pagine web con maggiore frequenza.

2. Trappole per striscianti

I siti web utilizzano diverse tecniche, come le trappole per crawler, per impedire ai crawler di accedere e scansionare determinate pagine web. Una trappola per crawler, o spider trap, induce un crawler a effettuare un numero infinito di richieste, intrappolandolo in un circolo vizioso. I siti web possono anche creare trappole per crawler involontariamente. In ogni caso, quando un crawler incontra una trappola, entra in una sorta di ciclo infinito che spreca le sue risorse.

3. Larghezza di banda della rete

Il download di un gran numero di pagine web irrilevanti, l'utilizzo di un web crawler distribuito o la scansione ripetuta di molte pagine web comportano tutti un elevato consumo di capacità di rete.

4. Pagine duplicate

I bot di scansione web analizzano principalmente tutti i contenuti duplicati presenti 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 indicizzare e classificare. Quando il bot Google rileva un gruppo di pagine web identiche nei risultati di ricerca, ne indicizza e seleziona solo una da visualizzare in risposta alla query di ricerca dell'utente.

Le 3 migliori pratiche per la scansione del web

1. Cortesia/Velocità di marcia

I siti web impostano una frequenza di scansione per limitare il numero di richieste effettuate dai bot di scansione. La frequenza di scansione indica quante richieste un crawler può effettuare al tuo sito web in un determinato intervallo di tempo (ad esempio, 100 richieste all'ora). Ciò consente ai proprietari dei siti web di proteggere la larghezza di banda dei propri server e ridurre il sovraccarico dei server. Un crawler deve rispettare il limite di scansione del sito web di destinazione.

2. Conformità al file Robots.txt

Il file robots.txt è un file di testo posizionato nella directory principale di un sito web che indica ai crawler quali pagine possono o non possono accedere. Si tratta di uno standard volontario, il che significa che i bot conformi lo rispettano, ma tecnicamente non impedisce l'accesso. Seguire le indicazioni del file robots.txt di un sito web è considerata una buona pratica e, in molte giurisdizioni, ignorarlo può esporvi a rischi legali o reputazionali.

3. Rotazione IP

I siti web utilizzano 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 pagine visualizzate.

Questo metodo consente ai proprietari di siti web di rilevare il "traffico non umano" e bloccare l'indirizzo IP del bot. Per evitare il rilevamento, è possibile integrare proxy rotanti , come i proxy residenziali , nel proprio crawler web.

Metodologia di benchmarking per i web crawler

Abbiamo testato quattro API di crawling (Apify, Nimble, Cloudflare, Firecrawl) su tre domini di diversa difficoltà: amazon.com (forte protezione dai bot), entrepreneur.com (sito con contenuti complessi) e theregister.com (sito di notizie).

Configurazione condivisa

Tutti i fornitori hanno ricevuto le stesse impostazioni di base per garantire un confronto equo:

• Mappa del sito: Disabilitata, i fornitori devono individuare le pagine solo tramite link HTML
• Collegamenti 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 utilizzano un browser headless
• Cache: disabilitata
• Limite di pagine: 1.000 pagine per ciclo di stampa
• Tempo limite: 7 ore (25.200 secondi)
• Gestione del limite di richieste: attesa di 20 secondi con fino a 3 tentativi sulla porta HTTP 429

Ciascun 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 scansione. I provider sono stati testati in sequenza (non in parallelo), ogni combinazione è stata eseguita una sola volta e lo stato di scansione è stato verificato ogni secondo.

Apify è stato configurato con l'attore website-content-crawler utilizzando Playwright/Firefox come browser headless. L'accesso al sottodominio è stato controllato tramite pattern glob e per tutte le richieste è stato utilizzato il proxy integrato di Apify.

Gli indirizzi IP Nimble, Cloudflare e Firecrawl sono stati configurati utilizzando le rispettive API REST con le impostazioni condivise descritte in precedenza. 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 scansionare 1.000 pagine con questo piano. Cloudflare addebita i costi in base al tempo di rendering del browser anziché al numero di pagine.

Per Firecrawl, abbiamo utilizzato il piano Hobby. Il costo riportato è l'importo proporzionale per 1.000 crediti dei 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 aggiuntivi.

Cem Dilmegani

Analista principale

Segui

Cem è analista principale presso AIMultiple dal 2017. AIMultiple fornisce informazioni a centinaia di migliaia di aziende (secondo SimilarWeb), tra cui il 55% delle aziende Fortune 500, ogni mese. Il lavoro di Cem è stato citato da importanti pubblicazioni globali come Business Insider, Forbes, Washington Post, società globali come Deloitte e HPE, ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione Europea. È possibile consultare l'elenco di altre aziende e risorse autorevoli che hanno citato AIMultiple. Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, responsabile acquisti tecnologici e imprenditore nel settore tecnologico. Ha fornito consulenza alle aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un report di McKinsey sulla digitalizzazione. Ha guidato la strategia tecnologica e gli acquisti di un'azienda di telecomunicazioni, riportando direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto un fatturato annuo ricorrente a 7 cifre e una valutazione a 9 cifre partendo da zero in soli 2 anni. Il lavoro di Cem in Hypatos è stato oggetto di articoli su importanti pubblicazioni tecnologiche come TechCrunch e Business Insider. Cem partecipa regolarmente come relatore a conferenze internazionali di settore. Si è laureato in ingegneria informatica presso l'Università di Bogazici e ha conseguito un MBA presso la Columbia Business School.

Visualizza il profilo completo

Revisionato tecnicamente da

Nazlı Şipi

Ricercatore di intelligenza artificiale

Segui

Nazlı è un'analista di dati presso AIMultiple. Ha maturato esperienza nell'analisi dei dati in diversi settori, dove si è occupata di trasformare set di dati complessi in informazioni utili.

Visualizza il profilo completo

Commenti 1

Condividi i tuoi pensieri

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.

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