Pop-up et interstitiels : ce que Google pénalise vraiment

Pop-up et interstitiels : ce que Google pénalise vraiment

Un interstitiel est dit « intrusif » aux yeux de Google lorsqu'il bloque l'accès au contenu principal d'une page mobile juste après un clic depuis les résultats de recherche. Ce n'est pas une interdiction générale des pop-ups : c'est un signal de classement précis, actif depuis janvier 2017, qui ne vise que trois configurations bien définies. Un site peut utiliser des fenêtres modales pour la capture d'e-mails, le consentement aux cookies ou la vérification d'âge sans jamais être concerné, à condition de respecter la manière dont elles apparaissent.

La confusion vient du fait que la plupart des guides mélangent « bonne pratique UX » et « signal algorithmique ». Les deux se recoupent souvent, mais pas toujours : un pop-up de sortie sur desktop peut être agaçant sans jamais toucher ce signal, tandis qu'une bannière de consentement mal codée peut, dans de rares cas, reproduire exactement le comportement que Google cible. Cet article détaille ce qui déclenche réellement la démotion, ce qui en est explicitement exempté, et comment reformuler un pop-up existant pour rester du bon côté de la règle.

Ce que Google appelle un interstitiel intrusif

Le 10 janvier 2017, Google a déployé un signal de classement mobile ciblant les interstitiels qui gênent l'accès au contenu juste après l'arrivée depuis une page de résultats. Techniquement, il ne s'agit pas d'une pénalité manuelle : aucune notification n'apparaît dans le rapport « Actions manuelles » de la Search Console. C'est un facteur intégré à l'algorithme de classement mobile, évalué au moment où Google analyse le rendu de la page pour cette requête et cet appareil. La page concernée voit son classement mobile abaissé pour les recherches qui l'amènent directement sur cette URL ; les autres pages du même site, atteintes par navigation interne, ne sont pas automatiquement affectées par ce même mécanisme.

Le signal se fonde sur le rendu réel de la page, pas sur son code source seul. Google exécute le JavaScript et regarde ce qui s'affiche à l'écran pendant les premières secondes de la visite sur un appareil mobile. Un interstitiel injecté dynamiquement après le chargement initial est donc tout aussi visible pour l'algorithme qu'un bloc présent dès le HTML de départ.

Ce point a une conséquence pratique pour la correction : comme il n'y a pas d'action manuelle, il n'y a rien à « lever » via une demande de réexamen. Une fois la mise en page corrigée et republiée, l'évaluation se met à jour au rythme normal du crawl et du rendu de la page par Google, sans étape administrative supplémentaire.

Les trois formats explicitement visés

Google a listé trois familles de mise en page lors de l'annonce du signal. Elles restent la référence pour savoir si un design pose problème.

Ces trois cas partagent un point commun : l'internaute ne peut pas atteindre le texte qu'il est venu lire sans agir d'abord sur un élément qui n'a rien à voir avec sa recherche initiale. C'est cette friction immédiate, et non la simple présence d'un calque superposé, qui constitue le problème.

  • Un pop-up qui recouvre le contenu principal, affiché immédiatement après l'arrivée ou pendant que l'internaute parcourt la page, et qu'il faut fermer pour continuer.
  • Un interstitiel autonome qu'il faut fermer avant d'accéder au contenu, séparé de la page elle-même, par exemple une page intermédiaire de type « avant de continuer ».
  • Une mise en page où la partie visible à l'écran ressemble à un interstitiel autonome, mais où le contenu réel est en réalité repoussé plus bas dans le code, donnant l'illusion d'une page normale alors que l'expérience immédiate est bloquante.

Les exceptions explicitement reconnues

Google a listé, dans la même annonce, des cas qui restent hors du champ du signal parce qu'ils répondent à une obligation légale ou à un usage jugé raisonnable.

La nuance sur les murs de connexion mérite d'être précisée pour le contenu éditorial payant : Google évalue un paywall différemment d'un login wall pur, et sa tolérance dépend de la manière dont l'accès est structuré, pas uniquement de la présence d'un formulaire de connexion. Un site qui bloque un article entier derrière un mur, sans qu'aucune portion ne soit consultable, ne bénéficie pas automatiquement de l'exemption réservée aux contenus légitimement privés.

  • Les bannières de consentement aux cookies et autres mentions légales imposées par une réglementation, comme le RGPD, l'ePrivacy ou une loi locale sur la confidentialité.
  • Les interstitiels de vérification d'âge, par exemple sur un site vendant de l'alcool ou proposant un contenu réservé aux adultes.
  • Les murs de connexion pour du contenu qui n'est pas destiné à être consulté gratuitement par tout le monde, comme une messagerie privée ou un espace abonné.
  • Les bannières qui occupent une portion raisonnable de l'écran et se ferment facilement, à l'image des bannières natives d'installation d'application proposées par les navigateurs mobiles eux-mêmes.

