Parametri URL di Google Search: cosa funziona ancora nel 2026

Verso settembre 2025, diversi strumenti SEO e script personalizzati hanno iniziato a rompersi senza troppo rumore. Il colpevole? Google ha smesso di rispettare in modo affidabile il parametro num=100, su cui gli utenti più esperti contavano da anni per ottenere 100 risultati per pagina. Nessun avviso formale di dismissione — solo un portavoce che ha detto a Search Engine Land che il parametro non era "formalmente supportato". Nello stesso periodo, Google ha introdotto più modalità udm insieme alle vecchie verticali tbm, ha annunciato che i domini con country code sarebbero stati progressivamente reindirizzati verso google.com e ha comunicato che gli AI Overviews avevano raggiunto oltre 2,5 miliardi di utenti mensili.

Se stai costruendo URL di ricerca, monitorando classifiche o automatizzando ricerche con i parametri URL di Google, è probabile che alcuni flussi di lavoro siano già degradati in silenzio. In Thunderbit abbiamo analizzato la documentazione attuale di Google, gli annunci di modifica più recenti, riferimenti ricavati con reverse engineering e verifiche sul campo per distinguere i controlli stabili da quelli contestuali. Il risultato è una guida aggiornata e da testare prima del rilascio ai parametri URL di Google Search che contano nel 2026, inclusi i mapping tbm/udm, la formula di codifica uule per il targeting geografico a livello città e i conflitti tra parametri che possono far risparmiare ore di debug.

Cosa sono i parametri URL di Google Search?

I parametri URL di Google Search sono le coppie chiave=valore che compaiono dopo il ? in un URL di ricerca Google. Controllano tutto: da cosa stai cercando, ai risultati del Paese che visualizzi, fino al fatto di vedere immagini, notizie o i classici link blu.

Un tipico URL di ricerca Google si scompone così:

https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m

• URL base: https://www.google.com/search
• ? apre la stringa di query
• q=best+crm+software è la query di ricerca (gli spazi sono codificati come +)
• & separa ogni parametro
• hl=en imposta la lingua dell’interfaccia su inglese
• gl=us dice a Google di mostrare i risultati come se fossi negli Stati Uniti
• tbs=qdr:m filtra i risultati dell’ultimo mese

Una distinzione importante: gli operatori di ricerca come site:, filetype: e intitle: vanno dentro il valore di q=. Fanno parte della query. I parametri URL come gl, hl e tbs sono chiavi separate nell’URL che controllano come Google elabora e mostra i risultati. Servono entrambi e lavorano insieme — ma sono due cose diverse.

Google non ha mai pubblicato una specifica unica e versionata per questi parametri. Alcuni arrivano dal modulo Advanced Search, altri dalla Custom Search API, altri ancora sono stati ricostruiti osservando gli URL di Google. Questo significa che l’articolo che stai leggendo si basa su test reali e sul comportamento documentato, non su un contratto API ufficiale.

Perché i parametri URL di Google Search contano nel 2026

I parametri URL non interessano solo gli sviluppatori. Chiunque lavori in SEO, marketing, vendite, operations o product e debba capire cosa mostra Google per una query specifica, in un mercato specifico, in un momento specifico — questi parametri sono il tuo kit di lavoro.

Ecco una rapida panoramica di chi ne beneficia e come:

Caso d'uso	Chi ne beneficia	Parametri chiave
Monitoraggio ranking SEO tra Paesi diversi	Team SEO e Marketing	gl, hl, uule, pws
Monitoraggio competitor per data	Team Strategy e Ops	tbs, q con site:
Monitoraggio annunci in mercati specifici	Team paid media	gl, hl, udm
Audit SEO locale (a livello città)	Attività locali	uule, gl
Ricerca contenuti / tracking trend	Team contenuti	tbs (filtri data), lr
Alimentare app AI/LLM con dati di ricerca	Team Product e Data	Più parametri + estrazione strutturata

Tre grandi cambiamenti rendono il 2026 molto diverso:

1. num=100 non è più affidabile. Il vecchio trucco per i risultati per pagina ha smesso di funzionare in modo costante a settembre 2025. Google non lo ha formalmente dismesso; un portavoce ha detto che non era mai stato formalmente supportato.
2. I redirect dei ccTLD sono una migrazione, non uno switch già completato. Google ha annunciato ad aprile 2025 che i domini country-code (google.co.uk, google.de, ecc.) sarebbero stati gradualmente reindirizzati verso google.com. Google non ha pubblicato un avviso di completamento, quindi non dare per scontato che tutti i locali si comportino ancora allo stesso modo.
3. Gli AI Overviews hanno cambiato la SERP. Google dichiara che gli AI Overviews hanno raggiunto oltre 2,5 miliardi di utenti mensili e più di 200 Paesi e territori. Le modalità udm ricavate con reverse engineering possono cambiare la superficie dei risultati in alcuni contesti, ma non sono un interruttore garantito per gli AI Overview.

