Google ha dichiarato guerra al back button hijacking
Google introduce una nuova policy antispam che classifica il back button hijacking come pratica malevole, con possibili azioni manuali.
Google ora puo’ colpire con azioni manuali i siti che manipolano la cronologia del browser
Immagina di cliccare il tasto “indietro” del browser dopo aver aperto un sito da una ricerca Google. Invece di tornare alla SERP, ti ritrovi in un loop: popup che si aprono, redirect che si sovrappongono, e il tuo tasto “indietro” che non serve a niente. Questo è il back button hijacking, una pratica che esiste da anni e che Google ha formalmente dichiarato guerra. Lo scorso 13 aprile, secondo il changelog ufficiale di Google Search Central, Mountain View ha introdotto una nuova politica antispam esplicita che classifica il back button hijacking come violazione delle “pratiche malevole” delle spam policy — con conseguenti possibili azioni manuali. Un cambiamento che sulla carta sembra tecnico, ma che nasconde un’inversione di rotta significativa nella filosofia di enforcement di Google.
Il meccanismo del dirottamento
Per capire la nuova policy, bisogna prima guardare come funziona il trucco. Quando un browser naviga tra le pagine, tiene traccia della cronologia in uno stack: ogni visita viene impilata, e il tasto “indietro” esegue un pop dall’alto di quello stack. La History API di HTML5 — introdotta per permettere alle Single Page Application di aggiornare l’URL senza ricaricare la pagina — espone metodi come history.pushState() e history.replaceState() che consentono agli sviluppatori di manipolare quello stack in modo programmatico. L’uso legittimo è evidente: una SPA che mostra risultati filtrati può aggiornare l’URL riflettendo lo stato dell’interfaccia, mantenendo funzionale il tasto “indietro” per l’utente.
L’abuso, però, è altrettanto semplice. Uno script malevolo può chiamare history.pushState() ripetutamente nel momento in cui l’utente apre la pagina, riempiendo lo stack con voci fittizie. Il risultato: ogni click su “indietro” consuma una voce artificiale dello stack, mostrando magari un interstitial pubblicitario o reindirizzando verso un’altra pagina del sito, prima che l’utente riesca finalmente a tornare alla SERP di Google. È un pattern deliberatamente ostile, che sfrutta un’API pensata per migliorare l’esperienza utente per fare esattamente il contrario. Già nel luglio 2013, Google aveva pubblicato un post di avvertimento sulle pratiche ingannevoli che includeva esplicitamente questo comportamento — ma senza mai formalizzarlo come violazione delle spam policy.
Dagli algoritmi alle azioni manuali
E qui arriva il colpo di scena: Google ha sempre sostenuto che le segnalazioni di spam servissero esclusivamente ad addestrare gli algoritmi di rilevamento, non a innescare interventi diretti. Nel luglio 2020, Gary Illyes aveva messo nero su bianco questa posizione nel post ufficiale sull’utilizzo delle segnalazioni spam, specificando che i report degli utenti non venivano usati per azioni manuali, ma solo per migliorare il sistema di rilevamento automatico. Era una scelta coerente con la filosofia di scalabilità di Google: non puoi avere team umani che revisionano miliardi di segnalazioni.
Ora quella posizione è cambiata. Il 14 aprile Google ha chiarito esplicitamente che le segnalazioni di spam possono essere utilizzate per intraprendere azioni manuali contro le violazioni. Non è un dettaglio marginale: significa che un utente che segnala un sito per back button hijacking potrebbe, in teoria, innescare una revisione manuale da parte del team di Search Quality, con conseguenze ben più severe di un aggiustamento algoritmico. Le azioni manuali appaiono in Google Search Console, richiedono una richiesta di revisione esplicita per essere rimosse, e possono deprimere o eliminare completamente la visibilità organica di un sito.
Come conferma l’annuncio ufficiale sul blog di Google Search Central, il back button hijacking diventa ora una violazione esplicita della categoria “malicious practices” nelle spam policy. La formulazione è diretta: “Today, we are expanding our spam policies to address a deceptive practice known as back button hijacking, which will become an explicit violation of the malicious practices of spam policies, leading to potential spam actions.” Il termine “potential spam actions” è deliberatamente ampio — copre sia le penalizzazioni algoritmiche sia le azioni manuali. Vale la pena notare che questo cambiamento arriva pochi mesi dopo il Discover core update di febbraio 2026, un periodo in cui Google ha evidentemente lavorato a un riassetto più ampio delle sue politiche di qualità.
Cosa cambia per chi costruisce
Vediamo le implicazioni pratiche. Se stai usando history.pushState() in un’applicazione legittima — per gestire la navigazione in una SPA, per tracciare stati dell’UI, per implementare infinite scroll con URL aggiornati — non hai nulla da temere. L’uso corretto della History API non è in discussione. Il problema è l’abuso: chiamate multiple e non richieste che inseriscono voci nello stack solo per intrappolare l’utente. Se il tuo codice fa questo, o se stai usando una libreria di terze parti che lo fa a tua insaputa (alcuni widget pubblicitari o sistemi di monetizzazione hanno storicamente usato questa tecnica), è il momento di fare un audit.
Ci sono altri segnali che indicano un momento di pulizia più generale nella documentazione e nelle policy di Google. A fine marzo, erano già state aggiunte nuove proprietà supportate per il markup di Discussion Forum e QA Page — una buona notizia per chi lavora con dati strutturati su siti di community. Il 20 aprile è arrivata anche una nuova sezione sui deep link “leggi tutto” nella documentazione degli snippet. A inizio marzo, invece, Google aveva rimosso dalla documentazione SEO di base su JavaScript una sezione sull’accessibilità ormai datata — un cleanup che segnala l’intenzione di mantenere la documentazione tecnica allineata alle pratiche attuali. Per chi costruisce siti, questi aggiornamenti vanno letti insieme: Google sta stringendo le maglie su comportamenti scorretti e contemporaneamente fornisce strumenti più precisi per chi lavora in modo corretto.
La storia della navigazione browser è, in un certo senso, sacra per il web: è il contratto implicito tra sito e utente, l’aspettativa fondamentale che “indietro” significhi davvero indietro. Forzare quell’interazione è come bloccare la porta d’uscita di un negozio per costringere il cliente a guardare un’altra vetrina — è manipolazione, non marketing. Google ora ha gli strumenti formali per punire chi lo fa, e tocca agli sviluppatori assicurarsi di non essere tra i colpevoli: non per paura delle penalizzazioni, ma perché rispettare il comportamento atteso dal browser è semplicemente buona ingegneria.
