Pourquoi Google refuse-t-il d'indexer les pages sans contenu visible dans le body ?

Qu'entend Google exactement par « contenu dans le body » ?

Google analyse le body HTML rendu après l'exécution du JavaScript. Si votre contenu principal n'apparaît pas dans cette zone au moment du crawl, le bot considère la page comme vide ou sans valeur. Ce n'est pas une question de balises meta ou de header : le corps de page doit contenir du texte exploitable.

Concrètement, une page dont le contenu se charge uniquement après un clic utilisateur, une interaction AJAX tardive ou une authentification obligatoire sera ignorée. Le bot ne franchit pas les murs de login et n'attend pas indéfiniment qu'un script peuple le DOM.

Pourquoi cette règle existe-t-elle ?

L'objectif de Google est simple : indexer du contenu accessible aux utilisateurs anonymes via la recherche organique. Si une page nécessite un compte pour afficher son contenu, elle n'a aucune raison d'apparaître dans les SERP publiques. Ce serait contre-productif pour l'expérience utilisateur : un internaute cliquant sur un résultat doit accéder immédiatement au contenu promis.

D'un point de vue technique, ce filtre permet aussi à Google d'éviter d'indexer du bruit : pages vides générées dynamiquement, templates sans données, ou contenu fantôme créé par des frameworks JS mal configurés. C'est un mécanisme de défense contre la pollution de l'index.

Quels types de sites sont concernés ?

Les plateformes SaaS avec gated content sont les premières touchées : dashboards clients, espaces membres, forums privés. Mais les sites e-commerce sont également vulnérables si leurs fiches produits se chargent entièrement en client-side rendering sans fallback SSR.

Les applications React, Vue ou Angular mal configurées produisent souvent ce problème : le HTML initial ne contient qu'un div vide, et tout le contenu s'injecte après hydratation. Si Google crawle avant que le JS ne s'exécute complètement, il voit une coquille vide.

• Contenu derrière login : jamais indexable, par design
• Client-side rendering pur : risque élevé si le SSR n'est pas implémenté
• Lazy loading mal calibré : si le contenu principal charge trop tard, Google peut passer à côté
• Frameworks JS sans pre-rendering : Angular, React sans Next.js/Gatsby produisent souvent du HTML vide au premier rendu
• Contenu généré par API externe : si l'appel prend trop de temps ou échoue côté serveur, le body reste vide

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

Absolument. On observe depuis des années que les sites full-client-side sans SSR peinent à se positionner, même avec un contenu riche une fois le JS exécuté. Google a progressé sur le rendu JavaScript, mais son budget crawl reste limité : il ne peut pas attendre 5 secondes que chaque page termine son hydratation.

Les audits de sites SPA montrent régulièrement des taux d'indexation catastrophiques pour les sections à fort rendering JS. Le Mobile-First Index aggrave ce phénomène : sur mobile, le timeout de rendu est encore plus court, et les ressources CPU allouées moindres. [A vérifier] : Google communique peu sur les seuils exacts de timeout côté mobile.

Quelles nuances faut-il apporter ?

La distinction entre « contenu principal » et « contenu secondaire » reste floue. Mueller ne précise pas si un texte minimal dans le body suffit à éviter le filtre, ou s'il faut un volume critique. On constate sur le terrain qu'une page avec un titre H1 et deux phrases peut être indexée, mais rarement bien positionnée.

Autre point : le « contenu caché » n'est pas uniquement lié au login. Les accordéons, onglets masqués ou modals peuvent aussi poser problème si le HTML correspondant n'est pas présent au chargement initial. Google lit le DOM après JS, mais si le contenu s'injecte uniquement au clic, le signal est affaibli.

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

Les pages AMP et les résultats enrichis échappent partiellement à cette logique. AMP impose un HTML structuré présent dès le départ, donc le problème ne se pose pas. Les données structurées JSON-LD permettent aussi de signaler du contenu même si le HTML est pauvre, mais ce n'est pas une solution miracle : Google indexe le JSON-LD pour les rich snippets, pas pour le corps de texte classique.

Enfin, certaines pages transactionnelles (checkout, panier) n'ont pas vocation à être indexées, même si elles contiennent du texte. Le crawl budget est là pour ça : si Google détecte que ces pages n'apportent rien aux SERP, il les ignore volontairement, indépendamment de leur contenu body.

Comment vérifier si mes pages sont vulnérables ?

Première étape : utiliser l'outil d'inspection d'URL dans la Search Console. Compare le HTML brut (view source) avec le rendu live (screenshot Googlebot). Si le contenu principal n'apparaît que dans le second, c'est que ton JS fait le gros du travail, et Google peut louper des pages selon son humeur de crawl.

Deuxième vérification : désactive JavaScript dans ton navigateur et charge tes pages critiques. Si elles affichent un écran blanc ou un loader infini, tu as un problème. Google ne garantit pas le rendu JS pour 100 % des crawls, surtout sur les sites à fort volume de pages.

Quelles erreurs techniques provoquent ce syndrome ?

Le piège classique : monter une SPA React/Vue sans configurer de Server-Side Rendering ou Static Site Generation. Le fichier index.html ne contient qu'un div#root vide, et tout le contenu s'injecte côté client. Google peut crawler cette page avant que le bundle JS ne s'exécute complètement.

Autre erreur fréquente : placer le contenu principal derrière des appels API asynchrones sans fallback côté serveur. Si l'API est lente ou hors ligne au moment du crawl, Googlebot voit une page vide et passe son chemin. Les timeouts réseau ne sont pas toujours gérés avec des états de chargement indexables.

Que faut-il implémenter concrètement ?

Pour les frameworks modernes, passe à Next.js (React), Nuxt (Vue) ou Angular Universal. Ces solutions offrent du SSR ou du SSG out-of-the-box, garantissant que le HTML initial contient le contenu. Si tu ne peux pas migrer, implémente un pre-rendering avec Prerender.io ou Rendertron pour servir du HTML statique aux bots.

Pour les sites à login, expose une version publique allégée du contenu si tu veux qu'elle soit indexée. Les forums font souvent ça : un extrait des premiers messages visible sans compte, le reste derrière authentification. Ça permet d'attirer du trafic organique tout en gardant l'incitation à s'inscrire.

• Auditer le HTML source vs rendu Googlebot pour toutes les pages stratégiques
• Implémenter SSR/SSG sur les sections e-commerce et contenu éditorial
• Tester le site avec JavaScript désactivé : le contenu principal doit rester visible
• Éviter le lazy loading sur le contenu above-the-fold : il doit charger immédiatement
• Monitorer les logs serveur pour détecter les requêtes Googlebot qui reçoivent du HTML vide
• Configurer un pre-rendering conditionnel pour les user-agents bots si le SSR complet est trop lourd