Que voit vraiment Google quand une page dépend du JavaScript ?

La question revient à chaque projet dont le contenu s'affiche par script : le moteur voit il ce que voit l'utilisateur ? La réponse officielle est oui, Google exécute le JavaScript et indexe le résultat, mais cette réponse cache une mécanique en deux temps qui explique la plupart des déconvenues. Le rendu JavaScript par Google n'est pas simultané à l'exploration : la page est d'abord récupérée et analysée telle qu'elle arrive du serveur, puis placée dans une file d'attente pour être rendue plus tard, avec un navigateur, dans des conditions qui ne sont pas celles d'un visiteur. Entre ces deux moments, tout peut arriver, et ce qui finit dans l'index n'est pas toujours ce que l'on croit y avoir mis.

Comment le moteur traite une page en deux passes

Le traitement se décompose en trois étapes distinctes que la documentation officielle sépare clairement : l'exploration, le rendu et l'indexation. Comprendre cette séparation évite les trois quarts des erreurs de diagnostic, car un contenu absent de l'index peut échouer à n'importe laquelle de ces étapes, pour des raisons totalement différentes. Cette lecture par étapes prolonge directement ce que nous exposons dans la rubrique référencement naturel sur le fonctionnement des robots d'exploration.

La première passe, sans exécution de script

Le robot demande l'adresse et reçoit le document HTML tel que le serveur l'a produit. Il en extrait immédiatement les liens, les balises de tête, la déclaration canonique et les directives d'indexation, puis en tire les nouvelles adresses à explorer. À ce stade, aucun script n'a été exécuté : ce qui n'est pas dans la source n'existe pas encore. C'est une distinction lourde de conséquences, car les décisions les plus structurantes, notamment celles qui portent sur l'indexation et la canonique, sont prises très tôt à partir de cette source brute.

La file d'attente de rendu

La page rejoint ensuite une file d'attente et sera rendue par un navigateur automatisé quand des ressources seront disponibles. Google a longtemps communiqué sur des délais qui pouvaient atteindre plusieurs jours, puis a indiqué que la médiane était devenue très courte, de l'ordre de quelques secondes pour la plupart des pages (documentation Google Search Central). La médiane n'est cependant pas la queue de distribution, et sur un site à faible autorité ou à budget d'exploration contraint, l'attente reste réelle. Un contenu qui n'existe qu'après rendu est donc indexé plus tard que le reste, parfois beaucoup plus tard.

Ce qui est pris avant le rendu et ne change plus

Certaines décisions se prennent à la première passe et ne sont pas systématiquement rejouées après rendu. Une directive interdisant l'indexation présente dans la source empêche la page d'être rendue du tout, ce qui rend inutile toute tentative de la retirer par script : le script ne sera jamais exécuté. De même, une adresse canonique injectée après coup entre en concurrence avec celle vue à la première passe, et le moteur choisira lui même. La règle pratique est simple : tout ce qui relève des directives d'indexation doit figurer dans la source servie par le serveur.

Un rendu, pas une session de navigation

Il faut aussi se défaire de l'idée que le moteur parcourt le site comme un utilisateur, en enchaînant les pages. Chaque adresse est traitée isolément, souvent à des moments très éloignés, par des processus différents. Une page qui suppose que l'utilisateur vient d'une autre page, parce qu'elle lit un paramètre transmis, un état de filtre ou une variable posée précédemment, se rendra donc dans un état neutre qui ne correspond à rien. Le même raisonnement vaut pour les contenus personnalisés selon la position géographique ou la langue du navigateur : le rendu s'effectue depuis une localisation qui n'est pas nécessairement celle du public visé, et la version obtenue est celle qui sera indexée.

Le navigateur qui rend n'est pas un visiteur

Le rendu s'effectue dans un navigateur sans état conservé d'une page à l'autre : pas de cookie hérité, pas de stockage local persistant, pas de session. Toute page dont le contenu dépend d'un état accumulé, d'un choix mémorisé ou d'une authentification échouera à afficher ce contenu au moment du rendu. Les demandes de permission, les fenêtres modales bloquantes et les scripts qui attendent une interaction produisent le même effet. Le robot ne clique pas, ne défile pas au delà de ce que la page affiche d'elle même, et n'accepte rien.

Les configurations qui posent réellement problème

Toutes les pages dépendant de scripts ne sont pas à risque, loin de là. Les difficultés se concentrent sur quelques configurations identifiables, et il est plus efficace de les connaître que d'auditer au hasard. La démarche est la même que pour le comptage du crawl, exposée dans notre article expliquant comment calculer son budget d'exploration à partir des journaux serveur : partir des familles d'adresses plutôt que des cas individuels.

Les liens qui ne sont pas des liens