Quand le signal se déclenche réellement

Trois conditions doivent être réunies en même temps pour que ce signal spécifique s'applique : l'appareil est un mobile, la page est celle sur laquelle l'internaute atterrit directement depuis un résultat de recherche Google, et l'interstitiel apparaît immédiatement ou pendant que la personne consulte le contenu, avant qu'elle ait pu en profiter. Si une seule de ces conditions manque, ce mécanisme précis ne s'applique pas, même si le pop-up reste par ailleurs une mauvaise idée pour l'expérience utilisateur.

Concrètement, cela veut dire que le même pop-up peut être sans risque pour ce signal sur une page profonde atteinte par navigation interne, et problématique sur la page d'accueil ou un article qui capte l'essentiel du trafic de recherche. Cela veut aussi dire que le desktop n'est pas concerné par ce facteur précis : un exit-intent agressif sur ordinateur ne déclenche pas cette démotion mobile, même s'il peut nuire au taux de conversion pour d'autres raisons.

Un piège fréquent consiste à croire que seul le premier chargement compte. En réalité, un interstitiel qui apparaît après quelques secondes de défilement, alors que l'internaute est toujours en train de lire le contenu pour lequel il a cliqué, entre dans le même périmètre que celui qui s'affiche à l'ouverture. Le critère de Google est « pendant que l'utilisateur consulte le contenu », pas seulement « au chargement ».

Ce mécanisme ne fait aucune exception pour les applications monopages ou les pages AMP : ce qui compte est ce qui s'affiche à l'écran pendant les premières secondes, quelle que soit la technologie utilisée pour produire ce rendu. Un interstitiel monté par JavaScript après l'hydratation d'une application React, par exemple, est traité exactement comme un bloc déjà présent dans le HTML statique au chargement.

Comment diagnostiquer une page suspecte

Il n'existe pas de rapport dédié dans Search Console qui liste les pages touchées par ce signal ; ce n'est pas une action manuelle et elle n'apparaît donc jamais dans ce rapport. Le diagnostic est donc manuel et reproduit le parcours réel d'un internaute.

Aucun de ces signes ne constitue une preuve formelle prise isolément — un écart de classement mobile peut avoir d'autres causes, de la vitesse de chargement à l'ergonomie tactile — mais leur combinaison donne une base de diagnostic fiable sans dépendre d'un outil externe.

  • Effectuer la recherche depuis un téléphone, dans les résultats Google réels, puis cliquer sur le lien, plutôt que d'ouvrir l'URL directement dans un nouvel onglet, car certaines implémentations conditionnent l'affichage de l'interstitiel à la présence d'un référent provenant d'un moteur de recherche.
  • Observer ce qui s'affiche avant toute interaction : si un calque recouvre le texte ou le pousse hors champ avant que l'internaute ait pu faire défiler la page, le format correspond à l'un des trois cas ciblés.
  • Répéter le test en simulant un moteur mobile avec l'émulation d'appareil de Chrome DevTools, en vérifiant que l'en-tête référent est bien celui d'un moteur de recherche, puisque certains scripts n'affichent l'interstitiel que dans ce contexte précis.
  • Comparer le classement mobile de l'URL concernée avec son classement desktop sur les mêmes requêtes : un écart net et persistant sur mobile, en l'absence d'autre explication technique, est un indice à vérifier en priorité.

Des alternatives qui respectent la règle

L'objectif n'est pas de renoncer à la capture d'e-mails ou à la promotion d'une offre, mais de changer le moment et la forme de l'interruption.

Pour les interstitiels obligatoires comme le consentement aux cookies, la marge de manœuvre porte surtout sur la sobriété : un bandeau clair, une action de fermeture en un geste, et l'absence d'un second calque qui apparaîtrait juste après avoir fermé le premier.

  • Un bandeau fixe en haut ou en bas de l'écran, qui occupe une portion limitée de la hauteur visible et laisse le contenu principal lisible et défilable en dessous.
  • Un déclenchement conditionné au comportement de lecture : afficher un format compact, qui ne recouvre pas le texte, après un pourcentage de défilement donné ou un temps significatif sur la page, plutôt qu'un calque bloquant à l'arrivée.
  • Un pop-up glissant dans un coin de l'écran, suffisamment petit pour ne jamais masquer le corps du texte, avec un bouton de fermeture visible dès son apparition.
  • Un exit-intent réservé au desktop, où la détection du mouvement de souris vers la barre d'adresse est fiable, plutôt que sur mobile où ce déclencheur n'a pas d'équivalent tactile fiable.
  • Un appel à l'action placé en fin d'article, une fois que l'internaute a déjà consommé le contenu pour lequel il est venu, plutôt qu'avant.

