SEO : Google sanctionnera dès le 15 juin les sites qui détournent le bouton « Retour » du navigateur

Google a tranché : le détournement du bouton « Retour » du navigateur devient officiellement une pratique sanctionnable. Les propriétaires de sites ont jusqu'au 15 juin 2026 pour nettoyer leur code, faute de quoi ils s'exposent à un déclassement dans les résultats de recherche — et ce, même si le code fautif provient d'une bibliothèque tierce qu'ils n'ont pas écrite eux-mêmes.

Le « back button hijacking », c'est quoi exactement ?

Derrière cette expression, une pratique très répandue : empêcher l'internaute de revenir à la page précédente en manipulant l'historique du navigateur. L'objectif est toujours le même — prolonger artificiellement la session, forcer une impression publicitaire supplémentaire, ou rediriger l'utilisateur vers une page conçue pour le retenir.

Techniquement, deux API JavaScript sont en première ligne. D'un côté, history.pushState() permet d'insérer de fausses entrées dans la pile de navigation du navigateur : l'utilisateur clique une fois sur « Retour » et se retrouve… toujours sur votre site, parce qu'une entrée fantôme a été empilée. De l'autre, location.replace() substitue discrètement l'URL, donnant l'illusion d'une navigation arrière qui n'en est pas une.

La sanction côté SEO

Google classe désormais ces comportements au même niveau que les pratiques spam classiques. Deux types de sanctions peuvent tomber :

• une action manuelle, notifiée dans la Search Console, avec un impact immédiat sur la visibilité ;
• un déclassement algorithmique, plus insidieux, qui affecte le positionnement sans alerte explicite.

Plusieurs gros acteurs ont été publiquement pointés par les utilisateurs ces derniers mois : LinkedIn, Reddit, Microsoft Azure et certains médias d'actualité pratiquaient — au moins ponctuellement — ce genre de manipulation. On imagine mal ces plateformes être déclassées du jour au lendemain ; la vraie question, c'est l'effet de ruissellement sur les plus petits sites.

Le piège du code tiers

Le point qui tend les éditeurs, c'est la responsabilité. Google est très clair : vous êtes responsable du comportement de votre page, même si le code problématique vient d'une régie pub, d'un widget ou d'une bibliothèque analytique. Autrement dit, une mise à jour d'un SDK tiers peut, du jour au lendemain, activer un comportement de hijacking sans que le webmaster en soit informé — et c'est le site qui trinque.

C'est particulièrement douloureux pour les sites monétisés en programmatique : une régie pousse un correctif qui modifie la gestion de la navigation, et la sanction Google arrive quelques semaines plus tard, sans bruit.

Ce qu'il faut faire d'ici le 15 juin

Quelques actions à mener sans tarder :

• Auditer les appels à history.pushState() et location.replace() dans votre code et dans les scripts tiers (publicités, widgets sociaux, chatbots).
• Tester manuellement le bouton Retour sur les pages clés, y compris après interaction avec les popups et les lecteurs vidéo intégrés.
• Mettre en place une CSP stricte pour limiter ce que les scripts externes peuvent charger et exécuter.
• Demander des engagements contractuels à vos régies : absence de manipulation d'historique, notification en cas de changement majeur.
• Surveiller la Search Console au cours des prochaines semaines, notamment la section « Actions manuelles ».

Mon retour

Cette annonce, au-delà de l'aspect SEO, consacre une évidence : on ne peut plus se permettre de charger un script tiers les yeux fermés. J'ai tendance à voir ça d'un bon œil — ça force les éditeurs à reprendre la main sur ce qui s'exécute dans les pages, et ça rend la vie plus difficile aux régies qui jouent sur le dos de l'utilisateur. Mais le délai de deux mois est court, surtout pour les sites qui dépendent de stacks publicitaires complexes où le changement d'une dépendance se négocie plus qu'il ne se décide.