Un élément cliquable qui déclenche une navigation par script, sans être une ancre pourvue d'une adresse, n'est pas un lien pour le moteur. C'est le défaut le plus répandu des interfaces construites avec les cadriciels récents, et il coupe purement et simplement la découverte : les pages concernées n'existent que si un plan de site les déclare. La correction est triviale et consiste à utiliser une véritable ancre avec une adresse réelle, quitte à intercepter le clic pour conserver la navigation fluide. Elle est aussi bénéfique pour l'accessibilité et pour l'ouverture dans un nouvel onglet.

Le contenu chargé au défilement

Une liste qui s'allonge à mesure que l'utilisateur défile ne s'allonge jamais pour le robot, qui ne défile pas. Les produits ou articles situés au delà de la première fournée n'existent donc pas, sauf si une pagination classique en adresses distinctes existe en parallèle. C'est un cas où l'ergonomie moderne et l'indexation entrent frontalement en conflit, et où la seule réponse solide consiste à maintenir les deux, la navigation fluide pour l'utilisateur et des adresses paginées réelles pour le moteur.

Les routes gérées entièrement côté client

Une application qui gère ses adresses par l'historique du navigateur peut très bien fonctionner pour l'utilisateur et ne servir qu'une coquille vide à toute demande directe. Le test décisif consiste à demander une adresse profonde directement, sans passer par la page d'accueil : si le serveur répond une page qui ne contient pas le contenu attendu, le moteur dépend entièrement du rendu pour cette page. Le cas des adresses avec fragment est pire encore, la partie située après le croisillon n'étant jamais transmise au serveur ni considérée comme une adresse distincte.

Les données structurées produites par script

Les données structurées injectées après coup sont bien prises en compte, à condition que le rendu aboutisse, ce qui les place mécaniquement dans la catégorie fragile. Le cas problématique n'est pas leur absence mais leur incohérence : un balisage produit côté client à partir de données récupérées en direct peut annoncer un prix, une disponibilité ou une note qui diffèrent de ce que la page affiche au moment du rendu, ce que le moteur traite comme une non concordance. Sur un contenu à enjeu, notamment une fiche produit ou un avis, il vaut mieux produire le balisage au serveur avec exactement les mêmes valeurs que le contenu visible.

Les ressources bloquées ou trop lentes

Si les fichiers de script nécessaires à l'affichage sont interdits par le fichier robots.txt, hébergés sur un domaine tiers défaillant ou trop lents à répondre, le rendu s'effectue sans eux et produit une page vide. Le blocage par robots.txt des dossiers de ressources est un vestige de pratiques anciennes qui persiste sur beaucoup de sites, et il produit exactement l'effet inverse de celui recherché. Le moteur abandonne par ailleurs les ressources qui tardent, sans qu'aucun message ne le signale.

Vérifier ce qui est réellement indexé

Le diagnostic ne se fait pas par raisonnement mais par observation, et trois outils suffisent, chacun répondant à une question différente. L'erreur classique consiste à n'en utiliser qu'un et à généraliser sa réponse. La méthode s'apparente à celle que nous appliquons pour le fichier robots.txt : vérifier ce que le serveur répond réellement plutôt que ce que la configuration est censée produire.

Comparer la source et le rendu

Le premier geste consiste à afficher le code source de la page, celui que le serveur envoie, et à y chercher une phrase précise du contenu principal. Si elle s'y trouve, le contenu est vu dès la première passe et la question du rendu ne se pose pas. Si elle n'y est pas mais apparaît dans l'inspecteur du navigateur, le contenu dépend entièrement du rendu. Cette distinction, qui prend trente secondes, oriente tout le reste du diagnostic et évite de chercher des explications compliquées à un problème simple.

Utiliser l'inspection d'URL de la Search Console

L'outil d'inspection donne le capital le plus précieux : le code HTML tel que Google l'a effectivement rendu, ainsi que la liste des ressources qu'il n'a pas pu charger et les messages de la console. C'est la seule source qui parle du comportement réel du moteur sur le site concerné, et non d'une simulation. Il faut lire cette sortie en entier, notamment la liste des ressources en échec, qui explique à elle seule une grande part des rendus vides.

Interroger le cache et la recherche sur extrait

Une vérification complémentaire consiste à rechercher dans le moteur une phrase exacte du contenu, entre guillemets, restreinte au site. Si la phrase ressort, elle est indexée. Cette méthode est plus fiable qu'un affichage de cache, dont la disponibilité a évolué, et elle répond directement à la seule question qui compte pour un contenu : est il dans l'index ou non. Elle permet aussi de vérifier des portions précises, par exemple un bloc de spécifications techniques chargé après le reste.

Regarder les journaux plutôt que les rapports

