Back button hijacking : la règle anti-spam d'avril 2026 qui vise vos scripts pub

Qu'est-ce que le back button hijacking selon Google ?

Google le définit ainsi dans ses règles anti-spam : le site « interfère avec la navigation de l'utilisateur en manipulant l'historique du navigateur ou d'autres fonctionnalités », ce qui l'empêche d'utiliser le bouton retour pour revenir immédiatement à la page d'où il venait^[2]. La pratique est rangée dans la catégorie des pratiques malveillantes.

Dans son billet du 13 avril, Google décrit les symptômes : l'internaute atterrit sur des pages qu'il n'a jamais visitées, se voit proposer des recommandations ou des publicités non sollicitées, ou se retrouve bloqué dans sa navigation^[1]. Le cas typique : vous arrivez depuis Google, vous appuyez sur retour, et au lieu de retrouver les résultats, vous tombez sur une page d'articles « qui pourraient vous intéresser ».

Quelles sanctions depuis le 15 juin 2026 ?

Google a publié la règle deux mois avant de l'appliquer, ce qui est rare et laissait le temps de corriger. Depuis le 15 juin 2026, les pages concernées peuvent faire l'objet « d'actions manuelles pour spam ou de déclassements automatiques »^[1]. Les deux n'ont pas la même visibilité pour vous.

Une action manuelle apparaît dans la Search Console, dans le rapport consacré, et se lève après correction via une demande de réexamen^[1]. Un déclassement automatique, lui, ne fait l'objet d'aucune notification : vous constatez seulement une baisse de visibilité, que vous risquez d'attribuer à tort à une mise à jour d'algorithme. C'est le scénario le plus dangereux pour une PME qui ne surveille pas ses scripts.

Pourquoi votre site peut être concerné sans le savoir

C'est la phrase la plus importante du billet de Google : le détournement « peut provenir des bibliothèques incluses par le site ou de sa plateforme publicitaire »^[1]. Google demande donc aux propriétaires de vérifier leur implémentation et de retirer ou désactiver le code, les imports ou les réglages en cause.

Dans les audits que je réalise, les suspects habituels sont toujours les mêmes : régies publicitaires qui ajoutent des modules de « recirculation », widgets de contenus sponsorisés, extensions WordPress de fenêtres de sortie, applications Shopify de rétention, scripts de test A/B mal configurés. Aucun de ces outils n'est interdit en soi. C'est leur comportement sur le bouton retour qui pose problème.

Le piège est que ce comportement apparaît souvent uniquement sur mobile, ou uniquement pour les visiteurs venant d'un moteur de recherche, ou seulement une fois sur deux. Un test rapide depuis votre ordinateur, en arrivant directement sur votre site, ne le révélera pas.

Les signalements de spam peuvent-ils déclencher une action manuelle ?

Oui, depuis avril 2026. Le 14 avril, Google a modifié sa documentation pour indiquer qu'il « peut désormais utiliser les signalements de spam pour prendre des actions manuelles », puis a précisé le 23 avril quand et pourquoi, en réponse aux réactions suscitées^[3]. Auparavant, ces signalements servaient officiellement à améliorer les systèmes de détection.

La page de signalement ajoute un détail important : si une action manuelle est prise, le texte du signalement est transmis au propriétaire du site pour qu'il comprenne le contexte^[4]. Google refuse aussi les signalements contenant des données personnelles. Concrètement, un concurrent ou un internaute agacé peut désormais signaler votre site, et ce signalement peut aboutir à une sanction s'il décrit une violation réelle.

Ma lecture : cela ne transforme pas la Search Console en outil de dénonciation entre concurrents, car Google vérifie la violation avant d'agir. Mais une pratique gênante pour les visiteurs, comme le détournement du bouton retour, est exactement le genre de chose que les gens signalent. Les deux annonces d'avril vont ensemble.

Ce que j'en pense

Je trouve cette règle saine. Le détournement du bouton retour améliore artificiellement des indicateurs (pages vues, impressions publicitaires) au détriment de l'expérience. Un visiteur piégé ne revient pas, et il retient la marque pour de mauvaises raisons. Pour un site de PME, le gain publicitaire est presque toujours dérisoire par rapport au risque.

Le vrai sujet, c'est la gouvernance des scripts. Beaucoup de sites que j'audite chargent dix, quinze, vingt scripts tiers dont personne ne sait plus qui les a ajoutés. Cette règle est une bonne occasion de faire l'inventaire. Un site léger, rendu côté serveur, avec peu de dépendances, comme ceux construits sur Éclair CMS, réduit mécaniquement ce risque. La mise à jour anti-spam de juin, que je détaille dans ma checklist technique de juin 2026, a montré que Google ne relâche pas la pression^[5].

Que faire concrètement ?

• Faites le test dans des conditions réelles : recherche Google sur smartphone, clic sur votre résultat, bouton retour. Répétez sur une page d'article, une fiche produit et la page d'accueil.
• Demandez à votre régie publicitaire, par écrit, si ses scripts modifient l'historique du navigateur, et désactivez les modules de recirculation en cas de doute.
• Sur WordPress ou Shopify, examinez les extensions de pop-up de sortie et de rétention ajoutées ces dernières années.
• Consultez le rapport Actions manuelles de la Search Console, et en cas de sanction, corrigez puis déposez une demande de réexamen.

Un crawler ne suffit pas à détecter ce problème, car il dépend du comportement réel dans un navigateur. En revanche, notre crawler Arachnide vous aide à inventorier les scripts chargés sur chaque page, ce qui est la première étape.

Sources

1. Google Search Central Blog, nouvelle règle anti-spam sur le back button hijacking (13 avril 2026)
2. Google Search Central, règles anti-spam de la recherche Google (pratiques malveillantes)
3. Google Search Central, journal des mises à jour de la documentation (entrées des 14 et 23 avril 2026)
4. Google Search Central, signaler un problème de qualité ou de spam
5. Google Search Status Dashboard, mise à jour anti-spam de juin 2026