SEO JavaScript : vérifier ce que Google peut réellement lire

9 min de lecture

Le SEO JavaScript consiste à vérifier que le contenu utile et les liens d’une page restent accessibles à Google, pas seulement visibles dans votre navigateur. Pour le contrôler, comparez la réponse HTML du serveur, le DOM après exécution et le HTML rendu dans l’inspection d’URL. Cette comparaison permet de localiser un défaut d’accès, une dépendance au clic ou une erreur de rendu avant de modifier l’architecture.

Google sait exécuter JavaScript, mais cela ne garantit ni la présence de chaque contenu dans le rendu ni son indexation. Contrôlez les caractéristiques, les destinations des liens et les directives d’indexation sur une même URL.

Lire trois documents, sans confondre leurs rôles

La réponse HTML est le document envoyé par le serveur. Vous la consultez avec « Afficher le code source » ou dans la réponse de la requête principale. Le DOM est la structure courante de la page, observable dans l’onglet Éléments des outils de développement. JavaScript peut y ajouter, supprimer ou remplacer du contenu.

Google distingue exploration, rendu et indexation. Il peut exécuter JavaScript avec Chromium lorsque ses ressources le permettent ; le rendu n’est donc pas nécessairement immédiat.^[28] Une page contenant seulement une structure vide dans sa réponse initiale dépend davantage de cette exécution qu’une page dont le texte est déjà livré.

Votre navigateur ne constitue pas une preuve du rendu Google : il peut bénéficier d’une session, d’un stockage local ou d’une interaction. Le document décisif pour ce contrôle reste le HTML rendu dans l’outil Google. Un contenu absent du HTML rendu utilisé pour l’indexation ne peut pas être indexé comme contenu de la page.^[28] Son absence lors d’un test en direct ne prouve toutefois pas son absence de la version indexée, car les deux états peuvent différer.^[23]

Distinguez enfin lisibilité et indexation. Voir un texte dans ce rendu confirme sa présence au moment du test, pas son inclusion dans l’index.

Préparer un contrôle SEO JavaScript reproductible

Avant d’ouvrir Search Console, définissez précisément ce qui doit être lu. « La fiche s’affiche » est trop vague : retenez le nom du produit, une caractéristique distinctive et le lien vers une autre fiche.

Consignez dans votre relevé :

• l’URL complète, le gabarit concerné et la version déployée ;
• le texte attendu, son emplacement et sa provenance : HTML ou API ;
• les URL des scripts et de la requête qui fournit les caractéristiques ;
• les interactions nécessaires, l’existence d’une session et les règles d’accès ;
• le statut HTTP, les directives robots et la canonique déclarée.

L’ordre de contrôle proposé ici est le suivant : accès à l’URL, réponse initiale, directives d’indexation, ressources, insertion du contenu, liens, puis inspection Google.

Ouvrez d’abord l’URL directement dans une session neuve, sans clic ni défilement. Observez ensuite séparément les interactions qui changent le contenu. Conservez chaque état avec sa date et son contexte ; sinon vous comparerez des situations différentes sans le savoir.

Comparer une fiche : le tableau de diagnostic rempli

Prenons un catalogue entièrement fictif, sans référence à un client de 4SYSTEM. La fiche /catalogue/lampe-atelier fournit son titre en HTML. Les caractéristiques viennent d’une API appelée à l’ouverture de l’onglet « Caractéristiques ». Les cartes de navigation utilisent des boutons avec onclick.

Le tableau est un modèle rempli pour ce scénario. La colonne d’inspection fixe le contrôle à réaliser ; elle ne rapporte aucun test réel. Le DOM décrit correspond à l’état après ouverture de l’onglet.

Le titre peut être lisible sans que toute la fiche le soit. Réutilisez les mêmes éléments dans les trois vues. Après correction, archivez un nouveau contrôle depuis une session neuve, sans effacer l’observation initiale.

Remplacer les destinations cachées derrière onclick

Une carte qui ouvre une fiche avec un événement JavaScript n’est pas automatiquement un lien exploitable. Google indique qu’il ne peut pas extraire fiablement les URL des ancres sans href ni des autres éléments simulant des liens par événements de script.^[17]

Dans le catalogue fictif, remplacez la navigation par un véritable élément : <a href="/catalogue/lampe-orientable">Lampe orientable</a>. Le script peut toujours améliorer la transition, mais la destination existe indépendamment du gestionnaire de clic. Un bouton conserve sa place pour une action, comme ouvrir un panneau, plutôt que pour désigner une autre page.

Vérifiez trois points : la présence de l’ancre dans le HTML rendu, une destination réelle et un libellé compréhensible. Ouvrez ensuite la destination directement : le serveur doit fournir la fiche attendue, pas seulement une enveloppe applicative qui fonctionne après une navigation interne.

Les liens ajoutés par JavaScript sont également exploitables s’ils respectent ce balisage.^[17] Corrigez le composant de navigation, puis contrôlez ses déclinaisons dans les catégories et les recommandations.

Isoler la dépendance à l’API et au déclenchement

Commencez par la requête qui apporte le texte manquant. Dans l’onglet Réseau, relevez son déclencheur, son statut et le contenu de la réponse. Une réponse JSON correcte ne suffit pas : identifiez aussi l’étape qui transforme cette donnée en texte dans le DOM.

