Rendu JavaScript

Une page web moderne se construit souvent en deux temps. Le serveur envoie d'abord un HTML, parfois presque vide, puis des scripts ajoutent le texte, les liens et les images dans le navigateur. Pour un moteur de recherche, le rendu consiste à exécuter ces scripts comme le ferait un navigateur, afin de lire la page dans son état final. Le SEO JavaScript regroupe les pratiques qui garantissent que ce contenu reste accessible aux robots.

Comment Google traite une page en JavaScript

Google décrit trois phases successives : le crawl, le rendu, puis l'indexation. Googlebot récupère l'URL et lit le HTML reçu. Les pages qui répondent avec un code HTTP 200 entrent ensuite dans une file d'attente de rendu, qu'elles contiennent du JavaScript ou non. Une version de Chromium sans interface, tenue à jour, exécute alors les scripts. Ce passage peut prendre quelques secondes, parfois davantage. Le HTML obtenu sert à l'indexation, et les liens qu'il contient relancent le crawl vers de nouvelles URL.

Ce fonctionnement entraîne des règles précises, détaillées dans le guide de Google sur les bases du SEO JavaScript :

• Google ne découvre que les liens écrits avec une balise <a> munie d'un attribut href. Un bouton qui change de page par un simple gestionnaire de clic n'est pas suivi.
• Les URL à fragment, du type #/produits, ne permettent pas de charger des contenus distincts de manière fiable. Google recommande l'API History du navigateur pour la navigation côté client.
• Une page qui ne renvoie pas un code 200, une erreur 404 par exemple, peut ne pas être rendue.
• Les scripts et les pages bloqués par le fichier robots.txt ne sont pas rendus.

Les pièges du noindex et de la balise canonical

Le cas le plus trompeur concerne la directive noindex. Quand Google la trouve dans le HTML initial, il peut renoncer au rendu et à l'exécution du JavaScript. Un script qui retire ensuite cette directive reste donc sans effet, et la page demeure hors de l'index. Une page destinée à être indexée ne doit pas porter de noindex dans son code d'origine.

La balise canonical suit une logique voisine. Google conseille de la placer dans le HTML d'origine. Si un script doit l'insérer, sa valeur doit être identique à celle du HTML initial, et la page ne doit en contenir qu'une seule. Le JavaScript peut en revanche définir la balise title, la meta description ou des données structurées en JSON-LD : Google les lit après le rendu.

Exemple d'une page vide avant exécution

Voici le HTML qu'envoie le serveur d'une application entièrement rendue côté client :

<body>
  <div id="app"></div>
  <script src="/main.2bb85551.js"></script>
</body>

Avant le rendu, cette page ne contient ni titre, ni texte, ni lien. Tout dépend de la réussite du script. Son nom de fichier inclut une empreinte du contenu, ici 2bb85551. Google explique que son service de rendu peut ignorer les en-têtes de cache et réutiliser une ancienne version d'un script ; un nom qui change à chaque mise à jour évite ce décalage.

Côté serveur, statique ou côté client

Le choix d'architecture pèse davantage que les réglages. Le rendu côté serveur produit le HTML complet à chaque requête. Le rendu statique le génère à l'avance, au moment de la construction du site. Le rendu côté client confie tout le travail au navigateur. L'hydratation combine les approches : le serveur envoie un HTML complet, puis le JavaScript le rend interactif. La documentation web.dev de Google indique que le rendu côté client peut convenir au référencement, mais qu'il demande souvent des tests supplémentaires.

Google estime que le rendu côté serveur ou le pré-rendu restent préférables. Ils accélèrent le site pour les internautes comme pour les robots, et tous les robots n'exécutent pas JavaScript. Le rendu dynamique, qui servait une version pré-calculée aux seuls robots, est présenté par Google comme une solution de contournement, et non comme une solution durable.

Le coût pour l'internaute

Le JavaScript a aussi un effet sur l'expérience de navigation. Un script lourd occupe le fil principal du navigateur. Ses tâches longues retardent la réponse aux clics, aux appuis et aux saisies, ce que mesure l'INP, l'indicateur de réactivité des Core Web Vitals. Un INP est jugé bon à 200 ms ou moins. Google suggère aussi de charger les images en différé, au moment où l'internaute s'apprête à les voir.

Vérifier ce que Google voit

L'outil d'inspection d'URL de Google Search Console et le test des résultats enrichis affichent le HTML rendu par Google. Le comparer au code source brut montre précisément ce qui dépend du JavaScript. Si un texte, un lien interne ou une balise n'apparaît que dans la version rendue, sa prise en compte dépend entièrement du rendu. Dans ce cas, mieux vaut placer ces éléments dans le HTML initial, surtout sur les pages qui comptent le plus pour le trafic.