Se i tuoi flussi di lavoro non sono stati aggiornati per questi cambiamenti, è probabile che tu stia ottenendo risultati degradati o fuorvianti senza accorgertene.

Cheat sheet dei parametri URL di Google Search (2026)

Prima di entrare nel dettaglio, la tabella di riferimento qui sotto è l’elenco più aggiornato che sono riuscito a mettere insieme. Salvala nei preferiti.

Parametro	Cosa fa	Valore di esempio	Stato
q	Query di ricerca (supporta operatori al suo interno)	q=best+crm+software	✅ Attivo
hl	Lingua dell’interfaccia	hl=en, hl=ja	✅ Attivo
gl	Contesto Paese/mercato	gl=us, gl=jp	✅ Attivo
lr	Limita i risultati a una lingua del contenuto	lr=lang_en	✅ Attivo
cr	Limita i risultati a un Paese di hosting	cr=countryUS	✅ Attivo
start	Offset di paginazione	start=10 (pagina 2)	✅ Attivo
num	Risultati per pagina (in passato)	num=100	⚠️ Non formalmente supportato; inaffidabile da sett. 2025
udm	Modalità di contenuto contestuale	udm=14 (web classico)	⚠️ Reverse engineered; varia in base al contesto
tbm	Verticale di ricerca	tbm=isch (immagini)	⚠️ Ancora osservato; testare insieme a udm
tbs	Filtri temporali, ordinamento, verbatim	tbs=qdr:w	✅ Attivo
safe	Controllo SafeSearch	safe=active	✅ Attivo
filter	Filtro dei risultati duplicati	filter=0	✅ Attivo (osservato)
nfpr	Disabilita l’autocorrezione	nfpr=1	✅ Attivo (osservato)
pws	Disattiva la personalizzazione	pws=0	✅ Attivo
uule	Targeting geografico a livello città/DMA	uule=w+CAIQICI...	✅ Attivo (reverse engineered)
as_q, as_epq, as_eq, ecc.	Campi del modulo Advanced Search	Vari	✅ Attivo
as_sitesearch	Limita a un dominio (Advanced Search)	as_sitesearch=example.com	✅ Attivo
as_filetype	Limita a un tipo di file (Advanced Search)	as_filetype=pdf	✅ Attivo
ie, oe	Codifica input/output	ie=UTF-8	✅ Attivo (raramente necessario)
kgmid, si, ibp	Entità Knowledge Graph / vista feature	Vari	⚠️ Contestuali (non per uso generale)
ei, ved, sxsrf, sclient	Sessione/tracking/telemetria	Vari	🔒 Interni (ignorare)
gbv	Vista HTML base (in passato)	gbv=1	❌ Inaffidabile nel 2026

Elimina ei, ved, sxsrf e sclient da qualsiasi URL tu salvi o condivida. Sono stati di sessione e telemetria che Google aggiunge automaticamente — irrilevanti per costruire URL di ricerca.

I parametri core di Google Search che funzionano ancora

Li ho testati tutti in modo diretto a metà 2026. Sono quelli che userai più spesso.

q — La tua query di ricerca

Il parametro q contiene i termini di ricerca. Gli spazi sono codificati come + o %20. Qui vivono gli operatori di ricerca documentati da Google — vanno dentro il valore di q, non come parametri URL separati.

Alcuni esempi:

• Frase esatta: q=%22google+search+url+parameters%22
• Limitato a un sito: q=site%3Aexample.com+pricing
• Tipo file: q=filetype%3Apdf+annual+report+2026
• Combinato: q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

Codifica sempre in URL l’intero valore della query. Virgolette, due punti e slash devono essere codificati correttamente per evitare di corrompere l’URL.

hl — Lingua dell’interfaccia

hl controlla la lingua dell’interfaccia di Google (pulsanti, etichette, intestazioni come "People also ask") e influenza quali risultati Google privilegia. Usa codici ISO 639-1 come en, fr, de, ja, oppure tag BCP 47 come en-gb o pt-br.

hl non obbliga tutti i documenti risultanti a essere in quella lingua. È un segnale forte, ma Google può comunque mostrare risultati in altre lingue se sono molto pertinenti. Per limitare la lingua dei contenuti, usa invece lr.

