Google sanctionne enfin le détournement du bouton « Retour » : les éditeurs ont jusqu'au 15 juin
Google sanctionne enfin le détournement du bouton « Retour » : les propriétaires de sites ont jusqu'au 15 juin pour nettoyer leur code sous peine de déclassement,
indépendamment de la provenance du code qui peut être issu d'une bibliothèque tierce
Depuis des années, des sites web de toutes tailles manipulent discrètement l'historique de navigation pour empêcher les internautes de partir ou diffuser de la publicité. Google a nommé officiellement cette pratique le back button hijacking et lui accole une sanction concrète : déclassement ou action manuelle dans les résultats de recherche. Les propriétaires de sites ont jusqu'au 15 juin 2026 pour mettre de l'ordre dans leur code. Derrière cette annonce technique se cache un bras de fer plus large sur qui contrôle vraiment l'expérience du navigateur.
Google a annoncé l'élargissement de ses politiques anti-spam afin de viser explicitement le back button hijacking, désormais classifié comme violation de la catégorie « pratiques malveillantes ». Le principe est simple à comprendre, et c'est précisément ce qui le rend exaspérant : lorsqu'un internaute clique sur le bouton retour, son attente est claire ; retourner là d'où il vient. Le détournement du bouton retour consiste à interférer avec la navigation du navigateur pour empêcher l'utilisateur de revenir à la page précédente.
Le mécanisme technique sous-jacent n'a rien d'exotique. Il repose généralement sur l'API JavaScript history.pushState(), qui permet d'ajouter silencieusement des entrées dans la pile d'historique du navigateur. Imaginez cet historique comme une pile de cartes : normalement, naviguer vers un article en ajoute une seule. Avec le détournement, le site en insère cinq supplémentaires, forçant l'utilisateur à appuyer cinq fois sur retour avant d'atteindre sa destination initiale.
L'objectif est invariablement le même : allonger artificiellement la durée de session ou déclencher une impression publicitaire supplémentaire auprès d'un visiteur déjà en train de partir. Ce que Google qualifie désormais de spam, l'industrie publicitaire l'appelait encore récemment « optimisation de l'engagement ».
LinkedIn, Reddit, les régies publicitaires : les coupables identifiés par la communauté
L'annonce a immédiatement provoqué un déferlement de témoignages sur les sites spécialisés, où les commentaires ce sont comptés par centaines en quelques heures. Les utilisateurs n'ont pas tardé à nommer les récidivistes.
Un développeur a détaillé avec précision le fonctionnement de LinkedIn : lorsqu'un utilisateur accède à un lien partagé, la plateforme utilise location.replace() pour substituer silencieusement l'URL courante par celle de la page d'accueil, une opération qui n'ajoute pas d'entrée dans l'historique, puis pousse manuellement l'URL originale dans la pile. Résultat : l'utilisateur croit revenir en arrière, mais se retrouve sur le fil LinkedIn, où son flux tente de le retenir.
Reddit est également cité, notamment sa version moderne qui se comporte comme une application mobile. Sur la version récente du site, le bouton retour ne fonctionne tout simplement plus selon de nombreux utilisateurs. La liste ne s'arrête pas aux réseaux sociaux : plusieurs commentateurs signalent le portail Azure de Microsoft comme un contrevenant notable, où la navigation arrière produit des résultats imprévisibles, souvent attribués à l'usage de modales plein écran mal gérées.
Un intervenant note que certains sites d'actualités affichent une publicité plein écran dès que l'utilisateur tente de quitter la page, une variante du détournement encore plus agressive. Ces comportements, longtemps tolérés faute de sanction formelle, sont précisément ceux que Google entend cibler.
L'arme : le déclassement SEO, y compris pour les bibliothèques tierces
La sanction annoncée par Google est double. Les pages pratiquant le détournement du bouton retour s'exposent à des actions manuelles de spam ou à des pénalités algorithmiques automatisées, susceptibles d'affecter leur visibilité dans les résultats de recherche.
Mais c'est la question de la responsabilité qui constitue le véritable coup de théâtre de l'annonce. Google reconnaît explicitement que certains cas de détournement ne proviennent pas du code du propriétaire du site, mais de bibliothèques incluses ou de plateformes publicitaires tierces, tout en précisant que la responsabilité incombe néanmoins au site.
Ce point a des implications considérables pour les éditeurs qui monétisent leur contenu via des régies programmatiques. Un widget qui était parfaitement propre lors de son installation peut avoir intégré des manipulations d'historique dans une mise à jour ultérieure, sans que le propriétaire du site en soit informé. La mécanique de la chaîne publicitaire programmatique, opaque par construction, devient ainsi un vecteur de risque SEO direct.
En décembre 2024, Google avait déjà commencé à lier les pénalités manuelles de recherche à l'éligibilité aux annonces Google Ads. Une action manuelle pour détournement du bouton retour pourrait donc également affecter l'accès aux campagnes payantes. Pour les éditeurs dépendants à la fois du SEO organique et de la publicité programmatique, l'effet de levier est redoutable.
La frontière entre usage légitime et abus : le débat des SPA
Tous les usages de l'API History ne sont pas frauduleux, et c'est là que le débat technique devient plus subtil. Les applications monopages (SPA), les diaporamas, le défilement infini ou les boîtes de dialogue modales utilisent légitimement pushState() pour mettre à jour l'URL au fil de la navigation sans pour autant tromper l'utilisateur sur sa position ou l'empêcher de partir.
La frontière, selon Google, tient à l'intention et à l'effet : manipuler l'historique pour améliorer la cohérence de navigation d'une application est acceptable ; l'utiliser pour piéger un utilisateur désirant quitter le site ne l'est pas. Mais cette distinction, intuitive pour un développeur de bonne foi, est nettement moins évidente à détecter automatiquement par un moteur d'indexation.
Sur Hacker News, plusieurs développeurs soulèvent une tension réelle : certains estiment que le bouton retour du navigateur devrait toujours permettre de quitter une application web, quelle que soit sa complexité ; d'autres défendent l'idée qu'une SPA bien construite doit pouvoir gérer sa propre navigation interne via l'historique, sans quoi le lien direct vers un état de l'application perd tout son sens. Google n'a pas tranché ce débat architectural dans son annonce, ce qui laisse une zone grise pour les développeurs front-end qui implémentent la navigation dans des interfaces riches.
Des experts SEO recommandent de traiter ce chantier comme un projet transversal, et non comme un ticket de correctif ponctuel : supprimer le code incriminé sans vérifier les flux adjacents peut casser la navigation des modales, des filtres de recherche ou des formulaires intégrant plusieurs étapes.
Un signal plus large : Google reprend la main sur l'expérience post-clic
Cette annonce ne surgit pas dans le vide. Elle s'inscrit dans une séquence cohérente d'extensions des politiques anti-spam de Google, toutes ciblant ce qui se passe après le clic depuis les résultats de recherche. Au cours des deux dernières années, Google a successivement ajouté l'abus de réputation de site, l'abus de contenu à grande échelle, et désormais le détournement du bouton retour comme violations nommées. Shortlist Le dénominateur commun : des comportements que les propriétaires de sites ont tendance à sous-traiter à des tiers (régies publicitaires, widgets d'engagement, outils A/B testing) et à oublier ensuite.
Pour Google, ces comportements sont mesurables : les signaux Chrome et Android WebView, les schémas de rebond, les clics courts et les rapports utilisateurs permettent de corréler « les utilisateurs essaient de partir, mais n'y arrivent pas ». L'entreprise dispose d'une vue unique sur ces données comportementales à l'échelle du web, ce qui lui donne un avantage considérable pour identifier les contrevenants, même sophistiqués.
La question qui divise la communauté est celle de l'applicabilité aux grands acteurs. Sur HN, un utilisateur demande directement si Reddit sera concerné, au vu de sa taille. Un autre note que LinkedIn, dont la dépendance au référencement naturel est structurellement faible (la plateforme bénéficiant d'un trafic direct massif), n'aura guère d'incitation à se conformer à la nouvelle règle. La politique de Google s'avère ainsi plus dissuasive pour les éditeurs de taille moyenne, dont la visibilité dépend directement du SEO, que pour les plateformes dominantes qui peuvent se permettre d'ignorer les injonctions du moteur de recherche.
Délai de grâce et procédure de recours
Google a choisi de publier sa politique deux mois avant l'entrée en vigueur de la sanction, fixée au 15 juin 2026, afin de donner aux propriétaires de sites le temps d'effectuer les modifications nécessaires. Les contrevenants qui auront corrigé le problème avant cette date pourront soumettre une demande de réexamen via la Search Console. Pour ceux qui découvriront le problème après une pénalité manuelle, le délai de traitement peut s'étaler sur plusieurs semaines.
Commencez par le test le plus simple*: accédez à votre site en cliquant sur un résultat de recherche Google, puis revenez en arrière. Vous devriez arriver immédiatement sur la page de résultats. Si ce n’est pas le cas, un élément interfère et vous devez l’identifier.
Voici les schémas techniques les plus susceptibles d’être à l’origine du problème*:
- Utilisation de history.pushState ou history.replaceState au chargement de la page sans justification UX claire ;
- Superpositions d’intention de sortie interceptant les événements popstate pour afficher des fenêtres contextuelles avant que l’utilisateur ne quitte la page ;
- Scripts publicitaires programmatiques insérant des pages interstitielles ou des chaînes de redirection ;
- Pages de destination d’affiliation ou widgets de recommandation de contenu modifiant l’historique de navigation.
Une fois la source identifiée, supprimez-la ou reconfigurez-la. Si elle provient d’un fournisseur tiers, demandez-lui directement si son implémentation modifie l’historique du navigateur. Certains fournisseurs proposent une option de configuration pour la désactiver. D’autres non, et vous devrez évaluer si l’outil présente le risque encouru.
Source : Google
Et vous ?
LinkedIn, Reddit ou d'autres grandes plateformes vont-elles réellement se conformer à cette politique, ou leur indépendance vis-à-vis du SEO leur permet-elle de l'ignorer impunément ?
Répondre avec citation
Envoyé par BugFactory
Partager