Bouton « Lire la suite », onglets, accordéons, FAQ dépliables, texte replié sous une fiche produit : une bonne partie du contenu d'un site n'est pas visible au premier affichage. La question revient dans presque tous les audits : Google lit-il ce texte, et lui donne-t-il le même poids qu'un paragraphe affiché en clair ?
La réponse a changé avec le temps. Les expériences des années 2016-2017 concluaient à une dévaluation du texte caché. Depuis le passage à l'indexation mobile-first, la position officielle de Google est différente. Cet article fait le tri entre ce qui est toléré, ce qui est sanctionné et ce qui, sans être interdit, échappe simplement au moteur.
« Contenu masqué » recouvre trois situations très différentes
Le traitement par Google dépend de la technique employée et de l'intention.
| Situation | Exemple | Traitement par Google |
|---|---|---|
| Contenu présent dans le HTML, replié par l'interface | Onglets, accordéons, « Lire la suite », <details>, curseur de slides |
Indexé. Autorisé par les règles anti-spam, à condition que le contenu soit destiné aux utilisateurs. |
| Contenu absent du HTML tant que l'utilisateur n'agit pas | Texte chargé en JavaScript au clic ou au défilement, appel API déclenché par un bouton | Non indexé, car Google n'interagit pas avec la page. Ce n'est pas une sanction, c'est une absence. |
| Texte dissimulé pour manipuler le classement | Texte blanc sur fond blanc, police à 0, bloc positionné hors écran, contenu différent servi au robot (cloaking) | Violation des règles anti-spam, exposée à une action manuelle ou à un déclassement algorithmique. |
La plupart des inquiétudes concernent la première ligne. Le vrai problème se trouve le plus souvent dans la deuxième.
Ce que disent les règles anti-spam de Google
La page des règles concernant le spam de Google Search Central (version mise à jour le 28 août 2026) définit le « texte et liens cachés » comme le fait de placer du contenu sur une page uniquement pour manipuler les moteurs, sans qu'il soit facilement lisible par un visiteur. Les exemples cités sont sans ambiguïté : texte blanc sur fond blanc, texte placé derrière une image, texte positionné hors écran par CSS, taille de police ou opacité à zéro, lien posé sur un seul caractère.
La même page liste explicitement ce qui ne constitue pas une violation :
- les accordéons et onglets qui affichent ou masquent un contenu supplémentaire ;
- les diaporamas ou curseurs qui font défiler des images ou des paragraphes ;
- les infobulles et textes affichés lors d'une interaction ;
- le texte réservé aux lecteurs d'écran, à des fins d'accessibilité.
Le cloaking relève d'une autre règle : présenter un contenu différent aux utilisateurs et aux moteurs pour manipuler le classement. Google précise qu'un paywall n'est pas du cloaking dès lors que le moteur accède au contenu complet et que le balisage adapté est en place.
Le critère central est donc l'intention. Un accordéon qui organise une FAQ sert le lecteur. Un bloc display:none rempli de variantes de mots-clés ne sert que le robot. Même propriété CSS, jugement opposé.
Onglets et accordéons : la position de Google a changé avec le mobile-first
Ce que montraient les tests de 2017
L'agence britannique Reboot Online a publié en mai 2017 une expérience de long terme sur le texte caché : 20 domaines neufs répartis en quatre groupes de cinq (texte visible, texte masqué par CSS, texte masqué par JavaScript, texte dans un textarea), suivis pendant environ six mois sur Google, Bing et Yahoo. Sur Google, les pages au texte entièrement visible se classaient nettement mieux que celles dont le texte était caché par CSS ou JavaScript ; Bing et Yahoo ne montraient pas de différence stable. Cette étude, relayée par Moz, a nourri la croyance encore répandue selon laquelle « Google dévalue le contenu caché ». Elle reste un instantané de 2017, quand l'index reposait sur la version desktop des pages.
Ce que Google dit depuis l'indexation mobile-first
Google a commencé l'indexation mobile-first en 2016 et a annoncé son achèvement dans un billet officiel du 31 octobre 2023 : tous les sites qui fonctionnent sur mobile sont désormais explorés en priorité avec le robot smartphone. Interrogé en 2020 sur la dévaluation du contenu placé dans des onglets ou des accordéons dans ce contexte, John Mueller (Google) a répondu que non : pour les pages mobiles, tout ce qui figure dans le HTML est pris en compte, y compris ce qui peut devenir visible après une interaction (compte rendu Search Engine Journal, avril 2020).
La documentation Mobile-first indexing best practices le formalise : vous pouvez adopter un design différent sur mobile, par exemple en déplaçant du contenu dans des accordéons ou des onglets, à condition que le contenu reste équivalent à celui de la version desktop. J'ai détaillé les implémentations recommandées dans un article dédié aux accordéons, onglets et infinite scroll compatibles avec le SEO.
Une nuance : indexé ne signifie pas forcément pesé comme un titre ou un premier paragraphe. Google ne publie pas de pondération. La règle de prudence reste simple : ce qui répond à l'intention de recherche principale s'affiche en clair, ce qui approfondit peut se replier.
Le vrai risque : le contenu qui n'est pas dans le HTML
La confusion vient de ce que « masqué par CSS » et « chargé par JavaScript au clic » sont mis dans le même sac. Google exécute le JavaScript et indexe le HTML rendu. Mais sa documentation sur le chargement différé est explicite : Google Search n'interagit pas avec la page. Un contenu qui n'apparaît qu'après un clic, un défilement ou une saisie n'est jamais chargé par le robot. Le guide mobile-first ajoute qu'il ne faut pas charger le contenu principal à la suite d'une interaction utilisateur.
Concrètement, un accordéon dont le texte est déjà dans le code source et replié par CSS est indexé. Un accordéon dont le clic déclenche une requête serveur pour récupérer le texte ne l'est pas. Même composant visuel, résultat opposé.
Le chapitre SEO du Web Almanac 2024 de HTTP Archive (analyse automatisée de millions de pages, pages d'accueil et pages internes) constate qu'à la médiane, le nombre de mots visibles après rendu diffère de 15 % du nombre de mots du HTML brut sur les pages d'accueil mobiles, et de 18 % sur desktop. Le chapitre JavaScript de la même édition relève une médiane de 558 Ko de JavaScript par page mobile, en hausse de 14 % sur un an. Plus le site dépend du JavaScript pour afficher son texte, plus la vérification du rendu s'impose.
Le même chapitre SEO note que l'écart de mots entre page d'accueil mobile et desktop s'est réduit à 36 mots à la médiane en 2024 (contre 55 en 2022). Faut-il retirer du texte sur mobile plutôt que le replier ? C'est l'objet d'un autre article sur le contenu mobile et le SEO.
Comment vérifier ce que Google voit sur votre site
Quatre contrôles suffisent pour lever le doute sur une page donnée.
- Le code source (Ctrl+U dans le navigateur). Cherchez une phrase du contenu replié. Si elle est présente, la version CSS est en place. Si elle est absente, le texte est injecté par JavaScript.
- L'outil d'inspection d'URL de la Search Console. Testez l'URL en direct, puis ouvrez le HTML rendu (« Afficher la page explorée »). C'est la vue la plus proche de ce que Google indexe. Le texte replié doit y figurer.
- La navigation sans JavaScript. Désactivez JavaScript dans les outils de développement et rechargez. Ce qui disparaît dépend du rendu : à confirmer avec le point 2.
- La recherche d'une phrase exacte du contenu replié, entre guillemets, dans Google. Si la page ressort, le passage est indexé.
Ces vérifications font partie d'un contrôle d'indexation classique. Elles sont utiles sur les constructeurs de pages WordPress, où onglets et accordéons sont parfois rendus côté client.
Critères de décision pour un site de TPE ou PME
Replier du contenu est un choix d'interface, pas un choix SEO. Voici les critères que je propose d'appliquer avant de décider.
- Le contenu qui porte la requête principale s'affiche en clair. Titre, premier paragraphe, réponse directe, prix ou caractéristiques déterminantes : rien de tout cela ne va dans un onglet.
- Le contenu complémentaire peut se replier : caractéristiques techniques détaillées, FAQ, conditions, avis au-delà des premiers. C'est aussi ce qui allège les pages mobiles.
- Le texte replié est dans le HTML initial. Élément
<details>/<summary>natif ou bloc masqué par CSS, jamais un chargement à la demande pour du texte à indexer. - Un bloc replié n'est pas un fourre-tout à mots-clés. Si vous n'accepteriez pas que le visiteur le lise ouvert, il ne doit pas exister.
- Les liens comptent aussi. Un menu de catégories ou de villes replié en pied de page transmet du maillage interne s'il est dans le HTML. Il reste soumis aux mêmes règles : des liens utiles à un humain, pas cinquante ancres géographiques empilées.
- Mesurez l'usage réel. Un événement sur l'ouverture de chaque accordéon indique si le contenu replié est consulté. Un bloc que personne n'ouvre mérite d'être supprimé ou remonté, pas conservé « pour le SEO ».
En résumé : Google ne sanctionne pas le contenu masqué par l'interface. Il sanctionne le texte dissimulé pour le tromper, et il ignore ce qu'il ne reçoit pas dans le HTML.
Questions fréquentes
Le contenu dans un accordéon ou un onglet est-il indexé par Google ?
Oui, à condition que le texte soit présent dans le HTML de la page et simplement replié par CSS ou par un script. Depuis l'indexation mobile-first, Google prend en compte tout ce qui figure dans le code, y compris ce qui devient visible après un clic. Ses règles anti-spam citent explicitement les accordéons et onglets comme des éléments autorisés.
Un bouton « Lire la suite » pénalise-t-il le référencement ?
Non, si le texte complet est déjà dans le code de la page et que le bouton ne fait que l'afficher. En revanche, si le clic déclenche un chargement du texte depuis le serveur, Google ne le verra pas, car il n'interagit pas avec la page. Vérifiez dans le code source que le contenu est présent avant le clic.
Qu'est-ce que Google considère comme du texte caché abusif ?
Du texte placé sur une page uniquement pour influencer le moteur, sans être lisible par un visiteur : texte de la couleur du fond, police à zéro, bloc positionné hors écran, lien sur un seul caractère. Ces pratiques violent les règles anti-spam de Google et peuvent entraîner une action manuelle. Les éléments d'interface qui masquent du contenu destiné aux utilisateurs ne sont pas concernés.
Comment savoir si Google voit mon contenu replié ?
Utilisez l'outil d'inspection d'URL de la Google Search Console, lancez un test en direct et consultez le HTML rendu. Si le texte replié y apparaît, il est pris en compte. Vous pouvez aussi rechercher une phrase exacte du texte entre guillemets dans Google pour vérifier qu'elle ressort.
Le contenu masqué a-t-il moins de poids que le contenu visible ?
Google ne publie pas de pondération et affirme prendre en compte tout le HTML des pages mobiles. Les tests qui concluaient à une dévaluation datent de 2016-2017, avant l'indexation mobile-first. Par prudence, gardez visible ce qui répond à la requête principale et repliez le contenu complémentaire.
Le cloaking, c'est la même chose que le contenu masqué ?
Non. Le cloaking consiste à servir un contenu différent au robot et aux visiteurs pour manipuler le classement, ce qui est interdit. Un accordéon montre le même contenu à tout le monde, il est seulement replié. Un paywall n'est pas du cloaking si Google accède au contenu complet avec le balisage adapté.