Modèle d'audit SEO JavaScript

Vérification du rendu : HTML brut vs DOM rendu

Confirmez ce que Googlebot voit après l'exécution de JavaScript, et pas seulement la réponse initiale du serveur.

Comparez le code source au DOM rendu

Google récupère d'abord votre HTML brut, puis affiche la page avec un navigateur headless avant l'indexation. Comme le rendu est différé et gourmand en ressources, il peut prendre du retard sur l'exploration ; c'est donc le résultat rendu qui compte au final pour l'indexation.

Commencez par consulter la réponse HTML brute (le code source renvoyé par le serveur) et notez quels contenus, liens et métadonnées sont présents avant l'exécution de tout JavaScript. Inspectez ensuite le DOM rendu après l'exécution des scripts et comparez les deux.

• [URL de la page] auditée
• Le contenu principal du corps est-il présent dans le HTML brut ?
• Les titres, le texte et les données produit sont-ils présents dans le DOM rendu ?
• La navigation et les liens internes sont-ils présents après le rendu ?
• Le title, la meta description et la canonique sont-ils présents après le rendu ?

Signalez tout ce qui n'apparaît qu'après l'exécution de JavaScript. Ce contenu dépend entièrement d'un rendu réussi et présente donc le plus de risque. Documentez chaque écart entre le HTML brut et le DOM rendu comme un point à corriger.

Contenu et liens explorables

Assurez-vous que le contenu principal et la navigation utilisent de vrais liens explorables présents dans le DOM.

Utilisez de vrais liens et un contenu présent dans le DOM

Les moteurs de recherche suivent les liens via des éléments <a> standard dotés d'un attribut href pointant vers une véritable URL. Les liens déclenchés uniquement par un gestionnaire onclick, un bouton ou un span ne sont pas découverts de manière fiable, si bien que des pages importantes peuvent rester inexplorées.

Parcourez vos principaux templates et confirmez que chaque lien de navigation et contextuel est une véritable ancre avec un href explorable.

• La navigation principale utilise des liens [a href]
• La pagination et les filtres exposent des URL explorables
• Les liens connexes et internes sont de vraies ancres, pas du onclick
• Le contenu principal est rendu dans le DOM, pas caché derrière des interactions

Évitez de dépendre d'événements de clic, du défilement infini sans URL paginées ou d'un contenu qui ne se charge qu'après des actions utilisateur que Googlebot n'effectue pas. Si un contenu nécessite un appui ou un défilement pour apparaître, considérez-le comme à risque et fournissez-y un chemin explorable. Notez quels liens et sections passent la vérification et lesquels nécessitent un vrai href ou une présence dans le DOM.

Indexabilité : métadonnées après le rendu

Repérez les noindex, canoniques ou robots injectés par JS qui bloquent ou détournent l'indexation.

Vérifiez les métadonnées rendues, pas seulement le code source

Les directives d'indexation sont lues dans le HTML rendu, si bien que le JavaScript qui les injecte ou les modifie peut affecter discrètement la façon dont une page est indexée. Un code source propre peut tout de même livrer un noindex ou une mauvaise canonique une fois les scripts exécutés.

Pour chaque template, inspectez le DOM rendu et confirmez que les signaux d'indexation correspondent à votre intention.

• Meta robots dans le DOM rendu : [index/noindex]
• Balise canonique présente une seule fois et pointant vers l'URL voulue
• Aucun JavaScript ne remplace la canonique par une autre URL
• Le title et la meta description prennent les bonnes valeurs après le rendu
• Hreflang et données structurées présents là où c'est attendu

Les modifications de noindex ou de canonique injectées par JS sont risquées, car Google peut agir sur la valeur rendue. Soyez particulièrement vigilant avec les frameworks ou les gestionnaires de balises qui réécrivent les éléments du head. Si une directive peut changer entre l'état brut et l'état rendu, considérez cela comme un défaut et définissez-la côté serveur. Consignez les directives rendues de chaque page ainsi que tout écart.

Stratégie de rendu : CSR vs SSR vs SSG

Choisissez une approche de rendu qui rend le contenu accessible de façon fiable aux robots d'exploration.

Choisissez une stratégie de rendu qui favorise l'exploration

La façon dont vous effectuez le rendu détermine la fiabilité avec laquelle le contenu parvient aux moteurs de recherche. Comme le rendu de Google est différé, les stratégies qui livrent le contenu dans le HTML initial réduisent le risque.

• Rendu côté client (CSR) : le navigateur construit la page à partir de JavaScript. Le contenu dépend entièrement d'un rendu réussi et présente donc le plus grand risque d'indexation.
• Rendu côté serveur (SSR) : le serveur renvoie un HTML entièrement formé à chaque requête. Le contenu, les liens et les métadonnées sont présents immédiatement.
• Génération de site statique (SSG) ou prérendu : le HTML est construit à l'avance ou servi depuis une couche de prérendu, ce qui rend le contenu accessible de façon fiable avec d'excellentes performances.

Pour les pages critiques pour le SEO, privilégiez le SSR, le SSG ou le prérendu afin que le contenu figure dans le HTML initial. Réservez le CSR lourd aux zones derrière une authentification ou à faible valeur SEO.

Documentez votre approche actuelle par template, les lacunes qu'elle crée et la stratégie cible.

• Template : [nom]
• Méthode de rendu actuelle vs cible

Impact de JavaScript sur les performances

