Back button hijacking – Ton site WordPress piège-t-il le bouton retour du navigateur ?

C’est quoi le back button hijacking ?

Le back button hijacking consiste à manipuler le comportement normal du bouton retour du navigateur.

Normalement quand un visiteur clique sur “retour”, il revient à la page précédente. C’est un réflexe de navigation basique. Un peu comme pousser une porte pour entrer. Si la porte te renvoie dans le couloir d’à côté, tu commences à trouver ça louche.

Avec le back button hijacking, le site modifie l’historique du navigateur pour empêcher ou détourner ce retour normal.

Des résultats possibles :

• le visiteur reste sur la même page ;
• il arrive sur une page qu’il n’a pas demandée ;
• une publicité s’affiche ;
• une pop-up revient au mauvais moment ;
• il doit cliquer plusieurs fois pour quitter ;
• il a l’impression que le site essaie de le coincer.

Et cette impression est très mauvaise pour la confiance.

Un visiteur qui se sent piégé ne se dit pas “tiens, quel tunnel de conversion audacieux”. Il ferme l’onglet. Rapidement. Parfois avec une petite rancune bonus.

Pourquoi Google surveille cette pratique ?

Google s’intéresse au back button hijacking parce que cette pratique trompe l’utilisateur.

Quand quelqu’un arrive depuis les résultats de recherche, il doit pouvoir revenir en arrière facilement si la page ne répond pas à son besoin. C’est normal et sain. C’est ce que l’on appelle le web civilisé.

Si un site empêche ce retour, il dégrade l’expérience utilisateur. Et pour Google, ce genre de manipulation peut devenir un signal de spam ou de comportement malveillant.

Le sujet devient donc important pour tous les propriétaires de sites WordPress. Même si le site n’a aucune intention douteuse, un script tiers ou un plugin mal configuré peut créer un comportement problématique.

Et dans ce cas, “je ne savais pas” ne protège pas vraiment. Le visiteur, lui, ne voit pas l’intention. Il voit juste un site pénible.

Comment ça fonctionne techniquement ?

Le back button hijacking repose souvent sur la manipulation de l’historique du navigateur.

Les sites web peuvent utiliser JavaScript pour modifier certaines entrées de navigation. Ce n’est pas forcément mauvais. Beaucoup de sites utilisent ce mécanisme pour des filtres, des interfaces dynamiques, des formulaires en plusieurs étapes ou des applications web.

Le problème commence quand cette possibilité est utilisée pour tromper le visiteur.

Pour comprendre le mécanisme de base sans tomber dans un roman technique, l’API History du navigateur explique comment un site peut ajouter ou modifier des entrées dans l’historique.

C’est un peu comme une relance de newsletter, bien utilisée, elle rend service. Envoyée 12 fois par jour, elle déclenche surtout une envie de désabonnement musclé.

Un site WordPress peut-il être concerné ?

Oui, un site WordPress peut être concerné par le back button hijacking WordPress.

Et non, cela ne veut pas forcément dire que le site a été piraté ou que quelqu’un a installé volontairement un script douteux.

Sur WordPress, beaucoup d’éléments peuvent ajouter du JavaScript :

• le thème ;
• les constructeurs de pages ;
• les extensions marketing ;
• les pop-ups ;
• les scripts publicitaires ;
• les outils d’affiliation ;
• les tags de tracking ;
• les widgets externes ;
• les scripts ajoutés dans le header ou le footer.

La plupart de ces outils peuvent être utiles. Le souci, c’est l’accumulation, les réglages agressifs ou les scripts tiers mal contrôlés.

Un site WordPress, ça peut vite devenir une colocation de plugins. Chacun ramène son petit bout de code, son CSS, son JavaScript, son script de suivi… et à la fin, personne ne sait vraiment qui a laissé la lumière allumée dans le navigateur.

Quels signes doivent alerter ?

Le visiteur ne voit pas “history.pushState” ou “replaceState” dans le code. Il voit juste que le site se comporte bizarrement.

Quelques signes doivent mettre la puce à l’oreille :

• le bouton retour ne ramène pas à la page précédente ;
• la même page semble se recharger ;
• une page intermédiaire apparaît sans raison ;
• une pop-up revient au moment de quitter ;
• le visiteur doit cliquer plusieurs fois sur retour ;
• le navigateur change d’URL sans vraie action claire ;
• le comportement est différent sur mobile ;
• une publicité ou une offre apparaît après le clic retour.

Le point commun est simple : le visiteur perd le contrôle.

Et sur le web, perdre le contrôle, même quelques secondes, suffit souvent à casser la confiance.

Back button hijacking ou simple bug ?

Tous les problèmes de bouton retour ne sont pas du back button hijacking.

