Google Updates · ★★★★★ ·
Google introduce una nuova policy antispam per il "back button hijacking"
Fonte: Google Search Central Blog
Google ha annunciato una nuova policy antispam che contrasta il "back button hijacking", una pratica ingannevole che manipola il comportamento del pulsante "indietro" del browser. Questa violazione rientra ora nelle "pratiche dannose" delle policy antispam e potrà comportare penalizzazioni.
> ANALISI APPROFONDITA
Google ha formalizzato il divieto di back button hijacking nelle spam policy, inserendolo esplicitamente tra le pratiche dannose (malicious practices). La tecnica consiste nel manipolare la cronologia del browser per impedire all'utente di tornare alla pagina precedente tramite il pulsante indietro, forzandolo a rimanere sul sito o reindirizzandolo verso destinazioni non volute. Fino ad oggi questa pratica era implicitamente vietata, ma l'assenza di una menzione esplicita lasciava margini interpretativi.
La nuova policy colma questa lacuna e introduce la possibilità di spam action manuali o algoritmiche contro i siti che implementano questa tecnica. Il back button hijacking viene tipicamente realizzato tramite JavaScript che inserisce entry fittizie nella history API del browser, oppure attraverso redirect immediati che sovrascrivono la pagina di provenienza nella cronologia. L'obiettivo è sempre lo stesso: intrappolare l'utente e massimizzare pageview, tempo di permanenza artificiale o conversioni forzate.
Google non ha fornito dettagli su come l'algoritmo identificherà questa pratica, ma è ragionevole ipotizzare che i segnali comportamentali degli utenti (bounce rate anomali, interazioni con il pulsante indietro, pattern di navigazione innaturali) giochino un ruolo chiave. La formalizzazione della policy suggerisce che il volume di segnalazioni manuali e di casi rilevati sia cresciuto abbastanza da giustificare un intervento normativo esplicito.
La tempistica dell'annuncio coincide con una fase in cui Google sta intensificando la lotta contro le pratiche che degradano l'esperienza utente, dopo gli update sui contenuti di bassa qualità e le strette sugli annunci interstiziali. Il back button hijacking è particolarmente diffuso in verticali ad alta competizione pubblicitaria (finanza, salute, gambling) e su siti che monetizzano tramite arbitraggio pubblicitario, dove ogni pageview in più si traduce direttamente in revenue.
La policy si applica a tutte le implementazioni che alterano il comportamento atteso del pulsante indietro, indipendentemente dall'intento dichiarato. Non esistono eccezioni per "miglioramenti UX" o "funzionalità avanzate": se l'utente preme indietro e non torna dove si aspettava, è violazione. Questo include anche implementazioni apparentemente innocue come le Single Page Application mal configurate che non gestiscono correttamente la history API.
Google non ha specificato se la penalizzazione sarà a livello di singola pagina, sezione o intero dominio, ma la categorizzazione come "malicious practice" suggerisce che l'impatto potrebbe essere site-wide nei casi più gravi. La distinzione tra errore tecnico e manipolazione intenzionale sarà probabilmente valutata caso per caso nelle azioni manuali, mentre l'algoritmo potrebbe applicare filtri più indiscriminati.
> COSA CAMBIA PER TE
- ▸ Siti che utilizzano SPA framework (React, Vue, Angular) devono verificare che la gestione della history API non crei comportamenti anomali del pulsante indietro, anche se non intenzionali. Un bug tecnico può essere interpretato come violazione.
- ▸ Verticali ad alto rischio (finanza, salute, lead generation) che hanno implementato script di terze parti per tracking o A/B testing devono auditare il codice JavaScript per identificare manipolazioni della cronologia browser, anche se inserite da vendor esterni.
- ▸ La policy elimina definitivamente qualsiasi giustificazione per tecniche di "session retention" basate sulla manipolazione della history, anche quando presentate come ottimizzazioni UX. Il rischio di spam action supera qualsiasi beneficio di engagement.
- ▸ Chi gestisce network di siti o programmi di affiliazione deve estendere il controllo qualità anche a questo aspetto, perché un singolo dominio penalizzato per back button hijacking può compromettere la reputazione dell'intero network agli occhi di Google.
- ▸ La formalizzazione della policy rende più semplice per i concorrenti segnalare violazioni tramite spam report, aumentando il rischio di azioni manuali anche su implementazioni borderline.
> ESEMPI CONCRETI
COSA FARE
Un sito di comparazione prezzi inserisce tramite JavaScript una entry fittizia nella history ogni volta che l'utente clicca su un risultato. Quando l'utente preme indietro, invece di tornare alla SERP di Google viene riportato alla pagina di comparazione. Questo è back button hijacking esplicito e comporta spam action site-wide.
COSA EVITARE
Una SPA di e-commerce gestisce male il routing client-side: quando l'utente naviga tra categorie prodotto, il pulsante indietro non funziona come atteso perché la history API non è sincronizzata con i cambi di stato. Anche se non intenzionale, questa implementazione può essere interpretata come violazione e richiede fix immediato.
SCENARIO
Un blog monetizzato con arbitraggio pubblicitario usa uno script di terze parti per analytics che, come side effect, modifica la history inserendo parametri UTM. Il comportamento del pulsante indietro risulta alterato. Il proprietario del sito è responsabile anche se il codice proviene da un vendor esterno, e deve rimuovere lo script o richiedere una versione corretta.
> COME TESTARE L'IMPATTO
- Apri Chrome DevTools → scheda Console e monitora le chiamate a history.pushState() e history.replaceState() durante la navigazione sul sito.
- Naviga su una pagina interna del sito partendo da una SERP di Google, poi premi il pulsante indietro: verifica che torni effettivamente alla SERP e non a una pagina intermedia o alla stessa pagina.
- Usa l'estensione Chrome "History API Monitor" per tracciare tutte le manipolazioni della cronologia browser durante una sessione di navigazione tipica sul sito.
- Testa il comportamento su mobile (Chrome Android e Safari iOS) perché alcune implementazioni di back button hijacking si attivano solo su dispositivi mobili dove l'utente è meno propenso a notare anomalie.
- Esegui un audit completo di tutti gli script JavaScript di terze parti (analytics, A/B testing, heatmap, advertising) per identificare manipolazioni della history non documentate.
- Controlla Google Search Console → Azioni manuali per verificare se è già presente una penalizzazione per "malicious practices" e, in caso positivo, prioritizza il fix del back button hijacking nella richiesta di riconsiderazione.
> DOMANDE FREQUENTI
Le Single Page Application sono automaticamente a rischio di penalizzazione?
+
No, se la history API è implementata correttamente. Il problema sorge quando il pulsante indietro non riporta l'utente alla pagina di provenienza attesa. Una SPA ben configurata che sincronizza stati client-side con la cronologia browser non viola la policy. Il test pratico è semplice: se l'utente arriva da Google e preme indietro, deve tornare a Google.
La penalizzazione è a livello di pagina o di dominio?
+
Google non lo specifica, ma la categorizzazione come "malicious practice" suggerisce che nei casi gravi l'impatto possa essere site-wide. Se il back button hijacking è implementato tramite script globale presente su tutte le pagine, è ragionevole aspettarsi una penalizzazione a livello di dominio. Implementazioni isolate su singole pagine potrebbero ricevere azioni più circoscritte.
Come distinguere tra bug tecnico e manipolazione intenzionale?
+
Nelle azioni manuali Google valuta il contesto: un bug isolato su una SPA complessa viene trattato diversamente da uno script dedicato a intrappolare utenti. Tuttavia, l'algoritmo potrebbe non fare questa distinzione. La responsabilità di garantire il corretto funzionamento del pulsante indietro ricade sempre sul proprietario del sito, indipendentemente dall'intenzionalità. Fix rapido e richiesta di riconsiderazione sono la strada da seguire in caso di errore tecnico.
Gli script di terze parti mi espongono a rischio anche se non controllo il codice?
+
Sì. Google considera il proprietario del sito responsabile di tutto il codice eseguito sulle sue pagine, inclusi script di vendor esterni. Se un tool di analytics o A/B testing manipola la history API causando back button hijacking, la penalizzazione colpisce il sito. È necessario auditare tutti gli script di terze parti e rimuovere quelli che alterano il comportamento del pulsante indietro.
> IL PUNTO DELLA REDAZIONE
Questa policy formalizza ciò che avrebbe dovuto essere ovvio da sempre: manipolare la navigazione dell'utente è spam, punto. Il fatto che Google abbia sentito il bisogno di esplicitarlo nel 2026 dice molto sulla diffusione della pratica, soprattutto in verticali dove il valore per pageview giustifica tattiche aggressive. Chi ha costruito strategie di retention o monetizzazione su queste tecniche deve smantellare tutto immediatamente. Il rischio non è teorico: la categorizzazione come "malicious practice" mette il back button hijacking allo stesso livello di cloaking e malware, con penalizzazioni potenzialmente devastanti. Non esistono zone grigie o interpretazioni creative. L'aspetto più insidioso riguarda le SPA e gli script di terze parti. Molti siti violano la policy senza saperlo, per bug tecnici o side effect di tool esterni. La responsabilità resta sempre del proprietario del sito. Un audit JavaScript completo non è più opzionale, è difesa preventiva contro spam action che potrebbero arrivare senza preavviso algoritmico.
> TAGS
Questo articolo include un riassunto della notizia originale e, per gli item critici (5/5), una analisi editoriale prodotta da Osservatorio SEO.
Il riassunto è generato da google/gemini-2.0-flash-001, l'analisi approfondita da anthropic/claude-sonnet-4-5.
Per il testo completo e l'attribuzione della notizia, consulta la fonte originale.