Google.com/goto: l'aggiornamento anti-scraping di Google rende ogni risultato più difficile da estrarre

Google ha aggiunto una richiesta supplementare tra i risultati di ricerca e le pagine di destinazione, creando un conflitto diretto con gli strumenti che raccolgono URL dei risultati su larga scala. La modifica, nota come google.com/goto: l'aggiornamento anti-scraping di Google, sostituisce molti link organici diretti con indirizzi di reindirizzamento opachi di Google.

Il risultato di ricerca appare ancora familiare a una persona. Titolo, dominio visualizzato, favicon e descrizione restano visibili. Tuttavia, il link sottostante può ora puntare a google.com/goto?url=... anziché alla pagina dell'editore.

Questa distinzione è rilevante perché il valore codificato non espone l'URL completo di destinazione. Un browser può chiedere automaticamente a Google di risolverlo. Uno scraper deve effettuare un'altra richiesta, gestire la risposta ed evitare di attivare le difese di Google.

Google descrive il rollout come una misura tecnica contro gli abusi. La modifica non blocca del tutto la raccolta automatizzata. Trasforma invece un'attività economica di parsing HTML in una sequenza più rumorosa di richieste che Google può osservare.

Questo è il conflitto centrale. Gli utenti della ricerca continuano ad aver bisogno di link in uscita affidabili, mentre Google vuole un maggiore controllo sull'accesso automatizzato ai propri risultati. Le aziende di SERP API, le piattaforme SEO, i ricercatori e gli sviluppatori AI operano ora all'interno di questa tensione.

Google.com/goto: l'aggiornamento anti-scraping di Google modifica il livello dei link

Google non ha cambiato ciò che un risultato organico mostra, ma ha cambiato il modo in cui il software raggiunge la destinazione del risultato.

Un risultato Google tradizionale inseriva la pagina di destinazione direttamente nell'attributo href dell'elemento anchor. Il software poteva scaricare una pagina di risultati di ricerca, analizzarne l'HTML ed estrarre diversi URL completi.

La nuova struttura inserisce un reindirizzamento controllato da Google. L'anchor del risultato può puntare a un indirizzo /goto contenente un valore che spesso inizia con CAES. Tale valore rappresenta la destinazione senza pubblicarla come testo leggibile.

Quando una persona fa clic sul risultato, il browser richiede l'indirizzo /goto. Google restituisce quindi un reindirizzamento HTTP che invia il browser alla pagina effettiva. La transizione è solitamente troppo veloce perché chi effettua la ricerca la noti.

Google ha confermato il rollout il 26 agosto 2026. Un portavoce ha dichiarato che l'azienda implementa regolarmente misure tecniche contro abusi in evoluzione per proteggere i propri servizi e utenti. La conferma ha descritto il reindirizzamento come una di tali misure.

L'azienda non ha pubblicato una specifica tecnica per il token. Non ha inoltre spiegato tutti i segnali che determinano quali browser, regioni o sessioni ricevono i link riscritti.

Le prime osservazioni sono emerse prima della conferma. Gli specialisti della ricerca hanno segnalato il pattern a giugno e luglio, quando sembrava ancora un test limitato. Entro la fine di agosto, diversi fornitori di dati osservavano una diffusione molto più ampia.

La conferma del rollout ha riportato una copertura quasi completa presso diversi provider di IP residenziali. La stima proveniva da Derek Perkins della società di monitoraggio del ranking Nozzle, non da Google.

Autom, un provider di API per dati di ricerca, ha riportato una progressione simile. Il suo team ha incontrato per la prima volta /goto in una piccola quota di pagine dei risultati. In seguito ha osservato il formato in modo costante nelle sessioni disconnesse e di navigazione privata.

Il resoconto tecnico del provider afferma che il parametro opaco non può essere convertito nella destinazione tramite una normale decodifica locale. La destinazione arriva invece attraverso la risposta di reindirizzamento.

Questo formato differisce dal precedente wrapper /url di Google. Quel wrapper spesso includeva una destinazione leggibile e codificata come URL nella propria query string. Il software poteva estrarre quel valore senza contattare nuovamente Google.

