Come raccogliere dati dal web su larga scala senza essere bloccati

Introduzione

Il tuo scraper funziona bene su qualche centinaio di pagine. Prova a utilizzarlo su qualche centinaio di migliaia e metà delle tue richieste riceverà un errore 403, un CAPTCHA o una pagina vuota. Il parser non ha fallito. Il sito di destinazione ha notato che il tuo traffico non si comporta come quello di una persona e ha iniziato a opporre resistenza.

Lo scraping su larga scala è soprattutto una questione di non dare nell’occhio. Qualsiasi sito che valga la pena di essere sottoposto a scraping utilizza una qualche forma di rilevamento dei bot, e ogni richiesta in più rappresenta un’ulteriore possibilità di essere segnalati. Si supera questo ostacolo con le basi fatte bene: i proxy giusti per lo scraping web, una cadenza delle richieste ragionevole, richieste che passino per quelle di un browser reale e un piano per quando un sito reagisce. Questo articolo illustra come avvengono effettivamente i blocchi e come costruire una pipeline che continui a estrarre dati senza far scattare ogni allarme.

Perché i siti bloccano la raccolta automatizzata

I siti non bloccano gli scraper per fare i difficili. Li bloccano perché il tuo traffico costa loro denaro e divulga dati che preferirebbero mantenere riservati. Uno scraper aggressivo può inviare migliaia di richieste al minuto, sovraccaricando i server e distorcendo le analisi. Prezzi, elenchi di prodotti e recensioni sono esattamente ciò che un concorrente desidera, quindi i siti che detengono tali dati li difendono con le unghie e con i denti. Parti dal presupposto che il tuo obiettivo abbia già previsto l’arrivo di persone come te.

Come decidono i sistemi di blocco

Il blocco raramente si basa su un’unica regola. La maggior parte dei sistemi di difesa tiene un punteggio aggiornato per ogni visitatore, e superare una soglia comporta un CAPTCHA o l’accesso negato. Quel punteggio risponde a tre domande: chi sei, quanto sei veloce e come appari da vicino.

Chi sei è la reputazione dell’IP: un intervallo di indirizzi di un data center noto, o un indirizzo che in passato ha tenuto un comportamento sospetto, parte già con dei punti a sfavore. Quanto velocemente ti muovi è la frequenza delle richieste. Che aspetto hai è la tua “impronta digitale”, ovvero le intestazioni che invii insieme al tuo handshake TLS, che rivelano se a effettuare la richiesta è un browser reale o un semplice script.

Cloudflare e Akamai integrano tutti e tre questi elementi in un punteggio in tempo reale per ogni richiesta. È per questo che uno scraper scivola senza intoppi attraverso un sito di piccole dimensioni e si scontra con un muro su uno protetto che esegue lo stesso codice.

Creare un pool di proxy per scalabilità

Parti da chi sei, perché un singolo IP non può gestire un lavoro di grandi dimensioni. Invia centomila richieste da un unico indirizzo e farai scattare rapidamente il controllo di reputazione. Un pool distribuisce quel carico su molti IP in modo che nessuno si distingua: è il livello di base di qualsiasi configurazione di raccolta dati su larga scala. I proxy per il web scraping che scegli qui definiscono il limite massimo per tutto ciò che viene a valle.

Su siti con protezione debole o assente, gli IP dei data center fanno il lavoro pesante: economici, veloci, disponibili in grandi quantità. Per lavori di grande volume sono preferibili gli IP dei data center progettati per la raccolta di grandi volumi di dati, piuttosto che pochi indirizzi condivisi che si esauriscono in un giorno. Il problema è che sono facili da individuare. Secondo TorchProxies (2026), i proxy dei data center raggiungono una percentuale di successo compresa tra il 60 e il 90% su obiettivi non protetti, per poi scendere al 20-40% in presenza dei sistemi di gestione dei bot di Cloudflare o Akamai.

Il calcolo è semplice: se un sito tollera circa 10 richieste al minuto per IP e ne servono 6.000, occorrono almeno 600 IP puliti, più un margine per quelli segnalati.

Logica di regolazione del ritmo delle richieste e di rotazione

Il passo successivo riguarda la velocità di esecuzione. La rotazione determina quale IP gestisce ciascuna richiesta; la regolazione dell’intervallo stabilisce la distanza tra una richiesta e l’altra.

La rotazione per richiesta assegna a ogni chiamata un IP nuovo, ideale per attività stateless come le pagine di prodotto indipendenti. Le sessioni sticky mantengono lo stesso IP per una serie di richieste correlate, necessarie quando un sito tiene traccia di una sessione, come nel caso di un checkout.

La gestione della frequenza è ciò che determina se si evitano i blocchi durante lo scraping o se ci si imbatte direttamente in essi. Rendere casuale il ritardo tra le richieste, poiché un intervallo fisso di 200 ms è di per sé un segnale di bot. Limitare la frequenza per IP e aggiungere un backoff esponenziale, in modo che gli errori costringano a rallentare invece di proseguire a tutti i costi. Il grafico sopra mostra il motivo: il tasso di blocco rimane vicino allo zero finché non si supera la tolleranza del target, poi sale bruscamente. La guida di Ranktracker allo scraping web per gli strumenti SEO mostra come lo stesso ritmo mantenga accurato un rank tracker.

Intestazioni e impronte digitali

Infine, c’è la tua “impronta digitale”. Anche gli IP puliti con un ritmo ragionevole vengono individuati se le richieste stesse gridano “script”. Ogni richiesta porta con sé delle intestazioni e un’impronta digitale TLS, e il sistema di rilevamento confronta entrambi con quelli di un browser reale.