Parfois, le souci vient d’un bug tout bête. Enfin, “tout bête” jusqu’au moment où il faut le trouver.

Le problème peut venir :

• d’un cache mal configuré ;
• d’un formulaire en plusieurs étapes ;
• d’un tunnel de paiement ;
• d’un plugin de traduction ;
• d’un site qui utilise beaucoup d’AJAX ;
• d’une redirection mal pensée ;
• d’un constructeur de pages ;
• d’un conflit entre extensions.

La différence se joue surtout sur le comportement.

Si le bouton retour est cassé à cause d’un bug, il faut le corriger. Si le bouton retour est volontairement détourné pour retenir le visiteur, là c’est plus grave.

Dans les deux cas, l’utilisateur final ne va pas faire d’enquête. Il va juste se dire que le site fonctionne mal, et il n’aura pas totalement tort.

Pourquoi c’est mauvais pour l’expérience utilisateur ?

Le bouton retour est l’un des gestes les plus naturels sur le web.

Le visiteur l’utilise pour revenir à une page précédente, comparer deux contenus, quitter une page qui ne l’intéresse pas ou retourner aux résultats de recherche.

Quand ce bouton ne répond plus comme prévu, l’expérience devient frustrante.

Un bon site doit laisser le visiteur respirer. Il doit pouvoir avancer, revenir, choisir, lire, hésiter, repartir et revenir plus tard. Internet n’est pas une salle d’interrogatoire. On ne bloque pas la porte en espérant que la personne signe un devis.

Avec WordPress, cette liberté de navigation fait partie de l’expérience globale. Un beau design ne suffit pas si le parcours donne une impression de piège. C’est pour ça qu’un Webdesign de qualité dans WordPress doit aussi respecter les réflexes simples du visiteur, notamment : lire, cliquer, revenir en arrière, comprendre où il se trouve.

Pourquoi c’est mauvais pour le SEO ?

Le back button hijacking WordPress peut aussi poser des problèmes côté SEO.

Google cherche à envoyer ses utilisateurs vers des pages utiles, fiables et pas trompeuses. Si un site empêche le retour normal ou manipule la navigation, il envoie un très mauvais signal.

Même sans sanction immédiate, ce type de comportement peut dégrader :

• la confiance ;
• la qualité perçue ;
• l’expérience mobile ;
• le taux de satisfaction ;
• les conversions ;
• l’image de marque ;
• le suivi des performances SEO.

Le SEO ne se limite pas aux mots-clés et aux balises. Un site bien référencé doit aussi offrir une navigation propre. Si le visiteur a l’impression d’être piégé, ce n’est pas une optimisation. C’est une prise d’otage avec un bouton CTA. Et ça, ce n’est pas une stratégie durable.

Comment savoir si ton site WordPress est concerné ?

Le plus simple est de tester le site comme un vrai visiteur.

Pas connecté à WordPress, pas non plus depuis l’admin et pas avec tous les scripts bloqués. Il faut tester dans des conditions normales.

Voici une méthode simple :

• ouvrir une fenêtre de navigation privée ;
• chercher une page du site depuis Google ;
• cliquer sur le résultat ;
• lire ou faire défiler la page ;
• cliquer sur le bouton retour ;
• vérifier si le navigateur revient bien à la page précédente.

Le test doit être fait sur plusieurs pages.

Priorité aux pages sensibles :

• page d’accueil ;
• pages services ;
• articles de blog ;
• pages avec pop-up ;
• pages avec publicités ;
• pages de capture email ;
• pages de vente ;
• formulaires ;
• pages consultées depuis mobile.

Il faut aussi tester après avoir accepté ou refusé les cookies, fermé une pop-up, cliqué sur un bouton ou changé de page. Certains scripts ne se déclenchent qu’après une interaction.

Oui, c’est un peu fastidieux. Mais bien moins que de découvrir plus tard que le site joue au labyrinthe avec les visiteurs.

Où chercher le problème dans WordPress ?

Si le bouton retour se comporte mal, il faut chercher du côté des éléments qui ajoutent du JavaScript.

Les suspects habituels :

• plugins de pop-up ;
• plugins de génération de leads ;
• extensions d’affiliation ;
• scripts publicitaires ;
• outils de tracking ;
• plugins de notifications ;
• widgets externes ;
• scripts ajoutés dans le header ;
• scripts ajoutés dans le footer ;
• anciennes personnalisations du thème ;
• extensions complémentaires d’un constructeur.

L’idée n’est pas d’accuser le premier plugin venu. La bonne pratique consiste à tester sur une version de préproduction, puis à désactiver temporairement les éléments suspects un par un. A ne pas faire directement sur le site en production un vendredi à 17 h 42. C’est rarement là que naissent les bonnes idées.

