Le back button hijacking, ou détournement du bouton retour, est officiellement devenu un sujet SEO à traiter. Google a annoncé le 13 avril 2026 une nouvelle règle anti-spam, avec une mise en application prévue au 15 juin 2026. Ce n’est donc plus une alerte théorique : si un site joue avec le bouton retour, je le mettrais maintenant dans la liste des choses à vérifier sérieusement.
Le message est simple : si un site empêche l'utilisateur de revenir normalement à la page précédente avec le bouton retour du navigateur, il prend désormais un risque Search. Et c’est justement le point qui m’intéresse ici : le problème peut venir d’un choix volontaire, mais aussi d’un script publicitaire, d’une bibliothèque JavaScript, d’un module de recommandation ou d’un outil marketing mal configuré.
Ce que Google appelle back button hijacking
Dans son annonce officielle, Google définit le problème autour d'une attente très simple : quand un utilisateur clique sur le bouton retour, il veut revenir à la page précédente. Le back button hijacking casse cette attente en interférant avec la navigation du navigateur. L'utilisateur peut être renvoyé vers une page qu'il n'a jamais visitée, vers une recommandation forcée, vers de la publicité ou vers un parcours qui l'empêche de revenir directement en arrière.
La documentation des spam policies de Google range désormais ce comportement dans les malicious practices. Cela ne veut pas dire que tous les sites concernés cherchent à installer un logiciel malveillant. Le cœur du sujet est plutôt la tromperie UX : le résultat réel ne correspond plus à ce que l'utilisateur croit déclencher.
Cette précision compte beaucoup pour les éditeurs et les sites monétisés. Un site peut être concerné même si le code problématique vient d'un script tiers. Google le dit explicitement dans son billet : certaines instances peuvent provenir de bibliothèques incluses ou de plateformes publicitaires. À la place du propriétaire du site, je ne me contenterais donc pas de dire “ce n’est pas mon script”. Je vérifierais ce qui se passe réellement en front.
Ce qui devient risqué pour un site
Les cas les plus risqués sont ceux où le site manipule l'historique du navigateur pour empêcher un retour normal. On parle par exemple de pages ajoutées artificiellement dans l'historique, de redirections déclenchées au moment où l'utilisateur veut repartir, ou de parcours qui obligent à cliquer plusieurs fois sur retour avant de sortir.
Le risque n'est pas seulement théorique. Google indique que les pages concernées peuvent faire l'objet d'une action manuelle spam ou de démotions automatisées, avec un impact possible sur la performance dans les résultats de recherche. Search Engine Roundtable a aussi relayé fin avril 2026 des alertes envoyées via Search Console à des sites susceptibles d'être concernés.
Ce qui n'est pas automatiquement interdit
Je ferais attention à ne pas tomber dans une lecture trop simpliste. Tout usage de l'API History de JavaScript n'est pas du spam. Les applications web modernes utilisent parfois history.pushState, history.replaceState ou l'événement popstate pour gérer une navigation interne propre, des filtres, des onglets, des formulaires ou des routes côté client.
La différence tient à l'intention et au résultat. Si le bouton retour permet bien de revenir à l'étape attendue, ou de quitter la page normalement vers la source précédente, on n'est pas dans le même cas qu'un site qui piège l'utilisateur. Le problème commence quand l'utilisateur est retenu, redirigé ou envoyé vers une page qu'il n'a pas demandé à visiter.
À retenir : Google ne dit pas "n'utilisez jamais l'historique navigateur". Google dit plutôt : n'utilisez pas l'historique navigateur pour tromper l'utilisateur ou l'empêcher de revenir immédiatement à la page d'où il vient.
C'est aussi pour cela que le sujet rejoint nos autres points techniques sur le rendu et la qualité front. Un site JavaScript peut être parfaitement sain, mais il doit rester lisible, navigable et cohérent. Si vous travaillez sur ce type d’architecture, l’article sur Google, JavaScript et les pages non-200 complète bien cette lecture.
Comment auditer son site
Le premier test est volontairement simple. J’ouvrirais une page depuis Google ou depuis une autre page du site, je naviguerais comme un visiteur normal, puis j’utiliserais le bouton retour du navigateur. À faire sur desktop et mobile, en navigation classique et si possible avec un profil propre. Le retour doit être prévisible.
Ensuite, il faut regarder le code et les scripts chargés. Les termes à rechercher dans le projet ou dans les scripts tiers sont notamment pushState, replaceState, popstate, onbeforeunload et les modules qui interceptent la sortie utilisateur. Ce ne sont pas des preuves de spam à eux seuls, mais ce sont de bons points d'entrée.
Si vous utilisez Google Tag Manager, des scripts publicitaires, des outils de popup, des widgets de recommandation ou des scripts d'affiliation, je contrôlerais aussi cette couche. Une page peut être propre dans le code source du site, puis devenir problématique une fois les tags marketing chargés.
Point de vigilance : testez avec les vrais consentements et les vraies conditions de diffusion. Certains scripts ne se déclenchent qu'après acceptation cookies, sur mobile, sur certaines géos, ou après une source de trafic précise.
Popups, régies pub et trafic pop : où faire attention
Les popups classiques ne sont pas automatiquement du back button hijacking. Un popup d'inscription, une bannière de consentement ou une offre de sortie peuvent être agaçants, mais le vrai sujet Google concerne le détournement de la navigation. Cela dit, la frontière devient vite mauvaise quand un outil intercepte le bouton retour pour forcer une offre, une page d'abonnement ou une recommandation.
Pour les sites qui utilisent des formats publicitaires agressifs, du trafic pop, des interstitiels ou des systèmes de rotation de landing pages, je monterais franchement le niveau de prudence. Il faut vérifier que l'utilisateur peut toujours revenir à sa page précédente sans être enfermé dans une boucle, sans être renvoyé vers une page qu'il n'a pas demandée, et sans devoir cliquer plusieurs fois pour sortir.
Ce sujet croise aussi la gestion des liens et des campagnes. Un outil comme Linka Factory peut aider à contrôler des liens, des QR codes ou des destinations de campagne, mais il ne doit jamais servir à masquer une destination interdite ou à contourner les règles d'une régie. Le bon usage reste le pilotage propre d'un lien, pas la tromperie UX.
Si vous travaillez avec des outils de capture de leads, gardez aussi en tête la logique utilisateur. Dans l’avis sur Poptin, on insiste déjà sur la différence entre un popup utile et un popup qui abîme l'expérience. Avec la règle Google sur le bouton retour, cette nuance devient encore plus importante.
Tableau de décision
| Comportement observé | Risque SEO/UX | Lecture ToolsBoxSEO | Action recommandée |
|---|---|---|---|
| Le bouton retour ramène à la page précédente normalement. | Faible | Comportement attendu. | Rien à corriger, mais tester après chaque ajout de script. |
| Le retour ouvre une page de recommandation ou une page publicitaire non visitée. | Élevé | Cas typique à corriger rapidement. | Désactiver le script ou la configuration responsable. |
| Il faut cliquer plusieurs fois pour quitter une page. | Élevé | Le parcours donne l'impression de retenir l'utilisateur. | Auditer l'historique navigateur et les scripts tiers. |
| Une application web utilise l'historique pour ses routes internes. | Variable | Normal si le parcours reste prévisible. | Tester les routes, filtres, modales et gestes retour mobile. |
| Un popup apparaît quand l'utilisateur semble vouloir partir. | Moyen | Pas toujours la même infraction, mais l'UX peut devenir mauvaise. | Limiter la fréquence, éviter les pièges et mesurer les signaux comportementaux. |
Que faire si Search Console envoie une alerte ?
Si Search Console signale un risque ou une action manuelle, je traiterais le sujet comme un incident SEO. La première étape consiste à récupérer les exemples d'URL, reproduire le comportement, puis identifier si le problème vient du code du site, d'un tag, d'un plugin, d'une régie ou d'une configuration.
Une fois le comportement supprimé, il faut retester depuis plusieurs appareils et plusieurs sources de trafic. Si une action manuelle a été appliquée, Google indique qu'une demande de réexamen peut être envoyée après correction. Il vaut mieux documenter clairement ce qui a été retiré, désactivé ou remplacé.
Le suivi Search Console reste ensuite essentiel. Le guide sur les rapports Search Console IA générative porte sur un autre sujet, mais la méthode de lecture reste utile : ne pas réagir à un seul signal isolé, croiser les dates, les pages, les requêtes, les appareils et les changements techniques.
Verdict ToolsBoxSEO
Le back button hijacking est un bon exemple de sujet où SEO et UX se rejoignent. Même sans sanction Google, je trouve que piéger le bouton retour est déjà une très mauvaise idée : cela casse la confiance, augmente la frustration et donne envie de ne jamais revenir sur le site. Depuis le 15 juin 2026, c'est en plus un risque explicite dans les règles spam de Google.
Pour un site propre, la correction est souvent simple : ne pas manipuler l'historique pour retenir l'utilisateur, auditer les scripts tiers, éviter les mécaniques publicitaires opaques, et tester le parcours réel sur mobile. Pour un site très monétisé par la publicité ou le trafic pop, je ferais ce contrôle avant de chercher de nouvelles optimisations SEO.
Mon avis : il ne faut pas transformer cette règle en panique générale. Mais il ne faut pas non plus la ranger dans les détails techniques. Le bouton retour est un contrat implicite avec le visiteur. Si ce contrat est cassé, Google vient maintenant de donner un nom SEO au problème.
FAQ
Qu'est-ce que le back button hijacking ?
Le back button hijacking consiste à interférer avec le bouton retour du navigateur pour empêcher l'utilisateur de revenir immédiatement à la page précédente. Il peut être renvoyé vers une page non visitée, une publicité, une recommandation forcée ou un parcours inattendu.
Depuis quand Google sanctionne-t-il cette pratique ?
Google a annoncé cette règle le 13 avril 2026, avec une application à partir du 15 juin 2026. Après cette date, les pages concernées peuvent être exposées à des actions manuelles spam ou à des démotions automatisées.
Les popups sont-ils interdits par cette règle ?
Non, pas automatiquement. Le sujet principal n'est pas l'existence d'un popup, mais le fait de détourner ou bloquer le retour navigateur. Un popup peut toutefois devenir un problème UX s'il force un parcours ou gêne excessivement la navigation.
Un site Next, React ou JavaScript est-il plus à risque ?
Pas forcément. Les sites JavaScript utilisent parfois l'historique navigateur pour gérer des routes ou des états d'interface. C'est acceptable si le retour reste logique et prévisible. Le risque commence quand cette mécanique empêche l'utilisateur de revenir à sa page d'origine.
Comment savoir si un script publicitaire est responsable ?
Je testerais la page avec les tags actifs, puis je comparerais avec une version sans certains scripts. Ensuite, je regarderais les événements liés à l'historique navigateur et les conditions de déclenchement : mobile, géo, source de trafic et consentement cookies.
Que faire si une action manuelle est reçue ?
Je corrigerais d’abord le comportement, puis je documenterais la suppression du script ou de la configuration responsable. Ensuite seulement : retest des URLs concernées et demande de réexamen dans Search Console si l'action manuelle est bien appliquée.