gl — Paese / geolocalizzazione

gl simula il Paese da cui stai effettuando la ricerca, usando codici ISO 3166-1 alpha-2 (us, gb, jp, de). Con i ccTLD che vengono gradualmente reindirizzati verso google.com, gl è ora il modo principale per ottenere risultati specifici per Paese.

La stessa query con valori gl diversi può restituire risultati, featured snippet e local pack completamente differenti. Ad esempio, q=best+bank&gl=us e q=best+bank&gl=jp ti mostreranno banche molto diverse.

Consiglio pratico: abbina sempre gl a hl per risultati localizzati accurati. Usare gl=jp con hl=en ti dà risultati del mercato giapponese in un’interfaccia inglese — utile per audit SEO internazionali.

lr e cr — Restrizione lingua e restrizione Paese

Questi due vengono confusi continuamente. La differenza conta:

• lr=lang_en limita i risultati alle pagine scritte in inglese (lingua del contenuto)
• cr=countryUS limita i risultati alle pagine ospitate negli Stati Uniti (posizione del server / associazione al Paese)
• gl=us simula una ricerca dagli Stati Uniti (influenza ranking, risultati locali, annunci)

Sia lr sia cr sono disponibili nel modulo Advanced Search di Google. Fai attenzione a combinarli: lr=lang_en + cr=countryJP significa "solo pagine in inglese ospitate in Giappone", un insieme molto ristretto. Ne parlo meglio nella sezione sui conflitti.

start — Paginazione

start=10 chiede i risultati a partire dalla posizione 11 (pagina 2), start=20 per la pagina 3 e così via. Poiché num=100 non è più affidabile, aumentare start di 10 è il default più sicuro — ma Google può comunque riscrivere o limitare la paginazione.

Il vecchio trucco num=100&start=0 per ottenere una pagina completa da 100 risultati non funziona più. Se i tuoi script includono ancora num, rimuovilo: viene ignorato senza errori.

pws — Disattiva la personalizzazione

pws=0 chiede a Google di disattivare la personalizzazione basata sull’account. È essenziale per il rank tracking SEO, dove vuoi risultati non influenzati dalla tua cronologia di ricerca, dai risultati cliccati o dalle preferenze del tuo account.

Un avviso: pws=0 riduce la personalizzazione ma non elimina tutti i fattori contestuali. Google afferma che i risultati possono ancora variare in base a tempo, posizione, lingua e dispositivo. Non esiste una SERP Google davvero "neutra".

safe e filter — SafeSearch e filtro dei duplicati

• safe=active attiva SafeSearch; safe=off lo disattiva. Tieni presente che impostazioni dell’account, policy amministrative, configurazioni di rete o leggi locali possono sovrascrivere questo parametro.
• filter=0 disattiva il filtro dei risultati duplicati di Google. Utile quando vuoi vedere tutti i risultati che Google ha, inclusi i quasi duplicati che normalmente verrebbero raggruppati.

nfpr — Disabilita l’autocorrezione

nfpr=1 impedisce a Google di riscrivere forzatamente la query quando pensa che tu abbia sbagliato a digitare qualcosa. È utile per tracciare termini di brand con ortografie insolite, gergo tecnico o query volutamente errate che i competitor stanno targettizzando.

Nota che nfpr=1 sopprime solo la riscrittura forzata. Per un controllo più ampio — disabilitare espansione dei sinonimi, cambiamenti di spelling e altre modifiche automatiche — usa tbs=li:1 (modalità verbatim), che approfondisco nella sezione su tbs qui sotto.

La migrazione da tbm a udm: cosa è cambiato e cosa usare ora

Questa è una delle modifiche ai parametri più importanti degli ultimi anni — e anche una delle più facili da sopravvalutare.

tbm è stato per oltre un decennio un modo comune per passare tra le verticali di Google — immagini, notizie, video, shopping. Google ha introdotto anche un sistema numerico udm con modalità sovrapposte e aggiuntive. Poiché Google non ha pubblicato un registro consumer stabile, consideralo un mapping contestuale, non una sostituzione pulita e completata.

Tabella completa di mapping da tbm a udm

I mapping qui sotto combinano il comportamento osservato dell’interfaccia e verifiche live del 12 agosto 2026. Diversi valori sono stati rimossi o riscritti nelle richieste anonime, quindi ogni riga va testata nell’account, nella regione e nel client in cui verrà usata:

Vecchio parametro	Vecchio valore	Nuovo parametro	Nuovo valore	Stato
tbm=lcl	Luoghi/Local	udm=1	Luoghi/Local	⚠️ Contestuale
tbm=isch	Immagini	udm=2	Immagini	⚠️ Contestuale
tbm=vid	Video	udm=7	Video	⚠️ Contestuale
tbm=nws	Notizie	udm=12	Notizie	⚠️ Contestuale
—	—	udm=14	Web classico (senza AI Overview)	🆕 Nuovo, nessun equivalente tbm
—	—	udm=18	Forum	🆕 Nuovo, nessun equivalente tbm
tbm=shop	Shopping	udm=28	Shopping	⚠️ Contestuale
tbm=bks	Libri	udm=36	Libri	⚠️ Contestuale
—	—	udm=39	Video brevi	🆕 Nuovo, nessun equivalente tbm
—	—	udm=50	Modalità AI Overview	🆕 Nuovo, nessun equivalente tbm

Google non ha pubblicato un registro stabile di udm — questo è un caveat fondamentale. Questi valori sono ricostruiti con reverse engineering osservando il comportamento dell’interfaccia di Google. L’accettazione degli URL varia in base ad account, regione, client, cookie e cohort sperimentale. Nei miei test, alcuni valori udm sono stati rimossi nelle richieste HTTP anonime ma funzionavano nelle sessioni browser interattive. Non dare per scontato che ogni valore funzioni ovunque.

Cosa fa udm=14 (e perché piace tanto agli SEO)

udm=14 è diventato una sorta di preferito di culto nella community SEO. Android Central lo ha descritto come un modo per richiedere una SERP web classica senza AI Overview. In molte sessioni produce una SERP tradizionale con link blu, ma non è una garanzia ufficiale o universale.

Perché è importante? Se fai rank tracking o audit SEO, gli AI Overview possono spingere i risultati organici sotto la piega della pagina e rendere più difficile valutare le posizioni. udm=14 può offrire una vista più pulita quando Google lo rispetta.

Detto questo, udm=14 non è garantito in ogni contesto. In verifiche live del 12 agosto 2026, Google a volte rimuoveva o riscriveva i valori udm a seconda del contesto della richiesta. I risultati effettivi variano in base a sessione, account, regione, client e cohort sperimentale.

udm=50 è stato osservato in contesti AI Mode/AI-result, ma non dovrebbe essere descritto come un modo garantito per forzare un AI Overview su una query arbitraria.

Cosa fare: aggiornare i workflow da tbm a udm

Il mio consiglio:

• Nuove implementazioni: tratta udm come input sperimentale/contestuale e prevedi fallback.
• Workflow esistenti: supporta e testa sia tbm sia udm, dove rilevante, invece di dare per conclusa la migrazione.
• Non combinarli mai entrambi: quando tbm e udm sono presenti insieme nello stesso URL, il comportamento è imprevedibile. Nei miei test, Google a volte li rimuoveva entrambi e restituiva una query semplice. Ne parlo meglio nella sezione sui conflitti.

La sintassi completa di tbs: intervalli di date personalizzati, ordinamento per data e verbatim

tbs è uno dei parametri più potenti del toolkit degli URL di ricerca Google, e molte guide ne sfiorano appena la superficie. Gestisce filtri temporali, ordinamento per data, modalità verbatim e altro ancora — tutto in un singolo valore separato da virgole.

Filtri temporali standard

| Valore di tbs | Significato | Frammento URL di esempio | |---|---|---|---| | qdr:h | Ultima ora | &tbs=qdr:h | | qdr:d | Ultime 24 ore | &tbs=qdr:d | | qdr:w | Ultima settimana | &tbs=qdr:w | | qdr:m | Ultimo mese | &tbs=qdr:m | | qdr:y | Ultimo anno | &tbs=qdr:y |

Queste sono le basi che coprono la maggior parte delle guide. Ma tbs può fare molto di più.

Intervalli di date personalizzati

Ti servono risultati da una finestra temporale specifica? Usa la sintassi cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY:

&tbs=cdr:1,cd_min:01/01/2026,cd_max:06/01/2026

Questo filtra i risultati a quelli che Google associa a date comprese tra il 1° gennaio e il 1° giugno 2026. È prezioso per la ricerca competitiva — per esempio: "cosa hanno pubblicato i competitor sul pricing nel Q1 2026?" Ricorda solo di codificare in URL l’intero valore, perché due punti e slash devono essere codificati.

Nota pratica: l’associazione delle date da parte di Google non è sempre accurata. La data mostrata nei risultati di ricerca è la migliore ipotesi di Google, non necessariamente la data reale di pubblicazione. Verifica sempre le date sulla pagina di destinazione.