Si la requête attend un clic, proposez de charger les caractéristiques essentielles dès l’ouverture de la fiche. Si elle part automatiquement mais échoue, examinez l’accès à l’API, les contrôles d’origine, les cookies requis et les erreurs de script. Ne rendez pas une API privée publique pour résoudre un problème SEO : fournissez seulement les données destinées à la fiche publique.

Google ne rend pas le JavaScript de fichiers bloqués ni de pages bloquées.^[28] Vérifiez donc les restrictions d’exploration des ressources utiles. L’inspection en direct exige aussi une page accessible sur Internet sans connexion.^[23]

Ne fixez pas un délai supposé universel de rendu. Pour isoler une dépendance, testez une variante qui livre directement le texte essentiel, puis comparez le rendu. Cette méthode distingue un problème d’acquisition de données d’un problème d’insertion.

Interroger Search Console sans surinterpréter le test

L’inspection d’URL présente d’abord les informations de la version connue de Google, pas un état actuel de votre déploiement.^[23] Notez la date d’exploration affichée avant d’interpréter une différence. Lancez ensuite le test en direct sur exactement la même URL.

Consultez les détails de la page testée, son HTML rendu et les ressources signalées. Recherchez le texte distinctif retenu, puis le href attendu. La capture visuelle aide à comprendre l’état de la page, mais elle ne remplace pas cette recherche : un bouton visible peut rester dépourvu de lien.

Vérifiez également la réponse initiale. Si elle contient noindex alors que la fiche doit être indexable, ne comptez pas sur JavaScript pour retirer cette directive : Google peut interrompre le rendu lorsqu’il la rencontre.^[28] Corrigez la directive à son origine, sans supprimer les exclusions légitimes d’autres pages.

Un test direct valide ne garantit pas l’indexation. Il ne prédit pas non plus la canonique que Google retiendra.^[23] Si le contenu est bien rendu mais que la page reste absente, poursuivez avec le diagnostic d’une page non indexée au lieu de traiter JavaScript comme cause unique.

Choisir le correctif et définir sa validation

Décidez selon l’écart constaté. Contenu absent de la réponse initiale mais présent dans le rendu Google : la dépendance à JavaScript existe, sans défaut de lisibilité démontré. Contenu présent seulement après clic : modifiez le déclenchement. Contenu perdu après exécution : examinez le composant qui remplace le HTML. Liens sans destination : corrigez le balisage.

Le rendu serveur ou le prérendu peut fournir le texte dès la réponse HTML et réduire la dépendance au rendu JavaScript ; tous les robots ne savent pas exécuter ce dernier.^[28] C’est une option d’architecture, pas une obligation ni une promesse d’indexation. Évaluez notamment la disponibilité des données côté serveur et le risque de divergence entre les versions.

Pour fermer le ticket, consignez la modification, la version testée et les pièces de contrôle : réponse initiale, DOM sans interaction, HTML du test direct et lien vérifié. Le critère proposé est concret : le contenu attendu et sa destination sont présents sans action préalable, avec des directives cohérentes.

Vérifiez enfin une autre fiche utilisant le même composant. Conservez un suivi distinct de l’état d’indexation ; la validation technique du correctif n’est pas sa preuve.

Questions fréquentes

Le contenu d’un composant avec shadow DOM est-il invisible ?

Pas nécessairement. Google prend en charge les composants web et rassemble le contenu du shadow DOM et du light DOM lors du rendu.^[28] Pour une fiche dont les caractéristiques sont encapsulées, recherchez leur texte dans le HTML rendu de l’inspection. La seule présence du composant dans le code source ne valide pas la présence de ses données.

Pourquoi une URL redirigée semble-t-elle réussir le test ?

Le test en direct suit les redirections, mais son rapport n’indique ni qu’une redirection a été suivie ni l’URL finale testée.^[23] Contrôlez donc la chaîne de redirection dans les outils réseau et inspectez séparément la destination attendue. Sinon, vous pourriez valider le contenu d’une page différente de la fiche que vous cherchez à corriger.

Comment vérifier si Google utilise un ancien script ?

Google précise que son service de rendu peut utiliser des ressources JavaScript ou CSS anciennes à cause de son cache.^[28] Comparez les fichiers référencés par la page avec ceux du déploiement, puis vérifiez leur version dans les éléments disponibles du test. Une stratégie de noms de fichiers versionnés aide au diagnostic, sans prouver à elle seule une actualisation.

Conclusion : ouvrir un ticket vérifiable

Commencez par une fiche représentative et un contenu distinctif. Remplissez le comparatif, corrigez le premier écart établi, puis refaites le test sans interaction. Transmettez au développeur les observations et les preuves, pas seulement une capture d’écran. Pour cadrer le diagnostic et les correctifs, consultez les services web et SEO de 4SYSTEM et présentez votre URL avec ce relevé.

Sources

• SEO Link Best Practices for Google | Google Search Central  |  Documentation  |  Google for Developers (consulté le 2026-10-08)
• URL Inspection tool - Search Console Help (consulté le 2026-10-08)
• Understand JavaScript SEO Basics | Google Search Central  |  Documentation  |  Google for Developers (consulté le 2026-10-08)