Inizia dall’User-Agent, ma non fermarti lì. Un browser reale invia un insieme coerente di intestazioni Accept, Accept-Language e Accept-Encoding in un ordine costante, mentre una richiesta che le omette o ne stravolge l’ordine salta all’occhio. Alla base c’è l’handshake TLS, sintetizzato in un’impronta digitale JA3. Un client Python e Chrome effettuano l’handshake in modo diverso anche quando le loro intestazioni visibili corrispondono, quindi i sistemi anti-bot efficaci analizzano l’handshake per individuare gli scraper che hanno simulato solo l’aspetto superficiale. Fate in modo che ogni richiesta sembri provenire da un browser dall’inizio alla fine.

Gestione dei CAPTCHA e dei blocchi soft

Non tutti i blocchi si manifestano apertamente. Un blocco duro è evidente: una schermata CAPTCHA o un errore 403. Un blocco soft si nasconde. Il sito restituisce un codice di stato 200, ma il corpo della risposta è limitato, ridotto o contaminato con dati errati destinati a compromettere il vostro set di dati senza avvisarvi.

Il rilevamento è la priorità assoluta. Segnalate le risposte che risultano sospettosamente piccole o identiche tra pagine che dovrebbero differire, e trattatele come errori anche quando lo stato indica successo. Gli input errati corrompono tutto ciò che viene costruito su di essi, quindi i controlli sulla qualità dei dati sono importanti tanto quanto l’accesso. La guida di Ranktracker al monitoraggio accurato del posizionamento mostra come gli input rumorosi rovinino i numeri che riportate.

Quando compaiono i CAPTCHA, esistono servizi per risolverli, ma la soluzione più economica è a monte: rallenta la frequenza, varia di più, ripulisci l’impronta digitale e smetterai di ricevere la sfida.

Quando passare al livello residenziale

A volte è proprio il livello di IP a rappresentare il limite massimo. Quando la gestione dei bot continua a bloccare il pool del tuo data center, indipendentemente da quanto tu regoli e mascheri il traffico, è il segnale che devi passare a un livello superiore.

Gli IP residenziali provengono da veri dispositivi domestici, quindi godono di un livello di fiducia che gli intervalli dei data center non riescono mai a ottenere. Per gli obiettivi più ostici, passare a IP residenziali a rotazione vi garantisce un traffico che appare come quello di normali utenti domestici, superando i filtri che respingono gli indirizzi dei data center a prima vista.

Il prezzo da pagare è la velocità e il costo. I proxy dei datacenter funzionano da 3 a 10 volte più velocemente, con tempi di risposta inferiori a 200 ms contro i 500 ms-2 secondi dei proxy residenziali, secondo ProxyWing. Su milioni di richieste, la differenza si fa sentire, quindi gestisci i livelli: mantieni i datacenter come impostazione predefinita e instrada solo le richieste bloccate verso i proxy residenziali.

I risultati di ricerca sono il caso classico. Se state effettuando lo scraping delle SERP per alimentare uno strumento come il SERP Checker di Ranktracker, le pagine più difficili spesso vi costringono a utilizzare i proxy residenziali.

Eseguite un test su un singolo sito di destinazione prima di scalare

Prima di indirizzare uno scraper verso l’intero elenco di obiettivi, eseguitelo su un singolo sito protetto e osservate i codici di risposta. Iniziate con un piccolo pool di datacenter, regolate la frequenza in modo prudente, poi aumentate la frequenza fino a quando non compaiono i blocchi e tornate all’ultimo livello in cui non si sono verificati problemi. Quel numero rappresenta il vostro limite massimo per IP e determina la dimensione del pool per l’intero lavoro. Impostate correttamente i proxy per il web scraping e la frequenza su un sito, e la stessa configurazione sarà scalabile per tutti gli altri.

Domande frequenti

Di quanti proxy ho bisogno per eseguire lo scraping su larga scala?

Dipende dalla tolleranza del sito di destinazione e dalla tua velocità di trasmissione. Calcola quante richieste al minuto un IP riesce a sopportare prima di essere segnalato, dividi la tua velocità target per quel numero, quindi aggiungi un margine di sicurezza. Ti servono 6.000 richieste al minuto su un sito che tollera 10 per IP? Ciò significa oltre 600 IP puliti, non una manciata di IP sfruttati fino all’esaurimento.

I proxy di datacenter o quelli residenziali sono migliori per lo scraping web?

Nessuno dei due vince a mani basse. Quelli dei data center sono più veloci ed economici e gestiscono bene i siti non protetti. Quelli residenziali sono più lenti e costosi, ma resistono a una gestione rigorosa dei bot. La maggior parte delle pipeline utilizza entrambi, imposta come predefinito quelli dei data center e passa a quelli residenziali solo quando i blocchi lo impongono.

Perché vengo ancora bloccato anche con i proxy?

Di solito è a causa del pacing o delle impronte digitali, non degli IP. Anche se si ruota un ampio pool di indirizzi, ma lo si utilizza alla velocità della macchina con le intestazioni predefinite, lo schema rimane comunque visibile. Rallenta, randomizza e cerca innanzitutto di sembrare un browser.

È consentito lo scraping dei dati pubblici?

Si tratta di una zona grigia dal punto di vista legale che varia a seconda della giurisdizione e dei termini di servizio del sito. Limitatevi ai dati visibili pubblicamente, rispettate il file robots.txt ove possibile, evitate i dati personali e chiedete una consulenza legale prima di qualsiasi estrazione commerciale su larga scala.