Con /goto, il risultato di ricerca visibile e la destinazione utilizzabile diventano elementi di dati separati. Google continua a mostrare informazioni sufficienti perché una persona possa valutare il risultato. Tuttavia, il codice sorgente della pagina non garantisce più un URL in uscita riutilizzabile.

Questo è il cambiamento significativo. Google ha spostato la risoluzione della destinazione dall'HTML statico a un'interazione con il proprio server.

Perché un reindirizzamento aggiuntivo mette sotto pressione i provider di dati di ricerca

Il reindirizzamento crea un costo marginale per ogni risultato risolto, e tale costo si accumula nei sistemi di raccolta ad alto volume.

Uno scraper di base aveva in precedenza bisogno di una richiesta per raccogliere diverse destinazioni organiche da una pagina di risultati di ricerca. Con il nuovo formato, potrebbe aver bisogno della richiesta originale più una richiesta di risoluzione per ciascun token /goto univoco.

Si consideri un servizio che monitora molte query in base a località, dispositivi e lingue. Può raccogliere più pagine per ogni query e ripetere tale raccolta nel corso della giornata. Una richiesta aggiuntiva per risultato diventa rapidamente un lavoro infrastrutturale sostanziale.

Il costo non è limitato alla larghezza di banda. Ogni risoluzione aggiunge latenza, gestione delle connessioni, logica di retry e un'altra opportunità di errore. Crea inoltre un flusso riconoscibile di richieste indirizzate all'endpoint di reindirizzamento di Google.

Google può osservare la velocità con cui un client risolve i link. Può confrontare tali richieste con cookie, identità di rete, caratteristiche del browser e attività di ricerca precedenti. Google non ha divulgato quali segnali utilizzi in questo caso.

Ciò rende l'aggiornamento più di un nuovo formato di parsing. Crea un checkpoint lato server tra l'ottenimento della pagina dei risultati e la conoscenza di ogni destinazione esatta.

Il monitoraggio tradizionale delle posizioni illustra la pressione. Un tracker di posizionamento deve identificare quale pagina si posiziona per una query, non semplicemente quale dominio appare. I percorsi esatti contano quando un sito dispone di più pagine in competizione per lo stesso argomento.

Uno strumento che memorizza il reindirizzamento di Google anziché l'URL dell'editore può produrre record fuorvianti. Potrebbe segnalare risultati mancanti, unire pagine distinte o far sembrare che modifiche alla landing page siano cambiamenti di ranking.

Le API di ricerca affrontano un problema correlato. I loro clienti si aspettano URL di destinazione puliti e strutturati. Quei clienti non dovrebbero dover comprendere l'attuale wrapper dei link di Google né riscrivere le proprie integrazioni ogni volta che il formato cambia.

Autom afferma di aver modificato la propria pipeline per risolvere i link /goto preservando i campi di risposta esistenti. Questo approccio sposta l'onere della compatibilità dai clienti API al provider di dati.

Questa correzione dipende comunque dal fatto che il servizio di reindirizzamento di Google rimanga disponibile per il collector. Presuppone inoltre che l'attuale comportamento delle risposte rimanga stabile. Google non ha assunto impegni su nessuna delle due condizioni.

I prodotti AI per la ricerca e la ricerca documentale affrontano un'altra forma di pressione. Alcuni sistemi utilizzano API di ricerca commerciali, mentre altri raccolgono pagine di risultati tramite la propria infrastruttura. Entrambi gli approcci dipendono da un accesso prevedibile agli URL delle fonti.

Il reindirizzamento non impedisce a un modello di leggere una destinazione dopo che qualcuno gliel'ha fornita. Influisce sul processo di discovery a monte, che trova, classifica e recupera le fonti prima che inizi l'analisi.

I knowledge worker possono incontrare l'effetto indirettamente. Un assistente di ricerca può non trovare fonti quando il suo connettore di ricerca gestisce in modo errato gli URL di reindirizzamento. Può anche memorizzare wrapper di Google dove gli utenti si aspettano link stabili degli editori.

Questo rende più difficile ispezionare la provenienza. Un record di ricerca affidabile dovrebbe conservare la pagina che ha supportato un'affermazione, non un indirizzo di instradamento temporaneo di proprietà del motore di ricerca.