Quels morceaux de code surveiller ?

Certains termes peuvent aider à repérer une manipulation de l’historique.

Dans les scripts, il faut notamment surveiller :

• history.pushState ;
• history.replaceState ;
• window.history ;
• popstate ;
• location.href ;
• location.replace ;
• les redirections déclenchées après le bouton retour.

Mais attention : ces éléments ne sont pas automatiquement mauvais.

Un site peut utiliser pushState proprement, par exemple pour modifier une URL après l’application d’un filtre. Le problème arrive quand le script ajoute volontairement de fausses étapes pour empêcher le visiteur de sortir.

La question n’est donc pas : “Ce code existe-t-il ?”

La vraie question est : “Que fait-il au parcours du visiteur ?”

Les pop-ups sont-elles concernées ?

Oui, certaines pop-ups peuvent être concernées.

Pas tous, évidemment. Une pop-up bien conçue peut être utile pour une inscription à une newsletter, une ressource gratuite, un message important ou encore une offre ponctuelle.

Le problème commence quand la pop-up devient collante, très collante. Du genre pot de miel sur clavier.

Exemples à éviter :

• pop-up qui revient immédiatement après fermeture ;
• fausse croix de fermeture ;
• offre qui apparaît uniquement au clic retour ;
• redirection forcée vers une autre page ;
• blocage de la navigation ;
• empilement de fenêtres ;
• impossibilité de quitter proprement.

Une bonne pop-up doit proposer et ne pas coincer l’utilisateur sur place.

Le visiteur doit pouvoir refuser, fermer, continuer sa lecture ou quitter la page. C’est la base. Sinon, ce n’est plus du marketing, c’est un vendeur qui bloque la sortie du magasin avec un kakémono.

Les plugins WordPress sont-ils dangereux ?

Non, les plugins WordPress ne sont pas dangereux par nature.

Mais chaque plugin ajoute du code. Et plus un site accumule d’extensions, plus il devient difficile de savoir ce qui se passe vraiment.

Le problème vient souvent de là :

• trop de plugins installés ;
• extensions abandonnées ;
• réglages agressifs ;
• scripts externes non maîtrisés ;
• outils gratuits douteux ;
• anciennes intégrations oubliées ;
• plugins qui font tous un peu la même chose.

Un site WordPress sain est souvent un site allégé et propre.

Le bon réflexe consiste à garder uniquement les extensions utiles, maintenues et bien configurées. Le plugin installé “juste pour tester” il y a deux ans qui n’a jamais été désactivé, c’est un peu le carton dans le garage. Un jour, il faut l’ouvrir et trier.

Que faire si ton site est concerné ?

Si un comportement suspect apparaît, il ne faut pas tout supprimer au hasard.

La bonne approche est progressive.

Commence par reproduire le problème :

• Quelle page est concernée ?
• Quel navigateur ?
• Ordinateur ou mobile ?
• Connecté ou non connecté ?
• Avec quelle pop-up ?
• Après quelle action ?

Ensuite, il faut isoler la source :

• tester sans les scripts publicitaires ;
• désactiver les pop-ups en préproduction ;
• vérifier les scripts du header et du footer ;
• contrôler les plugins marketing ;
• regarder les outils d’affiliation ;
• inspecter les personnalisations du thème ;
• tester avec un thème par défaut si nécessaire.

Si le problème vient d’un plugin, il faut chercher un réglage, une mise à jour ou une alternative plus propre.

Si le problème vient d’un script tiers, mieux vaut le retirer ou le remplacer.

Si le problème vient d’un développement sur mesure, la correction doit être faite proprement. Modifier un fichier au hasard sans comprendre peut transformer un bouton retour douteux en site en PLS. Et personne ne veut de ça.

Faut-il rediriger les visiteurs autrement ?

Non, si cela est pour contourner le problème.

Une redirection peut être utile quand elle répond à une vraie logique : une ancienne page remplacée, une URL modifiée, un contenu déplacé, une page fusionnée.

Mais rediriger pour retenir le visiteur ou l’envoyer vers une offre qu’il n’a pas demandée, c’est une mauvaise idée.

Le visiteur doit comprendre ce qui se passe. S’il clique sur retour, il doit revenir en arrière. S’il clique sur un bouton, il doit obtenir ce que le bouton annonce. S’il ferme une pop-up, elle doit rester fermée.

Ce sont des règles simples à appliquer et justement, les règles simples sont souvent celles qui évitent les gros problèmes.

Pourquoi la maintenance WordPress est importante ?

Le back button hijacking montre bien une chose : la sécurité WordPress ne se limite pas aux mises à jour et aux mots de passe.

Un site peut aussi se dégrader à cause de scripts tiers, d’extensions inutiles, de pop-ups trop agressives ou d’intégrations marketing mal contrôlées.

