Le contenu masqué dans les onglets est-il vraiment indexé en mobile-first ?

Pourquoi Google fait-il cette distinction entre chargement initial et dynamique ?

La réponse tient à la manière dont Googlebot crawle les pages mobiles. Lorsqu'il indexe une URL en mobile-first, il simule un smartphone et charge la page une seule fois. Il analyse alors le DOM tel qu'il se présente après le rendu initial JavaScript, sans simuler de clics, de scrolls ou d'interactions.

Si votre contenu nécessite une action utilisateur (clic sur un onglet, bouton "Voir plus", hover) pour déclencher un appel AJAX ou un chargement différé, Googlebot ne le verra jamais. Le bot n'a pas pour mission de tester toutes les interactions possibles sur chaque page crawlée. Il se contente du premier état du DOM une fois le JavaScript exécuté.

Cette limitation a des implications majeures pour les architectures SPA (Single Page Application) et les interfaces riches en JavaScript. Beaucoup de frameworks modernes (React, Vue, Angular) chargent du contenu conditionnel qui ne s'affiche qu'après interaction. Si ce contenu n'est pas présent dans le DOM initial rendu côté client, il est invisible pour l'index.

Que signifie exactement "chargé au chargement de la page" ?

L'expression désigne tout contenu présent dans le DOM une fois le rendu JavaScript initial achevé. Autrement dit : Googlebot charge l'URL, exécute le JS, attend quelques secondes (généralement 5 secondes maximum), puis fige l'état du DOM et indexe ce qu'il voit à ce moment précis.

Si vos onglets sont codés avec du HTML déjà présent mais caché via CSS (display:none, visibility:hidden, aria-hidden), le contenu est bien indexable. En revanche, si vos onglets ne chargent le HTML qu'au clic (via fetch() ou XMLHttpRequest), ce contenu n'existe pas au moment où Googlebot analyse la page. Il ne sera donc pas indexé.

Comment vérifier ce que Googlebot voit réellement ?

Utilise l'outil de test de compatibilité mobile dans la Search Console (anciennement Mobile-Friendly Test). Cet outil simule le comportement de Googlebot mobile et te montre le HTML rendu après exécution du JavaScript. Compare ce rendu avec ce que tu vois dans l'inspecteur de ton navigateur après avoir cliqué sur chaque onglet.

Autre option : demande le rendu HTML via l'URL Inspection Tool de la Search Console. L'onglet "Plus d'infos" > "Afficher la page testée" > "HTML" te montre exactement ce que Google a indexé. Si ton contenu d'onglets n'apparaît pas ici, il n'est pas indexé.

• Contenu indexable : HTML présent dans le DOM initial, même caché par CSS
• Contenu non indexable : HTML chargé après clic, hover ou interaction utilisateur
• Solution technique : charger tous les onglets dès le rendu initial et les masquer avec CSS ou aria-hidden
• Outil de vérification : Search Console > Inspection d'URL > HTML rendu
• Impact SEO : le contenu invisible pour Googlebot ne contribue ni au ranking ni à l'indexation de mots-clés

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, mais avec des nuances importantes. J'ai observé des cas où du contenu chargé très rapidement après le rendu initial (dans les 2-3 premières secondes) était parfois indexé, probablement parce que Googlebot attend un certain délai avant de figer le DOM. Cependant, compter là-dessus est risqué : les temps d'attente varient selon la charge serveur, la complexité JS et le crawl budget alloué.

En pratique, j'ai vu des sites perdre des positions clés après migration vers une architecture à onglets dynamiques sans pré-chargement. Le contenu disparaissait littéralement de l'index. Google ne crawle pas deux fois la même URL pour tester différents états d'interface. Si ton contenu n'est pas là au premier passage, c'est terminé.

Quelles sont les zones grises de cette règle ?

Mueller ne précise pas ce qu'il advient du contenu chargé via Intersection Observer (lazy loading au scroll). Si un onglet devient visible via scroll automatique ou progressive enhancement, est-il indexé ? [A verifier] La documentation officielle reste floue sur ce point. Mes tests suggèrent que le contenu visible dans le viewport initial est indexé, mais pas celui situé plus bas même s'il est techniquement "chargé" dans le DOM.

