Risolvi il redirect /goto di Google nella tua pipeline SERP

Il riepilogo in 30 secondi

Il 26 agosto 2026 Google ha confermato che i link nei risultati di ricerca ora passano da google.com/goto?url=[token cifrato] prima di raggiungere la destinazione. Barry Schwartz lo ha riportato su Search Engine Roundtable e Search Engine Land, e un portavoce di Google l'ha definito parte di "misure tecniche di lungo periodo contro forme di abuso in evoluzione".

Se il tuo team estrae URL di destinazione dai risultati di ricerca di Google (monitoraggio posizioni, scraping SERP, raccolta dati per l'AI), un presupposto è appena saltato: l'URL reale non è più visibile nel link. È cifrato in un token che il browser segue come un normale redirect.

La buona notizia: si può riparare, e la riparazione è più piccola di quanto molti immaginino. Il token non si decifra, ma si risolve con una singola richiesta HTTP in più e, essendo deterministico, si può mettere in cache. Questo articolo ti guida in una riparazione da 30 minuti: individuare il cambiamento, risolverlo in sicurezza e garantire che i tuoi report mostrino ancora le pagine giuste. Se non fai scraping di SERP e non confronti le posizioni con URL estratti da quelle pagine, salta a "Ciò che il cambiamento non tocca". Sul tuo sito non cambia nulla.

Cosa è cambiato esattamente

Per anni il link di un risultato Google ha portato la destinazione reale dentro il link stesso:

<a href="https://yoursite.com/landing-page?utm_...">...

Ora lo stesso risultato può portare un link di transito:

<a href="https://www.google.com/goto?url=TtFp1Lc2026...*">...

Seguendolo, Google restituisce un redirect HTTP verso la destinazione. Due punti importanti sul funzionamento:

• Il token è cifrato e a prova di manomissione. Secondo un reverse engineering indipendente (pubblicato ad agosto 2026), è composto da un marcatore da 1 byte, un identificatore di chiave da 4 byte e dati in formato Tink. Cambi un carattere e Google risponde con HTTP 400. Senza le chiavi di Google non puoi né forgiare un token né decodificare un URL.
• Il token è deterministico. Lo stesso URL di destinazione genera sempre lo stesso token. Questo da solo rende economica tutta la riparazione: risolvi una volta, poi usi la cache del token.

Derek Perkins di Nozzle ha osservato un rollout vicino al "100%" presso diversi fornitori di IP residenziali, ed è per questo che questa volta è più di un esperimento.

Ciò che sopravvive al cambiamento

Che il parametro ved sopravviva merita attenzione: i dati di posizione e tipo di click che i tool di monitoraggio leggevano dai link di risultato sono ancora lì. È nascosto solo l'URL di destinazione.

Ciò che il cambiamento non tocca

• Posizioni e traffico. Il sistema di ranking di Google non c'entra con i link che renderizza.
• I dati di Google Search Console. Posizioni, impressioni e click nella GSC arrivano dai dati interni di Google e non sono coinvolti.
• I crawler che visitano il tuo sito. Googlebot, GPTBot e qualsiasi bot che crawla le tue pagine non tocca google.com/goto. Compare solo nei link che Google ti mostra.
• Bing e gli altri motori di ricerca. È un cambiamento solo di Google.

A essere coinvolti sono solo chi gestisce pipeline che leggono i link delle tabelle dei risultati di Google. Se sei tra questi, lo sentirai; altrimenti è solo rumore.

Verifica se sei coinvolto

Esegui i quattro controlli. I primi due richiedono cinque minuti; gli ultimi due sono una conversazione con il tuo fornitore.

Se è tutto pulito, non ti riguarda: metti la pagina tra i segnalibri e vai avanti.

Se trovi un'occorrenza, i quattro passaggi successivi restituiscono precisione alla pipeline. Ogni passaggio dice cosa fare, come appare un buon output e come recuperare quando non funziona.

Passaggio 1: Rileva i token dove compaiono

Cosa fare. Nel tuo script di estrazione SERP, raccogli tutti i link dei risultati e segnala tutto ciò che inizia con https://www.google.com/goto?url= (matcha anche il /goto?url= nudo che compare su alcune superfici e l'url= seguito da un payload in stile base64). Registra il tasso di segnalazione per query: è il tuo indicatore di rollout. E, dall'osservazione di Derek Perkins: il rollout non è uniforme tra i range di IP, quindi tieni traccia per fornitore, non in aggregato.

Risultato atteso. Un goto_rate per query. Lo 0% significa che la tua fonte restituisce ancora link diretti; il 100% significa tokenizzazione completa.

Controllo qualità. Lancia la stessa query due volte da due IP diversi. Se uno è tokenizzato e l'altro no, c'è una partizione di range di IP e vanno trattati entrambi.

Recupero. Se il campione dà zero occorrenze ma sospetti una tokenizzazione, verifica se la tua estrazione legge un DOM renderizzato via JavaScript invece dell'HTML grezzo. I token possono comparire nel markup renderizzato anche quando la risposta grezza resta nel vecchio formato.

Passaggio 2: Risolvi un token con un singolo redirect

Cosa fare. Quando il risultato porta un token, segui il link lato server con il seguito dei redirect disabilitato e leggi l'header Location:

curl -sI "https://www.google.com/goto?url=TtFp1Lc..." | grep -i location

La risposta è un HTTP 3xx verso la destinazione reale. Conservala. Due regole rendono questo passaggio economico e sicuro:

• Cache per token, non per URL. Poiché la tokenizzazione è deterministica, basta una risoluzione per token. Salva token -> resolved_url e riutilizzalo all'infinito.
• Non fare mai crawling di `google.com/goto` come pagina. Google ha aggiunto Disallow: /goto? al proprio robots.txt a fine luglio 2026. Quell'indirizzo non è pensato per essere scaricato da un crawler; un fetcher corretto segue leggermente il link del token e legge solo la catena di redirect; un fetcher maldestro indicizza o archivia l'URL goto stesso e sporca i tuoi dati. A fine luglio c'erano già quasi 3.750 URL di questo tipo indicizzati su google.com.

Controllo dei costi prima di partire: una prima spazzata di SERP con centinaia di risultati significa centinaia di richieste extra verso google.com, esattamente il tipo di carico che il rilevamento bot di Google osserva. La cache deterministica riduce il tutto a una richiesta per token unico, quindi non risparmiare su questo passaggio.

Risultato atteso. Una tabella di mappatura stabile tra token e destinazioni. Verifica dieci token casuali nel browser: ognuno deve atterrare su una pagina sensata.

Controllo qualità. Conferma che la lunghezza del token sia stabile tra URL diversi e che URL di destinazione identici producano sempre lo stesso token. Se la corrispondenza si rompe, c'è stata una rotazione di chiavi (vedi Passaggio 5).

Recupero. Un token che restituisce 400 è contraffatto, troncato o proviene da una sessione scaduta; ri-fai lo scrape della SERP e riprova. Due fallimenti consecutivi di solito significano HTML archiviato obsoleto, non un token rotto.

Passaggio 3: Salva la destinazione, non l'involucro

Cosa fare. Il resto della pipeline (associazione keyword-pagina, controlli di indicizzazione, audit degli schemi) deve vedere l'URL di destinazione. Quindi, dopo il Passaggio 2, conserva tre campi per risultato: resolved_url, token e accessed_at. Togli i link goto dalla colonna URL di ogni report; un URL google.com in un report di keyword è un errore di qualità dei dati in una dozzina di forme.

Se non riesci ad aggiungere il resolver questa settimana, il passo intermedio sicuro è omettere del tutto la destinazione invece di salvare il token: i dati di posizione e ranking restano significativi, solo la colonna URL resta vuota. Un tool che dichiara chiaramente "nessun URL" è molto più facile da interpretare di uno che riporta una stringa di token come fosse un indirizzo reale.

Risultato atteso. Un report in cui il 100% delle righe sono URL http(s) dei tuoi domini e zero righe google.com.

Controllo qualità. Confronta i dati a livello di URL con Search Console per dieci keyword. Le righe devono coincidere. Se Search Console dà una posizione a un URL che il tuo report dichiara "non trovato", c'è un buco nel resolver o nel parser.

Recupero. Se una piccola parte degli URL continua a non risolversi, registra i loro token a parte. La maggior parte dei fallimenti riconduce ai due responsabili del Passaggio 2: HTML obsoleto o un muro di rilevamento bot alla richiesta successiva.

Passaggio 4: Verifica cosa fa il tuo fornitore

Cosa fare. Se dipendi da un tool di monitoraggio posizioni o da una SERP API (incluse quelle costruite su dati Google scraping), il rollout è in corso da settimane. Fai queste cinque domande e verificaci ogni cambio di report:

Risultato atteso. O una correzione confermata o un motivo chiaro per andartene. Entro 30 giorni dovresti poter unire gli URL dei tuoi report con il log delle modifiche del sito senza rumore.

Via di ritorno. Nessun miglioramento dal fornitore entro una settimana: sostituisci questo punto dati con la Google Search Console API per le posizioni, che viene direttamente dai dati di Google e non vede mai un token. Il prezzo è un po' meno dettaglio a livello di link; accettabile se le tue decisioni richiedono precisione e non funzionalità di terze parti.

Passaggio 5: Tieni d'occhio il prossimo passaggio

Il meccanismo non si ferma qui. Monitora tre cose ogni mese:

1. Rotazione di chiavi. Il campione di reverse engineering ha trovato quattro identificatori di chiave in circolazione, con uno dominante ("ee47aa4d", circa il 62% dei token). Se compare una quinta chiave e la quota dominante si sposta, aspettati un'invalidazione della cache: risolvi di nuovo i token alla rotazione.
2. Estensione ad altre superfici. /goto è stato visto anche nei link sponsorizzati e in altri tipi di risultato. Se i tuoi tool toccano annunci o immagini, amplia la ricerca del Passaggio 1.
3. Indurimento continuo. Fa parte di una serie più lunga: rendering JavaScript forzato (inizio 2025), lancio di SearchGuard, chiusura del &num=100 (settembre 2025) e azione DMCA sotto la Sezione 1201 contro SerpApi (dicembre 2025). Ogni evento è documentato a parte; l'articolo di reverse engineering ne raccoglie la maggior parte. Aspettati che ottenere l'URL finale diventi più difficile, non più facile.

Verifica del risultato finale

• [ ] Il rilevatore del Passaggio 1 gira in CI o su pianificazione e registra goto_rate per query
• [ ] Tutti i token campione si risolvono in destinazioni reali, verificate nel browser
• [ ] Zero URL google.com/goto nei tuoi report (grep sull'ultimo export)
• [ ] Dieci keyword coincidono riga per riga con Search Console
• [ ] Il fornitore ha confermato la strategia di risoluzione, o i dati di ranking passano dalla GSC API
• [ ] C'è un controllo dedicato di rotazione chiavi nel tuo ritmo mensile

Domande frequenti

Questo cambia le mie posizioni o il mio traffico? No. Ciò che cambia è il percorso del click; il sistema di ranking, i risultati e ciò che vede l'utente non cambiano. Le tue performance organiche sono a rischio solo se un tool che gestisci inizia a riportare dati sbagliati.

Si può decodificare un token goto? Non dall'esterno. È un payload cifrato in formato Tink e cambiare un carattere restituisce HTTP 400, quindi nemmeno la contraffazione è possibile. La via percorribile è seguire il redirect e leggere l'header Location, esattamente ciò che fa il browser.

Uno scraper può seguire i link `/goto`? In pratica è ciò che fa un click del browser, ma Google ha bloccato /goto? nel proprio robots.txt e i termini limitano l'accesso automatizzato ai risultati di ricerca. Se fai scraping di SERP sei già dalla parte sbagliata di quei termini; questo rollout non lo cambia, lo rende solo più pesante. Scegli la tua posizione di conformità prima di costruire il resolver.

Devo cambiare qualcosa sul mio sito? No. Il cambiamento è interamente nei link che Google renderizza. Da verificare sono i tool che leggono il SERP a tuo nome: è il Passaggio 4.

Autrice: Olivia Stone, ricercatrice di intelligence SERP presso Auspia (analizza oltre 25.000 query). Scrive di analisi SERP, pattern di ranking e di come i cambiamenti nei risultati di ricerca influenzano i dati di posizione.