Contenu en onglets et accordéons : Google l'indexe-t-il ?

Oui, dans la grande majorité des cas : Google indexe le contenu placé dans un onglet, un accordéon ou un bloc « lire la suite » exactement comme s'il était visible par défaut. Cette réponse aurait été différente il y a quelques années, quand le moteur analysait surtout la version desktop d'un site et traitait le contenu masqué au premier chargement comme secondaire. Le passage à l'indexation mobile-first a changé la donne, parce que les interfaces mobiles reposent presque toutes sur ce type de divulgation progressive pour tenir sur un petit écran.

La vraie question n'est donc plus « est-ce indexé ? » mais « par quel mécanisme ce texte arrive-t-il jusqu'au moteur, et cela change-t-il quelque chose à son traitement ? ». La réponse dépend entièrement de la façon dont l'onglet ou l'accordéon est construit techniquement, pas de son apparence visuelle. C'est cette distinction, invisible pour un utilisateur mais décisive pour l'indexation, que cet article détaille : le rôle du rendu, les schémas d'implémentation sûrs et risqués, et les situations où masquer du contenu finit par poser un vrai problème.

Le tournant de l'indexation mobile-first

Avant l'annonce du passage généralisé à l'indexation mobile-first, Google construisait son index principalement à partir de la version desktop d'une page. Sur desktop, les designers avaient moins besoin de replier du contenu : l'espace disponible permettait d'afficher un texte complet sans onglets ni accordéons. Ces mécanismes existaient déjà, mais surtout sur mobile, où l'écran impose de faire des choix. Cette asymétrie a nourri une inquiétude légitime chez les référenceurs : si Google indexe la version desktop et que celle-ci diffère de la version mobile pliée, le contenu replié pourrait être compté différemment, voire ignoré.

Le déploiement de l'indexation mobile-first, entamé en 2018 et généralisé à la quasi-totalité des sites quelques années plus tard, a inversé la logique : c'est désormais la version mobile qui sert de référence pour l'indexation et le classement, sauf exception rare. Google a précisé à plusieurs reprises, par la voix de ses porte-parole officiels, que le contenu affiché uniquement après une interaction sur cette version mobile est traité au même niveau que le contenu visible d'emblée, dès lors qu'il est présent dans le code au moment du rendu de la page. L'ancienne réserve implicite liée au contenu masqué n'a donc plus de fondement technique dans son principe général.

Ce que Googlebot voit réellement au moment du rendu

Googlebot n'analyse pas seulement le code source brut envoyé par le serveur. Depuis plusieurs années, il utilise un moteur de rendu basé sur une version récente de Chromium pour exécuter le JavaScript de la page, construire l'arbre DOM final, puis indexer le texte qui s'y trouve. Ce qui compte pour l'indexation n'est donc pas ce qui s'affiche à l'écran, mais ce qui existe dans cette structure après exécution des scripts. Un texte masqué par une règle CSS comme display: none, visibility: hidden ou une hauteur ramenée à zéro avec overflow: hidden reste parfaitement lisible par le moteur, parce que ces propriétés n'empêchent en rien la présence du texte dans le document.

La distinction qui compte réellement se situe ailleurs, entre trois cas concrets. Premier cas : le texte est présent dans le HTML initial envoyé par le serveur, puis masqué par une classe CSS que le JavaScript retire au clic — il est indexé sans difficulté. Deuxième cas : le texte est injecté dans le DOM par un script au chargement de la page, avant toute interaction de l'utilisateur, puis masqué de la même façon — il est également capturé, puisque Google attend l'exécution du JavaScript avant de figer son instantané du DOM. Troisième cas, le seul réellement problématique : le texte n'existe nulle part dans le DOM avant que l'utilisateur ne clique, parce qu'il est récupéré par une requête réseau déclenchée exclusivement par cet événement. Googlebot ne simule pas systématiquement chaque clic possible sur une page, donc ce contenu risque de rester invisible pour l'indexation.

Onglets, accordéons et « lire la suite » : trois logiques, trois résultats