Ordinare per data e modalità Verbatim

Qui la guida entra in un territorio che nessun articolo concorrente copre davvero.

sbd:1 ordina i risultati per data (dal più recente). Da solo è utile ma non sorprendente. Il trucco è che puoi combinarlo con i filtri di intervallo temporale in un unico valore tbs:

&tbs=qdr:m,sbd:1

Così ottieni risultati dell’ultimo mese, ordinati per data — dal più recente. È il modo più rapido per trovare ciò che è stato appena pubblicato su un argomento. Uso questa combinazione costantemente quando monitoro i contenuti dei competitor.

li:1 abilita la modalità verbatim — l’equivalente URL del cliccare lo strumento "Verbatim" nell’interfaccia di ricerca di Google. La modalità verbatim disattiva autocorrezione, espansione dei sinonimi, cambi di spelling e altre modifiche automatiche della query.

La differenza tra li:1 e nfpr=1 riguarda l’ambito:

• nfpr=1: sopprime solo la riscrittura forzata di spelling/query (ad esempio impedisce a Google di cambiare "teh" in "the")
• tbs=li:1: disattiva tutte le modifiche automatiche — spelling, sinonimi, termini correlati, aggiustamenti di personalizzazione

Puoi anche impilare più valori tbs. Ad esempio, tbs=qdr:m,sbd:1,li:1 ti dà risultati dell’ultimo mese, ordinati per data, con matching verbatim. Nei miei test questa combinazione funziona, anche se consiglio di verificarla con le tue query specifiche dato che la sintassi tbs non è documentata.

Come costruire un codice uule per il geo-targeting a livello città

Se gl è una lente a livello Paese, uule è un microscopio a livello città. Per la SEO locale — verificare come si posiziona la tua attività a Denver rispetto a Dallas, o cosa vede un utente nel quartiere Shibuya di Tokyo — gl da solo non basta.

Nessun articolo in prima posizione spiega davvero come costruire un codice uule — si limitano a dire che il parametro esiste e passano oltre. Ecco il quadro completo.

Quando usare gl, uule o cr

Parametro	Granularità	Caso d'uso tipico	Richiede codifica?
gl=us	Livello Paese	Simulazione rapida del Paese	No
cr=countryUS	Livello Paese (restrittivo)	Filtro per Paese di hosting	No
uule=w+CAIQICI...	Livello città/DMA	Controllo ranking SEO locale	Sì

L’algoritmo di codifica uule (passo dopo passo)

Il parametro uule usa un segnale di località codificato. La costruzione è ricostruita con reverse engineering, non documentata ufficialmente da Google, ma ampiamente validata dalla community SEO.

L’approccio più sicuro è codificare un piccolo payload Protocol Buffers invece di affidarsi alla scorciatoia spesso copiata online (che può fallire con caratteri non ASCII). Ecco il processo:

1. Recupera il nome canonico della località Google. Google pubblica i target geografici con nomi canonici tramite i dati di geotargeting della Google Ads API. Esempio: New York,New York,United States
2. Codifica il nome in byte UTF-8.
3. Costruisci un piccolo payload protobuf con il nome e la sua lunghezza in byte.
4. Codifica il payload in base64url e anteponi w+.

Ecco uno snippet Python che lo fa:

import base64

def encode_varint(value: int) -> bytes:
    out = bytearray()
    while True:
        byte = value & 0x7F
        value >>= 7
        if value:
            out.append(byte | 0x80)
        else:
            out.append(byte)
            return bytes(out)

def build_uule(canonical_name: str) -> str:
    name = canonical_name.encode("utf-8")
    payload = b"\x08\x02\x10\x20\x12" + encode_varint(len(name)) + name
    encoded = base64.urlsafe_b64encode(payload).decode().rstrip("=")
    return "w+" + encoded

#Esempio
print(build_uule("New York,New York,United States"))
#Output: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw

Quando lo inserisci in un URL, assicurati che il + letterale in w+ venga codificato correttamente come %2B dalla tua libreria URL. La maggior parte delle implementazioni di URLSearchParams o urllib.parse.urlencode lo gestisce automaticamente.

Un uule costruito correttamente è comunque solo un segnale di località. Non sovrascrive indirizzo IP, impostazioni dell’account, dispositivo o cohort sperimentale. Usalo per verifiche locali indicative, non come garanzia di ranking esatti a livello città.

Quando i parametri URL di Google Search entrano in conflitto senza avvisare