Autre cas limite : les accordéons imbriqués. Si un contenu est caché dans un onglet lui-même contenu dans un autre onglet, Google l'indexe-t-il si le HTML est présent ? Oui, mais avec un poids moindre qu'un contenu directement visible. Google comprend la hiérarchie visuelle et ajuste le poids des signaux en conséquence. Un contenu caché dans trois niveaux d'onglets aura moins d'impact qu'un contenu affiché par défaut.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Sur desktop, historiquement, Googlebot était plus tolérant. Avant le passage au mobile-first, le bot desktop exécutait parfois des interactions basiques (expansion d'accordéons, chargement de lazy load basique). Mais depuis que l'indexation mobile-first est devenue la norme pour la majorité des sites, cette exception a disparu. Ne compte plus sur le bot desktop pour sauver ton contenu mal architecturé.

Exception notable : les sites explicitement exclus du mobile-first (très rares désormais, principalement des sites legacy non responsive). Pour eux, l'ancienne logique desktop s'applique encore, mais cette situation est temporaire. Google migre tous les sites progressivement, et aucun nouveau site n'échappe au mobile-first dès son indexation initiale.

Comment auditer l'architecture des onglets sur mon site ?

Commence par identifier toutes les pages utilisant des interfaces à onglets, accordéons ou contenu masqué. Liste les templates concernés : fiches produits, pages services, FAQ, landing pages. Pour chaque template, inspecte le code source et vérifie si le HTML de tous les onglets est présent dès le chargement initial ou s'il est chargé dynamiquement.

Utilise la Search Console pour comparer le HTML brut (Ctrl+U dans le navigateur) avec le HTML rendu (Inspection d'URL > Afficher la page testée). Si tu constates des écarts significatifs, notamment du contenu qui apparaît dans le navigateur mais pas dans le rendu Google, tu as un problème d'indexation. Priorise les pages stratégiques : celles qui génèrent du trafic organique ou qui ciblent des mots-clés prioritaires.

Quelle solution technique adopter pour garantir l'indexation ?

La méthode la plus fiable : pré-charger tous les onglets dans le DOM et les masquer via CSS (display:none ou visibility:hidden). Le contenu est techniquement présent dans le code source, donc indexable, mais invisible jusqu'à ce que l'utilisateur clique sur l'onglet concerné. Cette approche fonctionne avec tous les frameworks modernes.

Si tes onglets contiennent beaucoup de contenu (ce qui pourrait ralentir le chargement initial), opte pour un server-side rendering (SSR) ou un static site generation (SSG). Next.js, Nuxt.js et Gatsby permettent de générer le HTML complet côté serveur, envoyé directement au bot sans dépendre du JavaScript client. Autre option : lazy loading progressif avec Intersection Observer, mais attention aux zones grises mentionnées plus haut.

Quelles erreurs éviter absolument ?

Erreur classique : implémenter des onglets avec React ou Vue en mode SPA pur sans SSR, où chaque onglet correspond à un state component vide par défaut. Le contenu se charge au clic via un useState() ou un v-if conditionnel. Pour l'utilisateur, c'est fluide. Pour Googlebot, c'est un trou noir.

Autre piège : utiliser des hash fragments (#onglet1, #onglet2) pour gérer l'affichage des onglets sans pré-charger le contenu. Google ignore les hash fragments et ne crawle pas les variantes d'URL avec ancres différentes. Si ton contenu n'existe que lorsque l'URL contient #onglet2, il ne sera jamais indexé. Préfère des query parameters (?tab=2) ou, mieux encore, du contenu pré-chargé.

• Vérifier que tous les onglets sont présents dans le DOM initial (pas de chargement AJAX conditionnel)
• Tester chaque template concerné via l'Inspection d'URL de la Search Console
• Comparer le HTML brut (Ctrl+U) avec le HTML rendu par Google
• Migrer vers SSR ou SSG si l'architecture actuelle repose sur du chargement conditionnel
• Éviter les hash fragments pour gérer l'affichage des onglets
• Privilégier display:none ou visibility:hidden plutôt que le chargement différé