I team che realizzano sistemi interni di ricerca dovrebbero quindi mantenere l'identità della fonte separata dai metadati di discovery. Una base di conoscenza AI ricercabile resta utile solo quando le sue citazioni rimandano a documenti durevoli.

La pressione immediata ricade sugli intermediari dei dati di ricerca. Il rischio a valle raggiunge qualsiasi prodotto che consideri il loro output come un'infrastruttura affidabile per le fonti.

La vera contesa è tra risultati aperti e risoluzione controllata

Google pubblica ancora una pagina dei risultati leggibile, ma controlla sempre più le azioni necessarie per trasformare quella pagina in dati riutilizzabili.

Non si tratta semplicemente di Google contro una singola azienda di scraping. La contesa principale riguarda due modelli tecnici per accedere ai risultati di ricerca rivolti al pubblico.

Il primo modello tratta una pagina dei risultati come un documento. Un client la scarica, legge i link incorporati nell'HTML e decide cosa fare successivamente. Gran parte del web delle origini operava secondo questo semplice schema.

Il secondo modello tratta i risultati come un servizio interattivo. Ciò che l'utente vede rimane accessibile, ma i valori importanti diventano disponibili solo attraverso richieste aggiuntive governate dalla piattaforma.

Il rollout di /goto sposta Google Search verso il secondo modello. Lo fa senza rimuovere i risultati organici né costringere gli utenti comuni a un nuovo flusso di lavoro.

Questa sfumatura è importante. Definire l'aggiornamento un divieto di scraping ne sovrastima l'effetto. I link restano risolvibili e test indipendenti dimostrano che gli sviluppatori possono ancora recuperare le loro destinazioni.

ScrapingBee ha testato /goto su browser, sessioni automatizzate e configurazioni di rete. I suoi esperimenti sui reindirizzamenti hanno rilevato che il token poteva essere decodificato strutturalmente, ma non convertito localmente nell'URL originale.

L'azienda ha riferito che una richiesta HTTP GET con i reindirizzamenti automatici disabilitati restituiva una risposta 302 e un'intestazione Location. Tale intestazione conteneva l'indirizzo di destinazione.

I suoi test hanno inoltre rilevato che le richieste HEAD si comportavano diversamente. Restituivano risposte 200 senza la necessaria intestazione della posizione, costringendo i collector a usare GET per una risoluzione affidabile.

Questa constatazione è in conflitto con la raccomandazione iniziale di Autom di leggere la posizione tramite HEAD. La differenza potrebbe riflettere un comportamento in evoluzione, condizioni di test o più varianti del rollout.

Gli sviluppatori non dovrebbero trattare nessuno dei due metodi come un contratto permanente. Un'implementazione difensiva può testare il comportamento delle risposte, supportare più di un wrapper e registrare gli errori senza corrompere gli URL memorizzati.

ScrapingBee ha misurato 50 risoluzioni con una mediana di circa 3,27 secondi se elaborate in sequenza. Cinque worker hanno ridotto la mediana a circa 1,23 secondi nel suo ambiente.

Questi valori provengono dai test di un singolo fornitore, non da un benchmark universale. Posizione di rete, riutilizzo delle connessioni, risposte di Google e throttling possono produrre risultati diversi.

Tuttavia, l'esperimento chiarisce il compromesso. L'aggiornamento aggiunge attrito, ma una concorrenza moderata può assorbirne una parte. Ciò rende più probabile che la misura rimodelli i costi anziché eliminare lo scraping.

L'interazione con il server offre inoltre a Google opzioni che i link statici non fornivano. Può modificare le risposte, cambiare i formati dei token, applicare controlli di velocità o distinguere tra tipi di client.

Google controlla già la pagina dei risultati di ricerca stessa. Tuttavia, gli URL in uscita diretti limitavano il coinvolgimento dell'azienda dopo che un client aveva ricevuto l'HTML. /goto estende tale coinvolgimento alla risoluzione della destinazione.

La modifica segue altri sforzi che hanno complicato la raccolta su larga scala. Google ha rafforzato le difese contro il traffico automatizzato e modificato parametri delle pagine dei risultati che i collector utilizzavano in precedenza per set di risultati più ampi.

