Ancora un anno fa, era possibile estrarre i risultati di Google con una sola richiesta GET con il parametro num=100 — cento risultati arrivavano in HTML puro. Nel 2026, questo non funziona più: Google ha bloccato l'accesso senza JavaScript, ha ridotto a cento i risultati per pagina e ha aggiunto un blocco AI Overviews, che viene renderizzato in modo asincrono e non è visibile da ogni IP. Vediamo come raccogliere la SERP in queste nuove condizioni, quali trappole nascoste ci sono e perché la scelta del tipo di proxy è diventata più importante del parser stesso.
Per chi è questa guida
Il parsing dei risultati di ricerca (SERP scraping) non riguarda solo le posizioni SEO. Oggi viene utilizzato da:
- Specialisti SEO e agenzie — monitorano l'organico, i featured snippets, "Le persone chiedono anche", i risultati locali e se il sito è presente negli AI Overviews.
- Analisti di mercato — monitorano chi Google cita nei blocchi AI per query commerciali e come cambia la prima pagina dei concorrenti.
- Team di AI e data — raccolgono la SERP come fonte di dati per sistemi RAG, addestramento di modelli e verifica dei fatti.
Tutti condividono un problema comune: Google nel 2026 distingue attivamente il traffico automatico da quello reale, e senza la giusta infrastruttura, la raccolta dei dati si interrompe dopo le prime decine di richieste.
Cosa è cambiato: tre colpi di Google ai scraper
Per rendere la guida onesta, iniziamo con il motivo per cui le vecchie istruzioni non funzionano più.
Gennaio 2025 — SearchGuard. Google ha lanciato un sistema di sfide JavaScript: una normale richiesta HTTP tramite requests o httpx ora riceve non HTML, ma una pagina di sfida. Senza l'esecuzione di JavaScript, non è possibile vedere i risultati — il parsing diretto "a testa alta" fallisce immediatamente.
Settembre 2025 — fine di num=100. Google ha rimosso il parametro che forniva 100 risultati per richiesta. Ora, i top-100 sono dieci richieste separate con paginazione. Per un monitoraggio approfondito, questo rappresenta un aumento letterale di dieci volte nel numero di richieste (e, di conseguenza, del carico sui proxy e del budget).
Dicembre 2025 — pressione legale. Il 19 dicembre 2025, Google ha presentato una denuncia DMCA contro SerpApi, affermando che SearchGuard è un "mezzo tecnico di protezione" (technological protection measure), e la sua elusione rientra nelle norme anti-elusione. Il precedente non è ancora risolto, ma stabilisce il tono: il parsing grigio di Google diventa sia tecnicamente che legalmente più costoso.
Inoltre, va notato che l'API di ricerca personalizzata ufficiale di Google sta per essere chiusa: ai clienti esistenti è stata comunicata una scadenza per la migrazione entro il 1 gennaio 2027. Quindi, anche l'alternativa "legale" si sta restringendo.
La principale novità dei risultati — AI Overviews
AI Overviews (in passato SGE) sono un riepilogo generato dall'IA in cima ai risultati con link alle fonti. Per lo scraping, questo è l'elemento più complesso del 2026 per tre motivi.
Ce ne sono molti. Secondo i dati di Ahrefs, gli AI Overviews appaiono in circa il 30% delle richieste; stime più recenti (Olostep) indicano fino al 48% di tutte le richieste e fino all'80% di quelle informative. Ignorare questo blocco significa raccogliere un quadro dei risultati incompleto.
Vengono renderizzati in modo asincrono. Il blocco esiste in tre stati: arriva subito in HTML (raramente), viene caricato tramite JavaScript dopo alcuni secondi dalla pagina principale (il caso più comune) o non appare affatto. Con il caricamento ritardato, la risposta HTTP grezza contiene un contenitore vuoto — il contenuto viene recuperato successivamente, e il parser deve aspettare (nella pratica, circa 8 secondi nell'automazione del browser).
Non sono visibili da ogni IP. Questo è il punto chiave di cui tacciono le vecchie guide: Google considera gli utenti mobili come il pubblico prioritario per la ricerca AI. Nella pratica, questo significa che con IP da data center, l'AI Overview spesso non viene restituito affatto, mentre la stessa richiesta tramite un operatore mobile restituisce l'intero blocco. Anche i principali aggregatori riconoscono l'incompletezza: SerpApi all'inizio del 2026 dichiarava circa il 68% di successo nel rilevamento degli AI Overviews.
Analisi passo passo: come raccogliere la SERP nel 2026
- Definite il volume. Fino a ~100 richieste al giorno è possibile gestirle con la propria automazione del browser. Da 100 a 10.000 — è necessario un parser gestito o un SERP-API. Oltre 10.000 al giorno senza un'infrastruttura enterprise con batch e webhook non è possibile. Questo determina tutto il resto dello stack.
- Raccogliete l'URL corretto. L'endpoint di base è /search, i parametri chiave sono: q (richiesta, URL-encoding), hl (lingua dell'interfaccia), gl (paese dei risultati), start (paginazione: start=10 — seconda pagina, start=20 — terza e così via). Ricordate: num=100 non funziona più, la profondità si ottiene solo tramite la paginazione.
- Utilizzate il rendering del browser. Poiché senza JavaScript non ci sono risultati, lo stack di base è Playwright o Selenium con Chromium headless. Assicuratevi di rimuovere i marker di automazione (flag --disable-blink-features=AutomationControlled), altrimenti l'antibot rileverà il browser controllato dalle proprietà del navigator.
- Attendete l'AI Overview. Dopo il caricamento della pagina, non afferrate subito il DOM: lasciate stabilizzarsi il networkidle e aspettate il caricamento del blocco (riferimento — fino a 8 secondi). La presenza del blocco è più affidabile da determinare tramite il testo del titolo "AI Overview", piuttosto che tramite le classi CSS — queste sono dinamiche e cambiano (i condizionali Kevs9, Y3BBE oggi sono uno, domani un altro).
- Parse per struttura, non per classi. Prendete l'organico tramite i tag di intestazione (h3) e la semantica, non tramite nomi di classi fragili. Dalla SERP nel 2026 sono disponibili: risultati organici, featured snippets, "Le persone chiedono anche", query correlate, knowledge graph, pacchetto locale, pubblicità e citazioni all'interno dell'AI Overview.
- Ruotate gli IP e rallentate. Impostate pause realistiche tra le richieste (4–12 secondi) e cambiate IP circa ogni 5 minuti, variando città/operatore. Un ritmo troppo regolare e un solo IP sono il modo più veloce per incappare in un captcha.
Insidie
- AI Overview "vuoto". Se prelevate il DOM subito dopo il caricamento, il blocco ritardato sarà vuoto — e deciderete che non esiste. Pianificate sempre un'attesa e una verifica successiva.
- Sessioni usa e getta per il caricamento. Alcuni API hanno una chiave di sessione per il caricamento dell'AI Overview ritardato che è usa e getta e vive circa 60 secondi — non contate di riutilizzarla in seguito.
- Falsa economia sui data center. Gli IP da data center economici catturano captcha già dopo 5–10 richieste e in aggiunta non mostrano gli AI Overviews. Il risparmio si traduce in dati incompleti e tempo perso.
- Selettori fragili. Se vi siete legati ai nomi delle classi CSS — il parser si romperà al primo redesign dei risultati. Attenetevi al testo e alla struttura.
- Impronta uniforme delle richieste. User-Agent, tempistiche e intestazioni identiche su tutti i flussi rivelano un botnet. Variegate il fingerprint così come gli IP.
Quale tipo di proxy scegliere
Nel 2026, sono i proxy, e non il parser, a determinare se vedrete l'intera SERP. Analizziamo per compiti.
Proxy mobili — per gli AI Overviews e le richieste più "pesanti". Poiché Google restituisce i blocchi AI principalmente al pubblico mobile, gli IP reali degli operatori (T-Mobile, Verizon, Vodafone e simili) attivano più stabilmente l'AI Overview e supportano notevolmente di più — secondo le osservazioni, 50–200 richieste prima di incontrare attrito contro 5–10 per i data center. Inoltre, l'IP CGNAT mobile condivide un indirizzo con centinaia di abbonati reali, quindi Google teme di bloccarlo. Se il vostro obiettivo è raccogliere specificamente gli AI Overviews o monitorare le SERP più protette, iniziate con proxy mobili.
Proxy residenziali — cavallo da lavoro per l'organico e il volume. Per raccogliere risultati normali, posizioni, featured snippets e pacchetti locali, gli IP residenziali (indirizzi di provider domestici) offrono il miglior rapporto qualità-prezzo. Sono difficili da distinguere da un utente reale, e la rotazione consente di scalare la raccolta senza un assalto da un solo indirizzo. L'opzione ottimale, quando l'AI Overview non è al centro dell'attenzione, ma sono importanti volume e geografia, è proxy residenziali con rotazione.
Data center — solo per test preliminari. Veloci e economici, ma contro Google nel 2026 vivono solo poche richieste e non vedono i blocchi AI. Adatti per il debug della logica del parser, non per la raccolta operativa.
Non siete sicuri di cosa scegliere per un compito specifico, iniziate con l'analisi di proxy residenziali contro proxy mobili nel 2026: lì troverete dettagli su dove ogni tipo risparmia denaro e dove — dati.
Conclusione
Il parsing di Google nel 2026 ha smesso di essere un compito "scrivere un parser". SearchGuard ha costretto a renderizzare JavaScript, l'annullamento di num=100 ha decuplicato il numero di richieste, e gli AI Overviews hanno aggiunto un blocco visibile principalmente da IP mobili e che viene caricato con ritardo. Tecnologicamente, tutto è risolvibile: automazione del browser, parsing per struttura, pause ragionevoli e rotazione. Ma il fondamento su cui si basa la completezza e la stabilità della raccolta sono i proxy giusti: mobili per gli AI Overviews e richieste protette, residenziali per l'organico e il volume. Iniziate con il tipo di proxy adatto al vostro compito — e il parser smetterà di inciampare sui captcha.
```