Réduisez le poids et le coût d'exécution du JS pour que les pages s'affichent vite pour les utilisateurs et les robots.

Réduisez le coût de JavaScript

Un JavaScript lourd ralentit le rendu pour les utilisateurs et alourdit le travail que les moteurs de recherche doivent accomplir pour afficher vos pages. Comme le rendu est gourmand en ressources, des pages plus légères s'affichent de façon plus fiable et se chargent plus vite, ce qui sert à la fois l'expérience et l'indexation.

Auditez la quantité de script livrée par chaque template clé et ce qu'elle bloque.

• Bundles JavaScript volumineux ou inutilisés identifiés
• Scripts bloquant le rendu différés ou fractionnés lorsque c'est possible
• Contenu critique non conditionné à une exécution lente de scripts
• Scripts tiers examinés au regard de leur poids et de leur nécessité
• Core Web Vitals examinés sur les templates clés

Privilégiez le fractionnement du code, la suppression du code inutilisé et le chargement différé des scripts non critiques afin que le contenu principal apparaisse rapidement. Ne bloquez jamais les fichiers JavaScript ou CSS dans le robots.txt, car cela empêche Google d'afficher la page telle que les utilisateurs la voient. Consignez les tailles des bundles, les ressources bloquantes et les correctifs prévus pour chaque template audité.

Tester et surveiller

Validez le rendu avec de vrais outils et gardez un œil via la Search Console dans la durée.

Testez la page rendue et surveillez-la

Vérifiez vos correctifs par rapport à ce que Google affiche réellement. L'outil d'inspection d'URL de la Search Console montre le HTML rendu et une capture d'écran de la page explorée, ce qui vous permet de confirmer que le contenu, les liens et les métadonnées sont présents après le rendu.

Passez chaque template clé par l'inspection et consignez les résultats.

• Le HTML rendu de l'inspection d'URL contient le contenu principal
• La capture d'écran rendue montre la mise en page attendue
• La navigation et les liens internes sont présents dans le HTML rendu
• Les directives d'indexation sont correctes dans le résultat rendu
• Aucune erreur signalée pendant le rendu

Passez ensuite des contrôles ponctuels à une surveillance continue.

• Suivez les rapports de couverture et d'indexation dans la Search Console
• Réinspectez après des changements majeurs de framework ou de template
• Surveillez les pages qui sortent de l'index

Consignez chaque URL testée [URL], son statut de rendu et tout suivi nécessaire, afin que les problèmes soient repérés tôt plutôt qu'après une baisse des classements.

Google peut-il indexer un contenu rendu avec JavaScript ?

Oui. Google peut exécuter JavaScript et indexer le contenu qui apparaît dans le DOM rendu. Toutefois, le rendu est différé et gourmand en ressources, il peut donc intervenir plus tard que l'exploration. Tout ce qui n'apparaît qu'après l'exécution de JavaScript dépend d'un rendu réussi, c'est pourquoi le HTML rendu côté serveur ou prérendu est plus fiable pour le contenu critique pour le SEO.

Quelle est la différence entre le HTML brut et le DOM rendu ?

Le HTML brut est la réponse initiale que votre serveur renvoie avant l'exécution de tout JavaScript. Le DOM rendu est la page après que les scripts se sont exécutés et l'ont modifiée. Googlebot récupère le HTML brut, puis affiche la page et indexe ce qu'il voit dans le résultat rendu. Auditer, c'est comparer les deux afin de savoir quel contenu atteint réellement l'index.

Pourquoi mes liens doivent-ils être de vraies balises d'ancre ?

Les moteurs de recherche découvrent et suivent les URL via des éléments d'ancre standard qui incluent un href pointant vers une véritable URL. Les liens qui ne fonctionnent que via un gestionnaire onclick, un bouton ou un span ne sont pas explorés de manière fiable, si bien que les pages qu'ils desservent peuvent ne jamais être trouvées. Exposez toujours les liens de navigation et de contenu importants comme de véritables ancres explorables dans le DOM.

Pourquoi des balises noindex ou canonique injectées par JavaScript poseraient-elles problème ?

Google lit les directives d'indexation dans le HTML rendu, si bien qu'une directive ajoutée ou modifiée par JavaScript peut prendre effet même si le code source paraît correct. Un script qui injecte un noindex ou réécrit la canonique vers la mauvaise URL peut désindexer ou détourner une page. Définir ces signaux côté serveur évite les surprises entre l'état brut et l'état rendu.

Quelle stratégie de rendu est la meilleure pour le SEO ?

Pour les pages critiques pour le SEO, privilégiez le rendu côté serveur, la génération statique ou le prérendu afin que le contenu, les liens et les métadonnées soient présents dans le HTML initial et ne dépendent pas de la construction de la page par le navigateur. Le rendu côté client est plus risqué, car le contenu repose entièrement sur le rendu. Réservez le rendu côté client lourd aux zones à faible valeur SEO ou authentifiées.

Comment confirmer ce que Googlebot affiche réellement ?

Utilisez l'outil d'inspection d'URL de la Google Search Console. Il montre le HTML rendu et une capture d'écran de la façon dont Google a exploré la page, afin que vous puissiez vérifier que le contenu, les liens internes et les directives d'indexation sont présents après le rendu. Assurez-vous aussi que le robots.txt ne bloque ni JavaScript ni CSS, et réinspectez les pages après des changements de template ou de framework.