Les onglets d'une fiche produit ou d'une page de comparaison suivent en général un schéma simple : tous les panneaux existent dans le DOM dès le chargement, un seul est visible et les autres sont masqués, un gestionnaire d'événement se contentant de permuter cette propriété au clic. Ce schéma est sûr : chaque panneau, y compris ceux qui ne sont pas visibles au premier affichage, reste disponible pour l'indexation.

Les accordéons, très employés pour les foires aux questions ou les listes de caractéristiques, reposent souvent sur le même principe, avec une animation de hauteur en CSS plutôt qu'un simple changement d'affichage. Le piège apparaît avec certaines bibliothèques d'interface, notamment dans les frameworks JavaScript modernes, qui démontent complètement le contenu du panneau fermé au lieu de le masquer visuellement — une écriture du type « si ouvert alors créer le composant » plutôt que « masquer le composant par CSS ». Si le panneau reste fermé par défaut et qu'aucune interaction ne se produit avant que Google capture son instantané, ce texte n'existe tout simplement pas dans le DOM analysé, même s'il est parfaitement légitime et pertinent pour l'utilisateur.

Les blocs « lire la suite » posent la même alternative. Une troncature purement visuelle, obtenue par exemple avec la propriété CSS line-clamp sur un paragraphe déjà complet dans le HTML, laisse le texte intégral disponible pour l'indexation dès le premier chargement. À l'inverse, certains composants ne chargent le texte complémentaire que via un appel à une API déclenché par le clic sur « lire la suite » — dans ce cas, le paragraphe additionnel n'est ni pré-rendu ni présent avant l'interaction, et suit le même risque que l'accordéon démonté évoqué plus haut.

• Sûr : le contenu existe dans le HTML initial ou est injecté au chargement de la page, avant toute interaction, puis simplement masqué par CSS.
• Risqué : le contenu n'apparaît dans le DOM qu'après un clic, via une requête réseau déclenchée par cet événement précis.
• Risqué : le composant démonte entièrement l'élément du DOM lorsqu'il est fermé, au lieu de le rendre invisible par une propriété CSS.

Indexé ne veut pas dire pondéré à l'identique dans tous les cas

L'indexation et le classement sont deux étapes distinctes, et la confusion entre les deux entretient une partie du doute autour des onglets et accordéons. Être indexé signifie que Google connaît l'existence du texte et peut le faire correspondre à une requête. Cela ne dit rien, en soi, de la façon dont ce texte pèse dans un calcul de pertinence face à une page concurrente qui présente une information équivalente sans la replier.

Sur le principe général du classement, Google affirme ne pas appliquer de dévaluation liée au seul fait qu'un contenu soit masqué par défaut sur mobile. Mais deux mécanismes indépendants de toute pénalité peuvent, dans les faits, avantager le contenu visible. D'une part, les systèmes d'extraction de passages, utilisés notamment pour les extraits optimisés, sélectionnent un fragment de texte censé répondre directement à une requête ; un texte présenté d'emblée à l'utilisateur, sans étape intermédiaire, correspond plus naturellement au type de réponse que ces systèmes cherchent à extraire. D'autre part, un contenu qui n'est jamais consulté parce qu'il reste plié dans l'expérience réelle des visiteurs produit des signaux d'usage différents de ceux d'un contenu lu directement, sans que cela constitue une règle explicite quelconque.

En pratique, cela signifie qu'un onglet ou un accordéon n'est pas un handicap pour l'indexation d'un texte, mais que le contenu qui répond le plus directement à l'intention de recherche principale d'une page gagne à rester visible sans interaction, si l'objectif inclut l'obtention de résultats enrichis dans les pages de résultats.

Quand masquer du contenu devient réellement un problème

Le premier cas de figure concerne l'écart entre ce qui est montré et ce qui est réellement destiné à l'utilisateur. Si le contenu placé dans un panneau masqué diffère substantiellement de ce que verrait un visiteur normal, par exemple un bloc de texte truffé de mots-clés sans intérêt éditorial ajouté uniquement pour être lu par le moteur et jamais consulté volontairement, cette pratique s'apparente à du camouflage de contenu, une violation documentée des règles de Google contre le spam, sanctionnable par une action manuelle. Le problème ici ne vient pas de la présence d'un accordéon, mais de la divergence d'intention entre ce qui est écrit et ce qui est montré.