Les journaux du serveur apportent une information qu'aucun outil ne donne : la liste des ressources que le robot a réellement demandées. Un site dont le moteur ne télécharge jamais les fichiers de script a un problème d'accès, un site dont il les télécharge beaucoup moins souvent que les pages a un problème de rendu partiel, et un site dont il télécharge tout normalement a un problème ailleurs. Cette lecture prend quelques minutes et permet d'écarter d'emblée toute une famille d'hypothèses avant de commencer à modifier quoi que ce soit.

Rejouer le rendu avec des contraintes réalistes

Un dernier contrôle consiste à charger la page dans un navigateur automatisé, sans cookie, sans stockage, avec les scripts tiers bloqués, et à extraire le contenu obtenu. Cette simulation s'approche des conditions du rendu et révèle les dépendances cachées : une bannière de consentement qui masque le contenu tant qu'aucun choix n'est fait, un script d'analyse dont l'échec interrompt la chaîne, une police distante qui bloque l'affichage. Ces cas ne se voient jamais dans un navigateur ordinaire déjà pourvu de cookies.

Décider quoi rendre côté serveur

La conclusion pratique n'est presque jamais de renoncer aux scripts, mais de choisir ce qui doit exister sans eux. Cette frontière se trace une fois, au niveau de l'architecture, et elle relève d'un arbitrage entre coût de développement et fiabilité de l'indexation.

Le minimum incompressible dans la source

Quatre éléments doivent figurer dans le document servi par le serveur, sans exception : le titre, la méta description, la déclaration canonique et les directives d'indexation. À ces quatre s'ajoute, pour toute page destinée à se positionner, le contenu textuel principal et le titre de premier niveau. Une page dont ces éléments dépendent du rendu fonctionnera peut être, mais elle dépendra d'une étape supplémentaire dont ni le délai ni la réussite ne sont garantis, ce qui est un risque inutile pour un contenu stratégique.

Le rendu au serveur, avec ses contreparties

Produire le HTML complet côté serveur règle la question de fond, au prix d'une infrastructure plus lourde et de temps de réponse à surveiller de près. Sur un site de contenu, une génération à la publication suivie d'une mise en cache est presque toujours préférable à un rendu à chaque requête, qui charge le serveur sans bénéfice pour un contenu qui ne change pas. Le point de vigilance est la cohérence entre la version servie au robot et celle servie à l'utilisateur, toute divergence intentionnelle relevant du procédé trompeur que le moteur sanctionne.

Le compromis de l'hydratation partielle

Entre le tout serveur et le tout client, la voie médiane consiste à servir un document complet et à ne réactiver par script que les zones réellement interactives, formulaires, filtres, carrousels. Le contenu est alors intégralement présent à la première passe, et le script n'ajoute que du comportement. Cette approche a l'avantage de dégrader proprement : sans script, la page reste lisible et navigable, ce qui bénéficie aussi aux utilisateurs sur connexion dégradée. Elle demande en revanche une discipline d'équipe : la frontière entre ce qui est rendu au serveur et ce qui est réactivé au client doit être écrite quelque part et tenue, faute de quoi chaque nouvelle fonctionnalité la déplace d'un cran et le site finit par revenir insensiblement au tout client.

Surveiller dans la durée plutôt que valider une fois

Une architecture validée à un instant donné se dégrade silencieusement au fil des livraisons : une bibliothèque change de mode de rendu, une balise passe côté client, un bloc de contenu migre dans un composant interactif. Le contrôle qui tient dans la durée est automatique et minimal : récupérer chaque semaine la source brute d'une dizaine d'adresses représentatives et vérifier qu'une phrase attendue s'y trouve toujours. Ce test tient en quelques lignes et détecte en une semaine ce qu'un audit ponctuel mettrait six mois à découvrir.

Ne pas confondre le rendu et la vitesse

Une dernière confusion mérite d'être levée, car elle conduit à traiter le mauvais problème. La dépendance au rendu est une question d'existence du contenu, la vitesse d'affichage est une question d'expérience utilisateur, et les deux se corrigent par des moyens différents. Une page dont le contenu arrive par script peut être très rapide pour l'utilisateur et fragile pour l'indexation ; une page entièrement rendue au serveur peut être lente et parfaitement indexée. Traiter la première par des optimisations de performance ne changera rien à son problème d'index, et c'est pourtant la réaction la plus fréquente quand le diagnostic n'a pas été posé. La méthode qui évite ce piège tient en une question posée avant toute intervention : le contenu manque t il dans l'index, ou est il présent mais mal classé ? Le premier cas relève du rendu et de l'accès, le second de la pertinence et de la concurrence, et ils n'ont à peu près aucun traitement commun.