SEO JavaScript : rendu côté serveur et indexation expliqués

Le processus comporte grosso modo trois étapes. Le moteur explore l'adresse et reçoit le HTML brut, la page entre dans une file d'attente de rendu, et quand son tour arrive, le JavaScript est exécuté pour produire la page finale, qui est alors indexée. Google réalise ce rendu avec un moteur de navigateur récent, mais l'étape est distincte et une attente peut s'intercaler.

Une page dont le HTML brut ne contient rien paraît donc vide au premier regard. Le contenu arrive plus tard, mais le temps passé dans la file varie d'une page à l'autre. Pour une page d'actualité ou de stock qui change souvent, cette attente signifie que le contenu apparaît tardivement.

Tous les moteurs de recherche et tous les robots d'IA ne rendent pas aussi bien. Certains n'exécutent aucun JavaScript, ou seulement une partie. Un contenu qui n'apparaît qu'après le rendu met en danger non pas un moteur de recherche, mais tous les outils qui lisent votre site.

Avec le rendu côté client, le serveur envoie une coquille de page vide et le navigateur construit le contenu avec JavaScript. Avec le rendu côté serveur, la page est préparée sur le serveur au moment de la requête et arrive pleine ; JavaScript prend ensuite la main sur l'interaction dans le navigateur. Avec la génération à l'avance, la page est produite une fois au moment de la publication et servie comme un fichier prêt.

Pour les pages qui changent rarement, la génération à l'avance est l'option la plus rapide et la plus solide : pages d'entreprise, pages de services, articles. Les pages qui portent des prix, des stocks ou des données personnalisées conviennent mieux au rendu côté serveur. Les zones que les moteurs de recherche ne doivent de toute façon pas voir, comme un tableau de bord après connexion, peuvent très bien utiliser le rendu côté client.

La plupart des frameworks modernes permettent de mêler les trois méthodes sur un même site. La décision se prend par type de page ; vous n'avez pas à choisir une seule méthode pour tout.

Le test le plus simple consiste à afficher le code source de la page. Si vous y voyez le titre, le texte principal et les liens, il n'y a pas de problème de fond. Si vous ne voyez qu'un élément racine vide et des balises de script, le contenu est construit dans le navigateur.

Le deuxième test est l'outil d'inspection d'URL de Google Search Console, qui montre le HTML reçu et la page telle que le moteur de recherche la voit après le rendu. Tout écart entre la page réelle et la page rendue y apparaît. Vous pouvez aussi vérifier rapidement vos titres, descriptions et la structure de votre contenu avec notre audit SEO on-page gratuit.

Le troisième signe se trouve dans les rapports d'index : de nombreuses pages marquées « explorée, actuellement non indexée », ou des résultats dont le titre et la description ne correspondent pas au vrai contenu, peuvent indiquer un problème de rendu.

• Le texte principal et les liens sont-ils visibles dans le code source de la page
• Le HTML rendu dans l'inspection d'URL correspond-il à la vraie page
• Le titre et la meta description sont-ils dans le premier HTML ou ajoutés plus tard
• Les menus et les liens dans le texte sont-ils construits avec de vraies balises de lien
• Les fichiers de script et de style sont-ils bloqués par le robots.txt

L'erreur la plus courante consiste à construire les liens à partir d'éléments qui fonctionnent sur un événement de clic plutôt qu'avec de vraies balises de lien. Les moteurs de recherche ne suivent que les liens qui portent une adresse ; une structure où un bouton change la page empêche la découverte de ces pages. Un défaut voisin est de placer les pages derrière un fragment de hachage dans l'adresse, ce qui comprime des pages distinctes en une seule URL.

La deuxième est de lier le contenu à l'interaction de l'utilisateur. Le contenu qui se charge quand quelqu'un clique sur un onglet, fait défiler la page ou appuie sur un bouton « afficher plus » est un contenu que le moteur de recherche ne voit pas. Le texte essentiel d'une page ne doit jamais se trouver derrière de telles interactions.

La troisième est de bloquer les fichiers de script et de style dans le robots.txt, ce qui empêche le moteur de rendre la page et l'amène à mal lire la mise en page ou le contenu. La quatrième est de ne pas renvoyer un statut d'erreur correct pour les pages qui n'existent pas : les applications monopages peuvent répondre à une adresse invalide par un code de succès et un message « page introuvable », et le moteur de recherche la prend pour une vraie page et tente de l'indexer.

On le peut, à condition d'en connaître le risque. Google sait lire les titres et les balises meta après le rendu, mais s'ils manquent dans le premier HTML, tous les robots et tous les outils d'aperçu des réseaux sociaux ne les verront pas. Une carte d'aperçu vide quand un lien est partagé vient souvent exactement de là.

La même logique vaut pour les données structurées. Vous pouvez les ajouter avec JavaScript, mais les avoir dans le premier HTML est plus sûr et crée moins de dépendances. Les balises critiques, comme l'adresse canonique et la directive robots, doivent figurer dans le premier HTML ; une directive modifiée après le rendu peut contredire la valeur que le moteur de recherche a lue en premier.

Ce domaine évolue vite et il n'existe pas de réponse unique. Les robots utilisés par les assistants d'IA et les résumés de recherche ne rendent en général pas aussi bien qu'un moteur de recherche classique, et certains se contentent du HTML brut. Garder le contenu important dans le premier HTML est donc la voie la plus sûre pour tous les lecteurs probables.

Si vous visez la visibilité dans les IA, placez la réponse principale de la page et les faits essentiels dans du HTML rendu côté serveur. Vous pouvez tester l'apparence de votre site pour ces outils avec notre vérification gratuite de la visibilité IA.

Tous les sites JavaScript n'ont pas besoin d'être réécrits. Un portail client, un outil de réservation ou une application derrière une connexion n'a pas besoin de trafic de recherche, le rendu côté client suffit donc. Vous voudrez de toute façon garder ces zones hors de la recherche.

Si votre site actuel affiche le contenu dans le code source, utilise de vraies balises de lien et que l'inspection d'URL ne soulève aucune inquiétude, il n'y a aucune raison de changer de méthode de rendu. Reconstruire une installation qui fonctionne par souci de recherche crée de nouveaux défauts. Mesurez d'abord, décidez ensuite.