Quand une page repose sur JavaScript, son contenu n’apparaît pas d’un bloc dans le code source. Googlebot doit l’exécuter, patienter, puis décider ce qu’il garde. Or cette exécution a une limite de temps, et tout ce qui arrive après passe à la trappe. Beaucoup de sites croient être indexés alors qu’une partie de leurs textes reste invisible. La cause tient rarement au code lui-même, mais au moment où ce code se termine. Voici comment corriger le tir sans refondre toute l’application.
Ce que Googlebot fait avant même d’indexer
Avant toute chose, il faut distinguer trois phases. L’exploration consiste à lire l’URL, l’affichage exécute le JavaScript dans une version toujours actualisée de Chromium, puis l’indexation fige ce qui est visible à l’instant où le moteur de rendu a terminé son travail, même si des scripts tournent encore en arrière-plan.
Cette exécution n’a rien d’anecdotique. Un script qui modifie le texte après coup change le contenu que Googlebot mémorise. Si le rendu est trop lent, l’indexation peut capturer une version partielle, avec des sections vides ou des menus absents.
Le point qu’on oublie, c’est que l’affichage ne se résume pas à charger une page, mais à laisser le moteur de rendu exécuter les scripts, modifier le DOM et stabiliser le résultat avant que l’indexation ne fige ce qu’elle voit. Autrement dit, une page n’est pas indexée dès son premier octet reçu : elle doit d’abord atteindre un état stable, faute de quoi Googlebot mémorise un contenu intermédiaire et incomplet. La précipitation est mauvaise conseillère.
Le piège de l’événement load et des cinq secondes
Le piège tient en une phrase. Google indexe uniquement ce qui est présent dans la page au moment où l’événement load se déclenche. Si un script injecte un paragraphe après ce moment, ce paragraphe n’existe pas pour Googlebot. Makina Corpus le formule sans détour sur daonet.eu : « le JavaScript doit s’exécuter rapidement, avec une cible de moins de 5 secondes ».
Dépasser ce seuil, c’est accepter qu’une partie du contenu ne sera jamais vue, même si la page fonctionne parfaitement dans le navigateur d’un visiteur humain et même si les outils de test affichent un rendu complet. L’enjeu n’est pas technique : un contenu qui arrive trop tard équivaut à un contenu inexistant pour l’indexation, et cette perte passe inaperçue tant qu’on ne compare pas le HTML initial au résultat final.
Le chargement différé est souvent présenté comme une bonne pratique de performance. Pour Googlebot, il devient un risque si le contenu principal n’apparaît qu’après une interaction ou un délai. Les sections qui dépendent d’un scroll, d’un clic ou d’un minuteur échappent presque toujours à l’indexation, car l’événement load est déjà passé.
Les blocages que les premiers résultats passent sous silence
Et si Googlebot ne venait jamais jusqu’à votre page ? Le fichier robots.txt est lu avant toute exploration ; si l’URL y est bloquée, aucune requête HTTP n’est envoyée. La question porte sur l’accès initial, pas sur le rendu JavaScript. Pour empêcher la découverte de liens, le mécanisme nofollow reste la seule voie propre.
Beaucoup confondent nofollow et noindex. Le premier agit sur la découverte des liens, le second sur l’affichage dans les résultats. Un lien en nofollow n’empêche pas Googlebot de suivre l’URL s’il la découvre autrement, mais il ne participe pas à la transmission de popularité. Sur ce point, voir aussi notre article sur mon site n’apparaît pas sur Google : les 8 erreurs à corriger d’urgence.
Certaines pages sont rendues invisibles par une simple ligne dans robots.txt. L’outil de test peut afficher un rendu correct, car il contourne parfois les restrictions locales, mais Googlebot, lui, les respecte. Il faut vérifier que les fichiers .js et les appels d’API ne sont pas bloqués par erreur, sinon l’affichage reste vide.
Corriger le tir sans refondre toute l’application
Le premier réflexe, c’est de déplacer le contenu critique dans le HTML initial. Plus besoin d’attendre qu’un script le génère : il est là, prêt à être lu. Les données importantes peuvent être sérialisées dans une balise script de type application/json, puis rendues côté client sans délai supplémentaire, ce qui évite de recharger une ressource externe et réduit le temps avant l’événement load.
Avant de toucher au code, un état des lieux s’impose. Ouvrir la page sans JavaScript montre immédiatement ce qui manque. Les textes absents à l’écran sont précisément ceux que Googlebot ne verra pas si le chargement dépasse le seuil.
Les points de contrôle qui suffisent à changer le résultat
- Vérifiez que le contenu principal est déjà dans le HTML initial, pas seulement dans un fichier .js.
- Les requêtes bloquées par robots.txt.
- Votre page affiche-t-elle quelque chose de lisible avant cinq secondes ?
- Un test sans JavaScript montre souvent des sections entières manquantes.
- Le chargement différé des images ou des textes.
Je crois que beaucoup de sites échouent ici sans le savoir. Les tests donnent une page complète après quelques secondes, mais Googlebot a déjà refermé son carnet, parce que la limite des cinq secondes ne se négocie pas au cas par cas et qu’elle s’applique à toutes les URLs sans exception. La question n’est pas de savoir si le JavaScript fonctionne, mais quand il finit de produire le contenu.
La correction ne demande pas de tout réécrire. Il suffit souvent de sortir le contenu principal du JavaScript et de le placer directement dans le HTML servi au serveur. Les interactions secondaires peuvent rester dynamiques, mais le texte qui doit être indexé ne doit plus dépendre d’un script.
Quand le chargement devient un critère de classement
Le temps ne joue pas en votre faveur. Googlebot applique une règle simple et brutale : ce qui n’est pas là au moment du load n’existe pas. Les sites qui jouent avec des chargements différés ou des animations paresseuses perdent des pans entiers de contenu sans le mesurer. La correction passe par une discipline de vitesse et de priorité, pas par une refonte complète. Votre page peut-elle se permettre d’attendre plus de cinq secondes avant de montrer ce qui compte ?