Ogni singolo adeguamento può essere aggirato con soluzioni tecniche. Insieme, rendono l'accesso non ufficiale meno prevedibile e aumentano il valore di un'infrastruttura di raccolta costantemente mantenuta.

Questo cambiamento rivela anche una simmetria scomoda. Google costruisce il proprio indice effettuando crawling su altri siti web, mentre limita i sistemi automatizzati che raccolgono la presentazione di quell'indice da parte di Google.

Le attività non sono identiche. Googlebot segue i controlli degli editori, costruisce un prodotto di ricerca e opera secondo sistemi di scansione documentati. Gli scraper SERP raccolgono le pagine di ranking generate da Google, spesso al di fuori di una relazione API supportata.

Ciononostante, editori e sviluppatori notano lo squilibrio. Google si aspetta che il web aperto resti tecnicamente accessibile, mentre rende il proprio livello di aggregazione progressivamente più difficile da riutilizzare.

Un thread della community molto discusso ha rispecchiato questa disputa. Al momento dell'istantanea fornita con questa storia, aveva raccolto 472 punti e 369 commenti.

Alcuni partecipanti hanno considerato l'aggiornamento una ragionevole protezione del servizio. Altri lo hanno descritto come un'ulteriore recinzione attorno a informazioni derivate da siti web pubblici. Diversi si sono concentrati sulla sfida ingegneristica pratica anziché sull'argomento politico.

L'interpretazione più solida si colloca tra queste posizioni. Google non ha chiuso i suoi risultati di ricerca, ma ha reso il riutilizzo ad alto volume più dipendente da interazioni controllate da Google.

L'aggiornamento introduce attrito, non un blocco completo dello scraping

La maggiore incertezza è se `/goto` rimanga un formato di reindirizzamento gestibile o diventi uno strato di un sistema di applicazione più rigoroso.

Il meccanismo attuale presenta limiti visibili. Uno scraper può richiedere ogni reindirizzamento e leggerne la destinazione. Alcune copie dell'URL sottostante possono inoltre restare altrove nella pagina renderizzata.

Google necessita delle informazioni sulla destinazione per mostrare domini, favicon, breadcrumb e attribuzione. A seconda del formato del risultato, i raccoglitori possono ricostruire parte dell'identità senza risolvere ogni link.

Questo non produce sempre l'esatta pagina di destinazione. Un dominio visualizzato non può distinguere una pagina prodotto da un articolo di assistenza sullo stesso sito. Anche il testo del breadcrumb può omettere parametri o componenti del percorso.

Nemmeno il rollout è uniforme. ScrapingBee ha segnalato /goto in Chrome, Edge, Playwright e nel proprio ambiente di raccolta. Brave e LibreWolf hanno restituito link diretti durante lo stesso ciclo di test.

Safari ha restituito un altro wrapper di Google anziché lo stesso formato /goto. Il cambio della posizione del proxy non ha rimosso il reindirizzamento in modo affidabile.

Questi risultati suggeriscono una variazione tra client, ma non rivelano le regole di selezione di Google. Il tipo di browser può correlare con l'esito senza esserne la causa diretta.

I token sono apparsi anche trasferibili nei test di ScrapingBee. I token raccolti tramite una connessione potevano essere risolti in seguito da un altro client senza i cookie o il proxy originali.

In quegli esperimenti sono rimasti utilizzabili per più di 24 ore. La loro durata massima resta sconosciuta e Google potrebbe modificare senza preavviso le regole di trasferibilità o scadenza.

Questa incertezza dovrebbe orientare le decisioni ingegneristiche. Un raccoglitore di produzione non dovrebbe memorizzare token opachi come se fossero identificatori permanenti. Dovrebbe risolvere e convalidare le destinazioni vicino al momento della raccolta.

Dovrebbe inoltre conservare il wrapper originale a fini diagnostici. Mantenere entrambi i valori aiuta i team a distinguere una variazione del ranking da un errore del resolver o da una nuova variante di risposta di Google.

I tentativi devono avere limiti accurati. Una risoluzione aggressiva può amplificare il modello di richieste che la modifica sembra progettata per esporre. Tentativi illimitati possono inoltre generare costi maggiori durante interruzioni parziali.

