Google a ajouté, le 13 avril 2026, une nouvelle infraction à ses règles anti-spam : le détournement du bouton Retour, ou back button hijacking. Une pratique ancienne, tolérée pendant des années, désormais classée dans la catégorie des pratiques malveillantes (malicious practices). Les sanctions tomberont à partir du 15 juin 2026, sous forme d’actions manuelles ou de rétrogradations algorithmiques.
Ce que recouvre la pratique
Le back button hijacking désigne toute manipulation qui empêche un utilisateur de revenir à la page précédente en cliquant sur le bouton Retour de son navigateur. Concrètement, l’internaute clique sur un résultat Google, atterrit sur une page, tente de repartir, et se retrouve bloqué : même page qui se recharge, redirection vers un interstitiel publicitaire, feed de recommandations façon Discover, ou enchaînement de pages jamais visitées. Dans les cas les plus agressifs, il faut cliquer plusieurs fois sur « Précédent » avant de s’extraire.
Techniquement, la manipulation exploite la History API, l’interface JavaScript qui permet aux applications web modernes de modifier l’historique du navigateur sans recharger la page. Les méthodes history.pushState() et history.replaceState() sont utilisées pour injecter des entrées factices dans la pile d’historique dès le chargement. Une variante intercepte l’événement popstate, déclenché à chaque tentative de navigation arrière, pour forcer une redirection. L’API elle-même reste parfaitement légitime, notamment dans les SPA (Single Page Applications, applications monopages qui gèrent le routage côté client) : Google vise l’abus, pas l’usage.
Un revirement assumé
Google reconnaît dans son communiqué avoir toléré la pratique par le passé, tout en la jugeant contraire aux Search Essentials. Le motif du durcissement est explicite : l’équipe Search Quality observe une hausse de ces comportements. Le calendrier n’est pas anodin. La chute du trafic référent, accélérée par les AI Overviews (les résumés génératifs affichés en haut des SERP) et la progression du zero-click, a poussé certains éditeurs et régies à durcir leurs tactiques de rétention. Une industrie de scripts de monétisation s’est développée, empaquetant la manipulation d’historique sous des appellations neutres comme « exit-intent recovery » ou « scroll-depth engagement ».
Chris Nelson, qui signe le billet pour l’équipe Search Quality, cadre la logique : les utilisateurs se sentent manipulés et deviennent moins enclins à cliquer sur des sites inconnus. Autrement dit, le problème déborde du site fautif et contamine la confiance dans les résultats de Google eux-mêmes.
Les esprits mal tournés signaleront que la disparition de cette pratique améliore, comme souvent, les statistiques de trafic de Google… Mais laissons cela aux esprits mal tournés.
Responsabilité élargie aux scripts tiers
Le point le plus sensible du communiqué concerne l’origine du code incriminé. Google précise que le détournement peut provenir de bibliothèques tierces ou de la plateforme publicitaire utilisée par le site. La responsabilité reste intégralement celle de l’éditeur. Un script de régie, un widget de recirculation, un module de consentement trop zélé, un A/B testing mal configuré : si le comportement se produit sur le domaine, la sanction frappe le domaine.
Les cibles prioritaires se dessinent assez nettement :
- éditeurs à forte monétisation publicitaire, notamment les MFA (Made for Advertising, sites conçus avant tout pour générer des impressions publicitaires)
- sites affiliés agressifs
- pages de destination utilisant des interstitiels et des popunders
- widgets de « contenus recommandés » injectés en fin d’article
Second point critique, rarement commenté : depuis décembre 2024, Google lie les actions manuelles de Search à l’éligibilité Google Ads. Un site frappé par une action manuelle pour détournement du bouton Retour peut donc perdre simultanément son classement organique et l’accès à la publicité payante.
Vérifiez que vous êtes dans les clous avant le 15 juin
Le délai de deux mois laisse le temps d’un audit sérieux. Les vérifications à conduire :
- tester le bouton Retour depuis une SERP Google réelle, sur mobile et desktop, et sur plusieurs navigateurs
- inspecter via les DevTools la valeur de
history.lengthau chargement des pages, et surveiller les appels àpushStatenon déclenchés par une navigation utilisateur - auditer les scripts tiers, en désactivant séquentiellement les régies, outils de popup et widgets d’engagement
- vérifier que les implémentations SPA ne poussent pas d’états fantômes à chaque re-render
La règle de contrôle la plus simple reste empirique : un seul clic sur « Précédent » doit ramener l’utilisateur à la page d’origine, sans exception.
Bibliographie
- Google Search Central, annonce officielle, 13 avril 2026
- Documentation Google sur les pratiques malveillantes
- Search Engine Journal, analyse de Matt G. Southern
- Search Engine Roundtable, couverture de Barry Schwartz
- PPC Land, lien entre sanctions Search et éligibilité Ads
- The Next Web, contexte de la malvertising « D-Shortiez »
- MDN Web Docs, documentation de la History API