Le combinazioni di parametri possono fallire in silenzio: Google può ignorare un input, riscrivere l’URL o restituire una superficie diversa. I controlli sui conflitti qui sotto meritano di essere aggiunti a ogni workflow che genera link di ricerca.

Nessun articolo concorrente copre le interazioni tra parametri. Ma se stai costruendo URL di ricerca con più parametri — e probabilmente lo stai facendo — devi sapere quali combinazioni convivono bene e quali si ostacolano a vicenda.

gl + uule: quale prevale?

Quando sono presenti entrambi, uule fornisce un segnale di località più specifico di gl. Se imposti gl=uk e un uule che punta a Tokyo, otterrai risultati influenzati da Tokyo, non risultati del Regno Unito.

Consiglio: se usi uule, ometti del tutto gl oppure imposta gl sul Paese che contiene la città indicata nel uule. Non inviare segnali in conflitto.

tbm + udm: non usarli insieme

Nei miei test, quando tbm e udm sono presenti nello stesso URL, Google a volte li rimuove entrambi e restituisce una semplice query web. Il comportamento non è coerente tra sessioni e account.

Consiglio: usa solo udm per le nuove implementazioni. Se devi supportare workflow legacy, usa uno o l’altro — mai entrambi.

lr + cr: il doppio filtro può portare a zero risultati

È una trappola sottile. lr=lang_en limita ai contenuti in inglese. cr=countryJP limita alle pagine ospitate in Giappone. Combinali e stai chiedendo "pagine in inglese ospitate in Giappone" — un sottoinsieme molto piccolo del web.

Consiglio: usa uno dei due, a meno che non ti serva esplicitamente l’intersezione. Se li combini, aspettati molti meno risultati.

num + start: paginazione rotta

Gli script vecchi che usano num=100&start=0 oggi restituiscono senza rumore solo circa 10 risultati. Il parametro num non viene più rispettato, ma non genera errore — viene semplicemente ignorato.

Consiglio: rimuovi num da tutti gli URL. Paginare usando start a incrementi di 10 e deduplica i risultati tra le pagine.

Riferimento rapido ai conflitti

Combinazione	Cosa succede	Consiglio
gl + uule	uule fornisce un segnale più specifico	Allinea Paese e città, oppure ometti gl
tbm + udm	Imprevedibile — entrambi possono essere rimossi	Usa solo udm
lr + cr	Restrizione molto aggressiva, spesso quasi zero risultati	Usa uno dei due
num + start	num ignorato, restituiti solo circa 10 risultati	Rimuovi num, pagina con start
nfpr=1 + tbs=li:1	Controlli correlati ma non identici	Testa la tua query specifica
hl + lr	Lingua interfaccia ≠ filtro lingua contenuto	Usali in modo intenzionale; hl non è un filtro contenuti

Dai parametri URL di Google Search all’estrazione di dati strutturati

A questo punto hai un URL di ricerca Google preciso — query giusta, Paese giusto, intervallo di date giusto, risultati web classici. Il passo successivo è estrarre dati strutturati dai risultati.

Che tu stia costruendo un rank tracker, monitorando i competitor o alimentando un workflow di ricerca con dati di ricerca, vedere i risultati giusti è solo metà del lavoro. Ti servono titoli, URL, snippet, posizioni e date in un foglio di calcolo o in un database.

Costruire un URL di ricerca Google mirato (mettere tutto insieme)

Un esempio completo che combina più parametri:

https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0

Scomposizione:

• q=site%3Acompetitor.com+intitle%3Apricing — pagine su competitor.com con "pricing" nel titolo
• hl=en — interfaccia in inglese
• gl=us — contesto di mercato USA
• tbs=qdr:m,sbd:1 — ultimo mese, ordinato per data
• udm=14 — risultati web classici (senza AI Overview)
• pws=0 — personalizzazione disattivata

Puoi costruirlo programmaticamente con curl:

curl -L -G 'https://www.google.com/search' \
  --data-urlencode 'q=site:competitor.com intitle:pricing' \
  --data-urlencode 'hl=en' \
  --data-urlencode 'gl=us' \
  --data-urlencode 'tbs=qdr:m,sbd:1' \
  --data-urlencode 'udm=14' \
  --data-urlencode 'pws=0' \
  -H 'User-Agent: Mozilla/5.0'

Oppure con Python:

import requests

params = {
    "q": "site:competitor.com intitle:pricing",
    "hl": "en",
    "gl": "us",
    "tbs": "qdr:m,sbd:1",
    "udm": "14",
    "pws": "0",
}