I sistemi di raccolta dovrebbero deduplicare i token identici prima di risolverli. ScrapingBee ha trovato token ripetuti in alcune pagine di risultati, rendendo evitabili richieste duplicate non necessarie.

I fornitori devono inoltre monitorare diversi confini. Dovrebbero tracciare la quota di risultati che usa ciascun wrapper, i tassi di successo della risoluzione, i codici di risposta e le distribuzioni della latenza.

Un improvviso aumento di URL Google nell'output dei clienti è un incidente di parsing, non la prova che gli editori siano scomparsi dalla ricerca. Separare queste condizioni evita falsi allarmi sul ranking.

I team di analytics hanno una domanda diversa. Vogliono sapere se il reindirizzamento modifica l'attribuzione del referral quando una persona raggiunge il sito di un editore.

Un reindirizzamento lato server può comunque condurre alla destinazione prevista preservando segnali di referral utilizzabili. L'attribuzione effettiva dipende dal comportamento del browser, dagli header, dalla configurazione analytics e dall'implementazione di Google.

Non esiste una base verificata per affermare che il rollout distrugga ampiamente l'attribuzione organica. Gli operatori dei siti dovrebbero esaminare le proprie richieste di arrivo e le classificazioni analytics prima di trarre tale conclusione.

Le linee guida sui reindirizzamenti generali di Google spiegano come il suo crawler interpreta i tipi di reindirizzamento comuni. Non documentano /goto come superficie di integrazione pubblica per raccoglitori di terze parti.

Questa differenza conta. La documentazione di Google Search Central indica agli editori come reindirizzare le proprie pagine. Non promette un comportamento stabile per i wrapper di ricerca in uscita di Google.

Gli utenti affrontano un compromesso minore ma reale. Passando il mouse su un risultato, possono vedere un indirizzo Google anziché la destinazione completa. Il dominio visualizzato fornisce ancora contesto, ma l'anteprima di stato del browser diventa meno informativa.

Questo può indebolire un controllo di sicurezza familiare. Un utente prudente potrebbe voler ispezionare l'esatta destinazione prima di aprirla, soprattutto quando più pagine condividono titoli simili.

Google può sostenere che le etichette di dominio visibili e le protezioni contro gli abusi restino efficaci. I critici possono ragionevolmente rispondere che un'etichetta controllata dalla piattaforma non equivale all'ispezione del link effettivo.

Nessuna delle due preoccupazioni dimostra che il rollout danneggi la maggior parte degli utenti. Mostra che le misure anti-automazione possono alterare la trasparenza anche quando l'esperienza di clic appare invariata.

Le prove attuali supportano una conclusione circoscritta. /goto aumenta i costi di raccolta, interrompe parser semplicistici ed estende il controllo di Google sulla risoluzione delle destinazioni.

Non supporta l'affermazione più forte secondo cui Google abbia reso impossibile lo scraping della ricerca. I fornitori hanno già dimostrato percorsi di risoluzione funzionanti, sebbene tali percorsi comportino nuovi rischi operativi.

Cosa costringe i team a monitorare l'aggiornamento anti-scraping di Google

Tre segnali determineranno se questa diventerà una normale modifica al parser o un cambiamento duraturo nell'economia dei dati di ricerca.

Il primo segnale è la copertura dei formati di link. I fornitori dovrebbero misurare con quale frequenza URL diretti, wrapper /url e token /goto compaiono tra browser, regioni e stati di sessione.

Una combinazione stabile rafforzerebbe l'idea che Google stia gestendo un sistema di controllo segmentato. Un rapido passaggio verso link /goto universali rafforzerebbe l'interpretazione anti-scraping.

Un ritorno ai link diretti indebolirebbe la conclusione più ampia. Suggerirebbe che problemi di compatibilità, preoccupazioni degli utenti o risultati sperimentali abbiano prevalso sul controllo aggiuntivo.

Il secondo segnale è il comportamento del resolver. I team dovrebbero tracciare se una semplice richiesta GET continua a restituire un header 302 Location utilizzabile senza una sessione browser.

Se questa via resta disponibile, i fornitori esperti possono trattare l'aggiornamento come un costo infrastrutturale aggiuntivo. Gli scraper di base si romperanno, ma i sistemi mantenuti potranno continuare a operare.