Le deuxième cas est plus fréquent et purement technique : bloquer, via robots.txt, l'accès aux fichiers JavaScript ou CSS qui construisent l'interface à onglets. Si Googlebot ne peut pas récupérer ces ressources, il ne peut pas non plus exécuter le script qui construit le DOM final, et une page dont le contenu réel dépend entièrement de ce mécanisme peut alors être indexée presque vide, malgré un texte complet destiné aux visiteurs qui, eux, chargent la page dans un navigateur classique.

Le troisième cas touche la résilience générale du rendu : une page dont la totalité du contenu utile dépend d'une exécution JavaScript sans accroc s'expose à un instantané appauvri chaque fois qu'une ressource est temporairement indisponible, qu'un script lève une erreur, ou que le budget de rendu alloué à la page est dépassé. Un onglet ou un accordéon isolé ne pose pas ce risque à lui seul, mais une page qui replie l'essentiel de son texte derrière plusieurs couches d'interaction cumule ce risque à chaque couche supplémentaire.

Le quatrième cas concerne la différenciation entre pages plutôt que l'indexation elle-même : lorsque le contenu véritablement unique d'une page se limite au résumé visible, et que les onglets répètent le même bloc générique, livraison, garantie ou politique de retour, sur des centaines de fiches produit, la part de texte réellement distinctive par page devient très faible, même si l'ensemble reste bien indexé dans chaque cas pris isolément.

Vérifier ce que Google voit sur votre propre page

La méthode la plus directe passe par l'outil d'inspection d'URL de Search Console. Après avoir testé l'URL en direct, l'onglet consacré au HTML affiche le code tel qu'il existe après exécution du JavaScript par le moteur de rendu de Google. Une recherche avec Ctrl+F du texte contenu dans un onglet ou un accordéon fermé permet de confirmer directement sa présence ou son absence dans le DOM analysé, ce qui règle la question sans ambiguïté pour la page testée, sans avoir à deviner ou à supposer quoi que ce soit.

La capture d'écran fournie par le même outil complète la vérification : elle montre comment Google a effectivement affiché la page au moment du rendu, ce qui permet de repérer un panneau resté vide ou un script qui n'a pas pu s'exécuter correctement. Un contrôle rapide complémentaire, côté navigateur, consiste à afficher le code source de la page et à y chercher le même texte : s'il y figure déjà avant toute exécution de script, sa présence dans le DOM final est garantie quel que soit le comportement du moteur de rendu ce jour-là.

Un dernier point mérite d'être vérifié systématiquement : que le fichier robots.txt du site n'exclue aucun répertoire contenant les scripts ou les feuilles de style nécessaires à la construction de l'interface à onglets, ce qui rendrait ce contrôle optimiste et sans valeur réelle en production.

Bonnes pratiques d'implémentation

Quelques choix de conception limitent le risque à la source plutôt que de le corriger après coup, une fois le trafic déjà perdu.

• Privilégier les balises HTML natives <details> et <summary> pour les accordéons simples : le contenu reste dans le DOM indépendamment du JavaScript, et l'accessibilité est gérée nativement par le navigateur.
• Dans les frameworks JavaScript, garder chaque panneau monté dans le DOM en permanence et gérer sa visibilité par une classe CSS, plutôt que de le créer ou de le détruire selon l'état ouvert ou fermé.
• Ne jamais faire dépendre le texte principal d'une page d'une requête réseau déclenchée uniquement par un clic ; le pré-rendre côté serveur, puis le masquer si nécessaire seulement après coup.
• Garder un extrait clair et visible par défaut pour tout passage susceptible d'alimenter un extrait optimisé, même si le détail complet vit dans un onglet secondaire.
• Tester chaque nouveau composant d'onglet ou d'accordéon dans l'outil d'inspection d'URL avant la mise en production, pas après avoir constaté un problème d'indexation sur le site en ligne.