response = requests.get(
    "https://www.google.com/search",
    params=params,
    headers={"User-Agent": "Mozilla/5.0"},
    timeout=20,
)
print(response.url)

Le richieste HTTP anonime a Google spesso restituiscono shell JavaScript senza risultati renderizzati lato server, oppure avvisi di traffico insolito — ed è proprio qui che l’estrazione via browser ha un vantaggio.

Estrarre dati SERP senza scrivere un parser

Analizzare l’HTML di Google è un lavoro fragile. La struttura DOM cambia spesso, i nomi delle classi sono offuscati e ciò che vedi nel browser non coincide sempre con ciò che ottieni in una risposta HTTP grezza.

Un approccio più semplice per chi non sviluppa codice: apri l’URL di ricerca costruito con cura in Chrome, poi usa uno strumento di estrazione basato sul browser per prelevare dati strutturati dalla pagina visibile. In Thunderbit abbiamo costruito la nostra estensione Chrome proprio per questo tipo di workflow — puoi usare AI Suggest Fields per identificare colonne come titolo del risultato, URL di destinazione, testo dello snippet e posizione visibile, quindi estrarle in un foglio di calcolo senza scrivere un parser.

Non è l’unica strada. Anche gli approcci basati su codice funzionano, soprattutto se devi gestire estrazioni su larga scala o ripetute. Ma per ricerche occasionali, audit e analisi competitive one-shot, l’estrazione via browser evita del tutto la fragilità del parsing HTML.

Quando usare invece un’API ufficiale

Qui serve una nota di uso responsabile — ed è importante.

I Termini di servizio di Google vietano l’accesso automatizzato che aggira le misure protettive, e Google Search Help classifica esplicitamente gli scraper e i software che inviano query automatiche per determinare il ranking come traffico automatizzato. Gestire uno scraper Google su scala di produzione ti espone a blocchi IP, CAPTCHA e possibili problemi legali.

Per esigenze di dati di ricerca ad alto volume e su scala produttiva, la strada migliore è un’API ufficiale. La Custom Search JSON API di Google non è più disponibile per i nuovi clienti — gli utenti esistenti hanno tempo fino al 1° gennaio 2027 per migrare, con 100 query gratuite al giorno e poi $5 ogni 1.000 query. Google raccomanda Vertex AI Search per la ricerca su siti controllati.

Per i siti che possiedi, la Search Console Search Analytics API è la fonte first-party per clic, impression, CTR e posizione media — senza bisogno di scraping.

Pensa alla conoscenza dei parametri URL come a uno strumento di diagnosi e ricerca: ottimo per creare link di ricerca precisi, fare audit manuali e capire cosa mostra Google. Non è un sostituto delle API ufficiali su larga scala.

Operatori di Google Search: i parametri dentro la query

Gli operatori di ricerca vivono dentro il parametro q=, ma sono compagni essenziali dei parametri URL. La tabella qui sotto copre quelli attualmente documentati da Google più alcuni che continuano a funzionare nella pratica:

Operatore	Cosa fa	Esempio
site:	Limita a un dominio	q=site:example.com+SEO
filetype:	Limita a un tipo di file	q=filetype:pdf+annual+report
intitle:	La parola deve apparire nel titolo	q=intitle:pricing+SaaS
inurl:	La parola deve apparire nell’URL	q=inurl:blog+marketing
-	Esclude un termine	q=apple+-fruit
""	Corrispondenza esatta della frase	q=%22google+search+url+parameters%22
OR	Uno dei due termini	q=scraping+OR+crawling
before:	Risultati prima di una data	q=AI+before:2026-01-01
after:	Risultati dopo una data	q=AI+after:2025-06-01
related:	Siti simili	q=related:hubspot.com

La vera potenza nasce combinando gli operatori dentro q con i parametri URL esterni:

q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14

Questo trova pagine su competitor.com con "pricing" nel titolo, pubblicate dopo gennaio 2026, ordinate per data, nel mercato USA, con risultati web classici. È una query di competitive intelligence molto precisa costruita interamente con parametri URL e operatori.

Google afferma che i risultati di site: non sono garantiti come completi — non trattare una query site: come inventario esaustivo delle pagine indicizzate.

Uso responsabile: Termini di servizio e limiti di Google

Contesto breve ma importante.

I Termini di servizio di Google vietano l’accesso abusivo e l’aggiramento delle misure protettive. Google Search Help cita esplicitamente gli scraper di ricerca e i software di ranking automatizzati come esempi di traffico automatizzato. Violare questi termini può portare a blocchi IP, CAPTCHA, restrizioni dell’account e potenzialmente azioni legali.

