Back button hijacking : Google sanctionne au 15 juin 2026

Le 13 avril 2026, Google a ajouté une nouvelle entrée à ses spam policies : le back button hijacking, classé dans la catégorie "malicious practices". Préavis de deux mois, enforcement le 15 juin. Ceux qui n'ont pas nettoyé d'ici là tombent sous manual action ou demotion automatique. C'est rare que Google annonce une date limite aussi nette.

Ce que Google appelle back button hijacking#

La définition officielle, mot pour mot dans le post Search Central : tout script ou technique qui insère ou remplace des pages dans l'historique navigateur de manière déceptive, empêchant l'utilisateur de revenir immédiatement à la page précédente.

En clair : tu cliques sur un résultat Google, tu veux retourner à la SERP avec le bouton Retour, et là, soit tu retombes sur la même page que tu viens de quitter, soit on te jette sur un faux feed Discover, soit tu te tapes une page intermédiaire que personne n'a demandée. Le bouton Retour devient inutile.

Google précise dans le post avoir "constaté une hausse de ce type de comportement" ces derniers mois. Glenn Gabe, qui suit le sujet depuis longtemps, a tweeté le jour même : "If you hijack the back button, you are going to get a manual action. This is great news for users. Enough with hijacking the back button and providing a Google-like feed."

Le vecteur technique#

Le coupable principal a un nom : history.pushState() et history.replaceState(). L'API History HTML5, utilisée légitimement par toutes les SPA modernes (React Router, Vue Router, Next.js navigation client) pour mettre à jour l'URL sans recharger la page. Sauf que la même API peut empiler des entrées bidon dans l'historique, ou intercepter l'event popstate pour rediriger vers une page de votre choix.

J'ai vu ce pattern dans la nature plusieurs fois ces deux dernières années : un éditeur média qui présente un faux feed "à lire ensuite" quand tu cliques Retour depuis Google, des sites affiliés qui intercalent une page promotionnelle avant la SERP, des pop-ups exit-intent qui empilent des pushState pour neutraliser le geste de sortie. Tout ça tombe.

Le piège : la responsabilité du tiers#

Le point qui va faire mal à beaucoup d'éditeurs : le site owner est responsable même si le script vient d'une lib externe ou d'une régie publicitaire. Google le dit explicitement dans le post.

Ça veut dire quoi concrètement ? Si ta régie pousse un tag JavaScript qui hijack le Retour à ton insu, c'est ton site qui prend la sanction. Si ton script d'affiliation insère une redirection intermédiaire, idem. Si ton outil de pop-ups (genre exit-intent) ajoute une entrée d'historique pour bloquer la sortie, c'est pour ta pomme.

Aucun nom de plugin n'a été cité officiellement par Google. Évite les articles qui te balancent une liste de "10 plugins WordPress à désinstaller". Personne n'a de liste officielle. Audite ton propre site, c'est la seule méthode honnête.

Notices Search Console : pas encore de sanction#

Le 27 avril, Google a commencé à envoyer des notices dans Search Console aux sites détectés. Snapshot des données : 17 avril 2026. Texte clé dans la notice : "No manual action has been taken at this time." Pas de pénalité immédiate, juste un avertissement.

Google s'engage à re-vérifier la conformité avant le 15 juin avant de balancer une vraie manual action. Spoiler : ça veut dire que tu as une fenêtre nette pour corriger sans pénalité, mais aussi qu'après le 15 juin, ce sera vérification puis sanction sans préavis. La reconsideration request via Search Console reste réservée aux manual actions réelles, pas aux warnings proactifs.

J'ai testé : audit DevTools en cinq minutes#

Trois méthodes simples pour vérifier ton propre site, aucune ne demande d'outil payant.

Méthode 1 : compter les entrées d'historique. Ouvre Chrome, va sur ton site depuis une recherche Google. Clic droit sur le bouton Retour : si la même page apparaît cinq fois ou plus dans la liste, hijacking confirmé.

Méthode 2 : DevTools popstate. Ouvre l'onglet Sources, puis Event Listeners, cherche popstate. Si plusieurs scripts écoutent cet event, regarde lesquels et ce qu'ils font. Les SPA légitimes écoutent normalement, mais une seule fois et pour router, pas pour rediriger.

Méthode 3 : history.length dans la console. Tape history.length, navigue normalement sur le site, retape history.length. Si le chiffre monte de plusieurs unités sans navigation réelle de ta part, un script empile des entrées en arrière-plan.

Combine les trois, tu sais en cinq minutes si tu es propre.

Pourquoi Google sort ça maintenant#

Le contexte technique : Navboost. Le système de Google qui suit treize mois de signaux comportementaux (clics, retours SERP, dwell time) pour ajuster les classements. Glenn Gabe l'avait expliqué dès 2024 sur son blog gsqi.com : le back button hijacking permet de gamer Navboost en faisant croire que l'utilisateur reste sur le site, alors qu'il essayait juste de partir.

C'est cohérent avec la ligne dure que Google tient depuis le spam update de mars 2026 et la nouvelle approche people-first contre le contenu IA. On est dans la même logique : tout ce qui manipule les signaux utilisateur passe à la trappe.

À noter aussi le timing avec le DSA et la fin d'AI Max prévue septembre 2026. Google nettoie son écosystème avant les contraintes réglementaires européennes. Cohérent.

Ce que tu fais cette semaine#

Avant le 15 juin, trois actions concrètes.

D'abord, audite ton site avec les méthodes DevTools ci-dessus. Si tu as une notice Search Console, identifie les pages listées et regarde précisément le JS qui s'exécute dessus.

Ensuite, isole les tags tiers. Régies, pop-ups, affiliés, scripts d'analytics exotiques. Désactive-les un par un et retest. Si tu identifies le coupable, vire-le ou remplace-le.

Enfin, si tu utilises des SPA, vérifie ta config router. React Router et Vue Router peuvent empiler des entrées si mal configurés (mode hash, gestion incorrecte des redirections, navigation programmatique mal pensée). Ce n'est pas du hijacking volontaire, mais Google ne fait pas la distinction.

Mon avis tranché#

Ce qui m'agace avec ce genre de policy, c'est la responsabilité asymétrique. Tu paies pour les bêtises de ta régie, alors que Google ne donne ni liste de scripts incriminés ni outil de détection officiel. Tu te débrouilles.

Mais sur le fond, Google a raison. Le back button hijacking est une pratique sale qui parasite l'expérience utilisateur depuis des années. Le bouton Retour appartient au navigateur, pas au site. Quand un éditeur le détourne, il vole une fonction système.

Si ton site est propre, tu n'as rien à faire. Si tu as une notice Search Console, tu as un mois pour corriger. Si tu n'es pas sûr, audite avant le 15 juin. Après, c'est manual action ou demotion automatique sans avertissement.