C’est là qu’une maintenance WordPress proactive devient utile. Elle permet de surveiller le site, de vérifier les mises à jour, de contrôler les sauvegardes, de repérer les anomalies et d’éviter que des petits problèmes techniques finissent par dégrader l’expérience utilisateur.

Un site WordPress n’est pas figé après sa mise en ligne. Il vit, il change, il reçoit des contenus, des plugins, des ajustements, des tests. Sans un suivi régulier, même un site propre initialement peut devenir bancal avec le temps. Comme une chaise Ikea montée correctement au départ, puis resserrée avec une cuillère trois ans plus tard.

Et si le site utilise des publicités ou de l’affiliation ?

Les sites qui utilisent des publicités, de l’affiliation ou des widgets externes doivent être encore plus vigilants.

Certains scripts tiers peuvent modifier le comportement du site sans que le propriétaire s’en rende compte immédiatement.

Le comportement peut varier selon :

• le pays ;
• le navigateur ;
• l’appareil ;
• la campagne publicitaire ;
• le profil du visiteur ;
• le moment de la journée ;
• les cookies déjà présents.

C’est donc plus difficile à repérer.

Il faut donc tester le site comme un visiteur anonyme, depuis plusieurs appareils, sans être connecté à WordPress. Les tests depuis l’admin ne suffisent pas, car certains scripts ne s’affichent pas de la même façon aux administrateurs.

Exemple concret de back button hijacking

Imaginons un site WordPress avec une pop-up d’offre spéciale.

Un visiteur arrive depuis Google. Il lit l’article, puis il clique sur retour pour revenir aux résultats de recherche.

Au lieu de revenir à Google, il tombe sur une page intermédiaire avec une offre. Il clique encore sur retour. Une autre étape apparaît. Il clique une troisième fois. Là, il commence à marmonner des choses peu compatibles avec une bonne image de marque.

Même si l’intention était commerciale, le résultat est désastreux. Le visiteur n’a pas demandé ce parcours. Il voulait simplement revenir en arrière.

Une alternative plus saine consiste à afficher une offre claire dans la page, avec un bouton visible, une fermeture honnête et aucun piège de navigation.

Un site doit guider sans forcer. Et franchement, c’est souvent plus efficace.

Comment éviter le problème dès la création d’un site ?

Lors de la création ou de la refonte d’un site, il faut vérifier que chaque outil ajouté a une vraie utilité :

• plugin marketing ;
• pop-up ;
• script de tracking ;
• outil publicitaire ;
• module d’affiliation ;
• constructeur de page ;
• intégration externe.

Chaque élément doit être choisi, configuré et testé.

Un site WordPress professionnel ne doit pas seulement être joli. Il doit être stable, propre, sécurisé et agréable à utiliser. Le visiteur doit sentir qu’il garde le contrôle de son parcours.

C’est aussi ça, un site bien conçu. Il ne doit pas faire de coups tordus dans le dos du navigateur.

Checklist pour vérifier ton site WordPress

Voici une checklist simple pour détecter un éventuel souci :

• tester le bouton retour depuis Google ;
• vérifier les pages importantes ;
• tester sur ordinateur et mobile ;
• tester Chrome, Safari et Firefox ;
• fermer les pop-ups puis cliquer sur retour ;
• tester les pages avec publicités ;
• vérifier les scripts d’affiliation ;
• contrôler les plugins marketing ;
• inspecter les scripts ajoutés dans le header et le footer ;
• rechercher les usages de history.pushState et history.replaceState ;
• désactiver les extensions suspectes en préproduction ;
• supprimer les scripts inutiles ;
• refaire un test après chaque correction.

Cette vérification n’a rien de spectaculaire. Aucunes sirène, pas de terminal noir avec lignes vertes façon film d’espionnage. Juste du bon sens, des tests propres et un peu de méthode.

Et souvent, c’est exactement ce qu’il faut.

En conclusion

Le back button hijacking est un rappel simple, un site WordPress ne doit pas seulement être rapide, beau et bien référencé. Il doit aussi être honnête dans sa navigation.

Le bouton retour appartient au visiteur. Il n’appartient pas au site !

Si ton WordPress utilise beaucoup de plugins, de pop-ups, de scripts publicitaires ou d’outils marketing, une vérification s’impose. Pas besoin de paniquer, mais pas question de laisser un comportement douteux s’installer tranquillement dans un coin.

Un site propre respecte les choix du visiteur. Il peut l’orienter, lui proposer une offre, lui donner envie de rester. Mais il ne le retient pas par la manche.

Dernier point, Google a annoncé traiter le back button hijacking comme une pratique malveillante dans ses politiques antispam à partir du 15 juin 2026.