Nuovi requisiti di autenticazione, breve durata dei token, rigidi limiti di velocità o token vincolati al client aumenterebbero materialmente la barriera. Indicherebbero che Google sta rafforzando il checkpoint anziché limitarsi a riscrivere i link.

Anche i cambiamenti nel comportamento di HEAD e GET meritano attenzione. Le prime segnalazioni contrastanti mostrano perché i fornitori necessitano di test diretti anziché affidarsi a un'unica ricetta di implementazione.

Il terzo segnale è la qualità dei dati all'interno dei prodotti SEO e AI. I clienti dovrebbero monitorare pagine di destinazione mancanti, URL Google duplicati, volatilità inspiegabile del ranking o citazioni che si fermano ai wrapper di reindirizzamento.

Questi sintomi mostrerebbero che alcuni fornitori non si sono ancora adattati pienamente. Un output stabile suggerirebbe che i vendor abbiano assorbito il cambiamento senza trasferire molto onere ai clienti.

Gli acquirenti di dati di ricerca dovrebbero porre ai fornitori domande concrete. Il servizio restituisce la destinazione finale? Preserva i parametri canonici? Come etichetta i risultati non risolti?

Dovrebbero inoltre chiedere se le posizioni riportate siano cambiate a causa del formato del link. Uno strumento di ranking deve separare gli errori di raccolta dai movimenti effettivi nell'ordinamento di Google.

I team di prodotto AI necessitano di controlli simili sulle citazioni. Ogni affermazione recuperata dovrebbe collegarsi all'URL finale dell'editore, con i fallimenti di raccolta visibili agli operatori.

Anche la prossima dichiarazione pubblica di Google conta, sebbene l'azienda possa offrire pochi dettagli aggiuntivi. Una spiegazione formale delle categorie di protezione degli utenti o degli abusi restringerebbe il dibattito sulle intenzioni.

La dichiarazione attuale conferma che /goto è una misura protettiva. Non dice se il design sia stato motivato da crawler AI, strumenti SEO, misurazione dei clic o un'altra categoria di abuso.

I conflitti legali potrebbero fornire maggiore contesto. Google ha contestato alcune aziende che raccolgono e rivendono risultati di ricerca, dimostrando che i controlli tecnici esistono insieme alla pressione legale.

Tuttavia, /goto riguarda una gamma più ampia di client rispetto a qualsiasi singolo convenuto. Ricercatori, strumenti di accessibilità, estensioni del browser e sistemi interni di monitoraggio possono incontrare gli stessi wrapper.

I prossimi mesi riveleranno se Google distingue tra questi utilizzi. Restrizioni uniformi favorirebbero i fornitori di dati centralizzati in grado di mantenere grandi sistemi di risoluzione.

Un accesso selettivo potrebbe produrre un mercato diverso. Partner supportati e interfacce approvate acquisirebbero importanza, mentre la raccolta non ufficiale diventerebbe meno affidabile.

Per gli sviluppatori, la risposta immediata è semplice. Trattate i link dei risultati di ricerca come dati variabili, convalidate le destinazioni, conservate il contesto diagnostico e monitorate separatamente i fallimenti del resolver dalle variazioni del ranking.

Per gli acquirenti, il compito è la verifica. Chiedete se il vostro fornitore SEO, di monitoraggio o di ricerca si sia adattato prima di fidarvi di un cambiamento inatteso nei suoi report.

Per i knowledge worker, ispezionate le citazioni quando un sistema di ricerca automatizzato restituisce un wrapper Google. Una risposta utilizzabile dovrebbe condurre alla fonte sottostante, non fermarsi al livello di routing del motore di ricerca.

Google.com/goto: l'aggiornamento anti-scraping di Google non è dunque né un blocco totale né un reindirizzamento cosmetico. È un casello architetturale collocato in un punto prezioso della pipeline dei dati di ricerca.

Osservate se tale pedaggio resta una richiesta poco costosa. Se acquisirà controlli d'identità più rigorosi, token di durata più breve o limiti più stretti, la riparazione del parser di oggi diventerà una controversia più ampia sull'accesso.