Les erreurs qui aggravent le problème

Certaines pratiques transforment un pop-up par ailleurs anodin en cas typique visé par le signal.

Le point commun à ces erreurs est presque toujours un défaut de test réel sur mobile, dans les conditions exactes d'un clic venu de la recherche, plutôt qu'une intention délibérée de contourner la règle.

  • Déclencher l'interstitiel avant même que le contenu principal n'ait eu le temps de s'afficher, ce qui correspond exactement au premier des trois cas listés par Google.
  • Un bouton de fermeture minuscule, mal contrasté, ou positionné de façon à être confondu avec un autre élément cliquable.
  • Un piège où la fermeture d'un premier calque en déclenche immédiatement un second, ce qui reproduit la même friction sous une forme différente.
  • Une mise en page pensée pour desktop, où le pop-up occupe une fraction raisonnable de l'écran, mais qui bascule en plein écran sur mobile faute d'avoir été testée sur ce format.
  • L'empilement de plusieurs obligations légitimes, comme le consentement, la vérification d'âge et les notifications push, qui, prises ensemble et déclenchées en cascade, recréent un mur bloquant même si chacune, isolément, serait tolérée.

Un cas concret : deux implémentations du même pop-up

Prenons un site e-commerce qui propose une réduction de dix pour cent contre une inscription à sa newsletter. Deux implémentations très proches en apparence donnent pourtant un verdict opposé au regard de ce signal.

Le code JavaScript peut être presque identique entre les deux versions ; ce qui change, ce sont trois paramètres : le déclencheur temporel, la proportion d'écran occupée et la facilité de fermeture. Ce sont précisément les leviers sur lesquels agir quand un audit révèle un pop-up à risque, sans avoir à supprimer l'offre elle-même.

  • Version à risque : le pop-up plein écran s'affiche une demi-seconde après le premier rendu, sans distinction entre un visiteur venu de la recherche et un visiteur qui navigue déjà sur le site depuis dix minutes ; sur mobile, il occupe toute la hauteur visible et le bouton de fermeture est un petit symbole gris sur fond blanc, peu contrasté.
  • Version conforme : le même pop-up ne se déclenche qu'après la moitié du défilement de la page produit, uniquement pour les visiteurs qui n'ont pas déjà vu l'offre lors d'une session précédente ; sur mobile, il prend la forme d'un bandeau occupant environ un tiers de l'écran, avec un bouton de fermeture contrasté et un lien pour revoir l'offre plus tard.

Questions fréquentes

Un bandeau de consentement aux cookies peut-il faire baisser mon classement mobile ?

Non, dans la mesure où il répond à une obligation légale et reste raisonnablement dimensionné. Google exclut explicitement ce cas du signal sur les interstitiels intrusifs, quelle que soit la fréquence à laquelle il s'affiche pour les nouveaux visiteurs.

Ce signal s'applique-t-il aussi sur ordinateur ?

Non, il s'agit d'un facteur de classement propre aux recherches effectuées sur mobile. Un pop-up agressif sur desktop peut nuire à l'expérience et aux conversions, mais il ne déclenche pas cette démotion spécifique.

Un pop-up de newsletter qui apparaît après trente secondes de lecture pose-t-il un problème ?

Cela dépend surtout de sa forme : Google vise aussi les pop-ups qui recouvrent le contenu pendant la lecture, pas seulement à l'arrivée. Un format qui n'occupe pas tout l'écran, ne masque pas le texte et propose une fermeture immédiate et visible limite ce risque.

Comment savoir si mon site a été touché, puisqu'aucune alerte n'apparaît dans Search Console ?

Il faut reproduire manuellement le parcours d'un internaute mobile depuis les résultats de recherche et observer ce qui s'affiche avant toute interaction. Un écart de classement mobile persistant, sans autre explication technique, est un indice complémentaire à vérifier.

Les bannières d'installation d'application sont-elles concernées ?

Les bannières natives proposées par le navigateur lui-même sont exemptées parce qu'elles restent compactes et faciles à fermer. Une bannière personnalisée qui recouvre l'écran entier pour pousser au téléchargement d'une application entre en revanche dans le périmètre visé.

Tous les articles