La conoscenza dei parametri URL è meglio usarla per: costruire manualmente URL di ricerca precisi, creare link di ricerca condivisibili per il team, eseguire audit su piccola scala nel browser e capire come funziona l’interfaccia di ricerca di Google. Per automazioni su scala produttiva, usa le API ufficiali di Google — o un provider terzo autorizzato di dati di ricerca come Brave Search API.

In Thunderbit, la nostra estensione browser è pensata per l’estrazione su pagine visibili e avviata dall’utente — non per query automatiche ad alto volume su Google. È una distinzione importante.

Takeaway chiave: il tuo toolkit 2026 per i parametri URL di Google Search

La versione sintetica:

• Usa gl + hl per i segnali di localizzazione e non affidarti solo ai ccTLD durante la migrazione dei redirect di Google
• Testa sia udm sia tbm dove serve — nessuno dei due è una API consumer stabile e versionata
• udm=14 può richiedere risultati web classici senza AI Overview, ma Google può rimuoverlo o riscriverlo
• Usa uule per il targeting geografico a livello città con la formula di codifica protobuf sopra
• Padroneggia tbs per filtri data precisi (cdr:1,cd_min:...,cd_max:...), ordinamento per data (sbd:1) e ricerca verbatim (li:1)
• Fai attenzione ai conflitti tra parametri: gl vs. uule, tbm vs. udm, lr vs. cr
• num=100 è inaffidabile e non è mai stato formalmente supportato — usa start a incrementi di 10 come default più sicuro
• Per dati SERP strutturati, usa strumenti browser-based come Thunderbit per lavoro ad hoc, oppure API ufficiali per la produzione
• Rispetta i Termini di servizio di Google — i parametri URL sono uno strumento di ricerca, non una licenza per fare scraping

Google continua a cambiare i parametri senza preavviso. Terrò aggiornato questo riferimento mentre le cose evolvono — salvalo nei preferiti e torna a controllarlo.

Scopri di più

• 9 migliori API SEO per il 2026 (con dati reali sul costo per richiesta)
• Come padroneggiare lo scraping dei motori di ricerca: guida completa
• I 27 migliori strumenti per analizzare e monitorare il ranking dei siti web
• Come usare la paginazione nel Web Scraper per un’estrazione efficiente
• Che cos’è l’automazione di ricerca? Vantaggi, strumenti e strategie

FAQ

Cosa fa udm=14 in un URL di ricerca Google?

udm=14 può richiedere una superficie di risultati web classici senza AI Overview, ed è per questo che è molto popolare tra i professionisti SEO. È ricavato tramite reverse engineering, non è un contratto Google documentato ufficialmente, e Google può rimuoverlo o riscriverlo a seconda di sessione, account, regione, client e cohort sperimentale.

Il parametro num funziona ancora nel 2026?

Non farci affidamento. Google ha smesso di rispettare in modo affidabile num=100 a settembre 2025, e un portavoce ha dichiarato che il parametro non è mai stato formalmente supportato. Usa start a incrementi di 10 come default di paginazione più sicuro e verifica il numero di risultati restituiti perché Google può ancora riscrivere o limitare la risposta.

Come simulo una ricerca Google da una città specifica?

Usa il parametro uule con un nome città codificato. La sezione di codifica qui sopra fornisce l’algoritmo basato su protobuf e un esempio in Python. Ti servirà il nome canonico della località Google (disponibile dai dati di geotargeting di Google Ads), che codifichi in un valore uule come uule=w+CAIQICIeNew+York,New+York,United+States.

Qual è la differenza tra gl, lr e cr?

Questi tre parametri controllano aspetti diversi del targeting geografico e linguistico. gl simula la località di ricerca a livello Paese (influenza ranking e risultati locali). lr limita i risultati alle pagine scritte in una specifica lingua del contenuto. cr limita i risultati alle pagine ospitate in un Paese specifico. Possono essere combinati, ma combinazioni contraddittorie (come lr=lang_en + cr=countryJP) restringeranno drasticamente i risultati.

Posso combinare più valori tbs in un solo URL?

Sì — separali con virgole all’interno di un unico parametro tbs. Per esempio, tbs=qdr:m,sbd:1 filtra all’ultimo mese e ordina per data (dal più recente). Puoi anche aggiungere li:1 per la modalità verbatim: tbs=qdr:m,sbd:1,li:1. La sintassi tbs non è documentata, quindi testa le combinazioni specifiche per confermare che funzionino come previsto.