Scrapare Google Search senza farsi bloccare: cosa succede davvero

“Google blocca gli scraper” è vero ma troppo vago per agire. Ecco cosa succede davvero, in ordine, quando uno script comincia a mandargli query automatizzate, e perché la prima soluzione tipica (più proxy) rimanda solo il problema.

Il rate limit è per IP, ed è più severo di quanto pensi

Google limita in base al volume di richieste da un singolo indirizzo IP in una finestra breve. Le fasce IP dei datacenter hanno un limite notevolmente più stretto di quelle residenziali, perché Google riesce a capire che una richiesta arriva da AWS, Google Cloud o un hosting provider invece che dalla connessione di casa di qualcuno. Una manciata di richieste rapide da un singolo IP di datacenter spesso basta a far scattare una sfida. È il primo muro contro cui sbatte quasi chiunque, ed è per questo che “basta aggiungere un ritardo” funziona esattamente finché il tuo volume di richieste resta banale.

CAPTCHA e il muro del consenso

Superato il rate limit, la risposta successiva di Google non è un errore, è una pagina diversa: una sfida CAPTCHA, o nel traffico UE/UK, un interstiziale di consenso cookie che va accettato prima che i risultati di ricerca vengano renderizzati. Entrambi rompono uno script che si aspetta organic_results in cima all’HTML. Nessuno dei due si risolve ritentando: un CAPTCHA richiede un umano (o un servizio di risoluzione a pagamento, che è un costo a sé e un problema di affidabilità a sé), e un muro di consenso richiede una sessione che l’ha già accettato, il che significa gestione dei cookie che la maggior parte degli scraper non implementa.

Il fingerprinting va oltre l’IP

L’indirizzo IP è il primo segnale, non l’unico. I sistemi anti-automazione di Google guardano anche le caratteristiche dell’handshake TLS, l’ordine e la completezza degli header HTTP, segnali a livello browser quando è coinvolto un browser headless (dimensione del viewport, font installati, stringa del renderer WebGL, se navigator.webdriver è impostato), e pattern comportamentali come richieste che arrivano a intervalli sospettosamente regolari. Una richiesta che supera il rate limit ma ha un header User-Agent scarno e nessuno degli header che manderebbe una vera richiesta Chrome si legge comunque come automatizzata. Ecco perché cambiare proxy senza sistemare anche il resto del fingerprint della richiesta compra molto poco.

La matematica della paginazione che nessuno mette in conto

Google non rispetta più il parametro num=100 che una volta restituiva 100 risultati in una sola richiesta. Ottenere “i primi 100 risultati” per una query oggi significa dieci richieste paginate separate, dieci risultati a pagina. Se il tuo foglio di calcolo per il rank tracking è stato costruito attorno alla vecchia assunzione, il tuo volume reale di richieste, e la tua esposizione reale ai problemi di rate limit e fingerprinting sopra, è 10 volte quello che dice il foglio. Questo da solo ha mandato in crisi stime di costo e piani infrastrutturali scritti prima del cambiamento e mai più rivisti.

Perché i proxy da soli non risolvono

I proxy residenziali rotanti risolvono esattamente uno dei quattro problemi sopra: il rate limit basato su IP. Non fanno niente per le pagine CAPTCHA già scattate, niente per il fingerprinting TLS e degli header, e niente per la matematica della paginazione. Un pool di proxy abbinato a un ingenuo requests.get con header di default verrà comunque sfidato, solo da un set rotante di IP invece che da uno solo. Risolvere tutti e quattro i problemi da solo significa far girare un vero motore browser (per la parità di fingerprint TLS e JS), mantenere profili di header che imitino traffico reale, gestire i flussi di consenso, e pagare banda proxy, continuamente, man mano che il rilevamento di Google cambia. È un impegno infrastrutturale permanente, non uno script una tantum.

La via dell’API

L’alternativa è non far girare niente di tutto questo da solo:

import requests

API_KEY = "faf_live_..."  # la tua chiave FastAF

resp = requests.get(
    "https://api.fastaf.co/v1/serp",
    params={"query": "web scraping api", "country": "us"},
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=60,
)
resp.raise_for_status()

for result in resp.json()["organic_results"]:
    print(result["rank"], result["title"], result["link"])

La richiesta passa attraverso infrastruttura costruita per gestire rate limit, fingerprinting e muri di consenso, e ricevi indietro JSON già parsato: organic_results, e people_also_ask, knowledge_graph, ads o related_searches quando la query li produce. Una ricerca costa 5 crediti, e le richieste fallite non vengono mai fatturate, dato che i crediti vengono riservati quando la richiesta parte e restituiti se non torna nessun risultato.

La versione breve

Quattro meccanismi separati si sommano contro uno scraper grezzo: rate limit IP, muri CAPTCHA e di consenso, fingerprinting oltre l’IP, e un costo di paginazione che è 10 volte quello che sembra sulla carta. Un pool di proxy affronta uno dei quattro. Se valga la pena costruirlo dipende da quanto tempo di ingegneria vuoi spendere sull’infrastruttura di ricerca invece che sul prodotto che consuma i risultati. Vedi i prezzi per il costo in crediti al tuo volume.