Come funziona realmente il SERP Scraping nel 2026 (Dopo che Google ha eliminato num=100 e richiesto JavaScript)
Due cambiamenti silenziosi — JavaScript obbligatorio e la fine del parametro num=100 — hanno riscritto l'economia del search scraping. Ecco cosa è realmente cambiato, perché il tuo rank tracker si è rotto e come raccogliere dati SERP in modo affidabile nel 2026.
Se il tuo rank tracker improvvisamente si è fermato alla fine del 2025, o il tuo scraper Google fatto in casa ha iniziato a restituire pagine vuote, non te lo sei immaginato. Nel giro di nove mesi Google ha apportato due modifiche che, singolarmente, sembravano piccoli lavori di manutenzione e, insieme, hanno riscritto silenziosamente l'economia del search scraping. Questa è una guida pratica su cosa è realmente cambiato, perché ha rotto così tanti strumenti contemporaneamente e come raccogliere dati SERP in modo affidabile nel 2026 senza bruciare la tua infrastruttura — o i tuoi IP.
Cambiamento uno: Google ha reso JavaScript obbligatorio
Il 17 gennaio 2025, Google ha iniziato a richiedere JavaScript per utilizzare Google Search. Se lo disattivi, ricevi un breve messaggio — "Attiva JavaScript per continuare la ricerca" — invece dei risultati. Un portavoce dell'azienda ha detto a TechCrunch che l'obiettivo era "proteggere meglio i nostri servizi e utenti da bot e forme evolutive di abuso e spam," e ha confermato che meno dello 0,1% delle ricerche proviene da utenti con JavaScript disattivato.
Quella cifra dello 0,1% è rivelatrice. Con circa 8,5 miliardi di ricerche al giorno, un decimo di percento sono ancora milioni di richieste — e una quota sproporzionata di esse non erano mai umani. Erano rank tracker, crawler SEO e scraper economici che colpivano la versione leggera, senza JavaScript, della pagina dei risultati. Search Engine Journal ha confermato la lettura diretta: Google richiede JavaScript per bloccare bot e scraper, inclusi gli strumenti SEO.
Abilitare JavaScript ci consente di proteggere meglio i nostri servizi e utenti da bot e forme evolutive di abuso e spam, e di fornire le informazioni più rilevanti e aggiornate.
La conseguenza pratica: l'era del parsing di Google recuperando un URL ed eseguendo una regex su HTML statico è finita. I risultati ora sono assemblati lato client. Se il tuo scraper non può eseguire JavaScript, non vede una pagina degradata — non vede alcuna pagina.
Cambiamento due: la morte del num=100
Il secondo cambiamento era più piccolo nell'aspetto e più grande nell'impatto. Intorno all'11 settembre 2025, Google ha disabilitato il parametro URL &num=100 — la piccola bandiera che diceva a Search di restituire 100 risultati su una singola pagina invece dei 10 predefiniti. Per un decennio è stato la spina dorsale del deep rank tracking: una richiesta, cento posizioni.
Quando è scomparso, la matematica si è invertita durante la notte. Per vedere i primi 100 risultati ora hai bisogno di fino a dieci richieste paginati invece di una. Keyword Insights ha messo il costo in modo schietto il giorno in cui è successo.
Google ha eliminato il parametro SERP n=100. Invece di 1 richiesta per 100 risultati SERP, ora ci vogliono 10 richieste (10 volte il costo). Questo impatta il nostro modulo di classifiche. Stiamo esaminando le opzioni e aggiorneremo presto la piattaforma.
L'onda d'urto ha colpito anche Google Search Console. A partire dal 10 settembre, i team SEO hanno visto le impressioni desktop calare bruscamente mentre la posizione media sembrava migliorare. La teoria dell'analista Brodie Clark — ampiamente discussa ma mai confermata da Google — è che una grande quota di quelle impressioni precedenti non erano mai umane: erano bot che caricavano pagine con 100 risultati tramite num=100, ciascuna registrando dieci volte le impressioni di una pagina normale. Rimuovi il parametro, e le impressioni fantasma scompaiono con esso. È un'interpretazione della comunità, non una spiegazione ufficiale, ma si adatta perfettamente alla tempistica.
Perché questo ha rotto così tanti strumenti contemporaneamente
La maggior parte degli strumenti SERP era costruita su due assunzioni che erano entrambe vere per anni e ora sono entrambe false: che Google avrebbe servito HTML utilizzabile senza JavaScript, e che si potevano recuperare 100 risultati per richiesta. Rimuovi entrambi nello stesso anno e le modalità di fallimento si accumulano:
- I fetcher statici restituiscono pagine vuote o di sfida invece dei risultati.
- I raccoglitori basati su paginazione necessitano di 10 volte il volume di richieste per la stessa copertura, il che significa 10 volte la larghezza di banda del proxy e 10 volte la superficie di blocco.
- Più richieste dagli stessi intervalli IP attivano i sistemi anti-bot più velocemente, quindi i tassi di successo diminuiscono esattamente quando il volume deve aumentare.
- I baselines di Search Console sono cambiati, quindi i dashboard storici non confrontano più come-per-come.
Come ha inquadrato l'ingegnere SEO Ryan Jones, l'ondata di scraping aggressivo — gran parte del quale ora alimenta prodotti AI — è esattamente ciò che ha spinto Google a reagire, rompendo i rank checker e gli scraper SERP come danno collaterale. Gli strumenti non sono falliti perché erano scritti male. Sono falliti perché il terreno è cambiato.
Come appare un SERP scraping affidabile nel 2026
Il nuovo baseline ha tre elementi non negoziabili. Mancane uno e il tuo tasso di successo crolla sotto carico.
1. Esegui JavaScript — ma solo quando necessario
Poiché i risultati sono assemblati lato client, hai bisogno di un client che esegua JavaScript per le pagine che lo richiedono. Ma avviare un browser headless per ogni richiesta è lento e costoso. Il pattern efficiente è provare prima un recupero leggero con un vero fingerprint TLS e passare a un rendering completo del browser solo quando la pagina effettivamente ti sfida. La maggior parte delle richieste non ha mai bisogno del browser; quelle che lo fanno lo ottengono automaticamente.
2. Ruota le uscite residenziali con veri fingerprint del browser
Gli IP dei datacenter e i fingerprint predefiniti dei client HTTP sono la via più veloce per un CAPTCHA. Le richieste devono arrivare da IP residenziali, portando il fingerprint TLS e dell'header di un vero browser come Chrome. Quando un'uscita viene segnalata, la rotazione a una nuova solitamente elimina il blocco senza alcun cambiamento alla richiesta stessa — che è esattamente come un raccoglitore resiliente si riprende da una pagina di "traffico insolito" invece di morire su di essa.
3. Analizza in dati strutturati, non HTML grezzo
Il markup di Google cambia costantemente, e dopo num=100 il layout è più frammentato, non meno. Mantenere i propri selettori contro un bersaglio mobile è un lavoro a tempo pieno. Un endpoint SERP strutturato che restituisce JSON pulito — risultati organici, annunci, shopping, pannelli di conoscenza, People Also Ask, AI Overviews — isola la tua pipeline da ogni cambiamento cosmetico sul lato di Google.
Il pattern in pratica
Invece di mantenere browser, pool di proxy e parser da soli, si passa una query a un endpoint che fa tutti e tre e restituisce risultati strutturati puliti. Con il QuantumProxies SERP API una singola richiesta autenticata gestisce l'esecuzione di JavaScript, la rotazione residenziale e l'analisi per te:
curl --location --request GET \
"https://app.quantumproxies.io/api/v1/serp/google/search?q=best+running+shoes&cc=us" \
--header "Authorization: Bearer YOUR_API_KEY"La risposta è JSON, non HTML — risultati organici con posizioni, annunci, unità di shopping, il knowledge graph, People Also Ask e AI Overviews dove presenti. Nessun browser headless da sorvegliare, nessun selettore da riparare quando Google rimescola la pagina, e la paginazione gestita così non stai ricostruendo manualmente ciò che num=100 ti dava gratuitamente. Quando un'uscita attiva una pagina anti-bot, il servizio riprova automaticamente su un nuovo IP residenziale — lo stesso comportamento di rotazione per recuperare che mantiene viva una pipeline sotto carico reale.
Se preferisci vedere la forma completa della richiesta e della risposta prima di scrivere qualsiasi codice, i documenti interattivi del SERP API su https://quantumproxies.io/serp-api/docs ti permettono di eseguire una query live e copiare snippet pronti per cURL, Python, JavaScript, PHP, Go e Ruby.
La conclusione
Il SERP scraping non è diventato più difficile in modo vago e incrementale — ha cambiato forma due volte in un anno. JavaScript è ora obbligatorio, quindi hai bisogno di un vero client. num=100 è sparito, quindi la copertura profonda costa un ordine di grandezza in più in richieste, il che significa che la qualità del tuo strato proxy e l'intelligenza della tua logica di escalation ora contano più del volume grezzo delle richieste. I team che raccolgono ancora dati SERP puliti su larga scala nel 2026 non sono quelli che inviano più richieste. Sono quelli che inviano richieste più intelligenti — capaci di JavaScript, con fingerprint residenziali e strutturati dal primo byte.