Un site qui s'affiche grâce à JavaScript est-il lisible par Google et les assistants IA ?

Mis à jour le 27 septembre 2026 · Guillaume Micallef, Velyria

Google sait exécuter JavaScript : il met les pages en file de rendu, puis les indexe à partir du HTML obtenu. Mais ce rendu peut prendre plus que quelques secondes, et Google écrit lui-même que tous les robots ne savent pas exécuter JavaScript. Le plus sûr est que vos services, votre ville et vos coordonnées figurent déjà dans le HTML envoyé par le serveur.

Comment Google traite un site en JavaScript

La documentation de Google Search Central sur les bases du référencement JavaScript décrit trois phases : l'exploration, le rendu et l'indexation. Google commence par lire le robots.txt. Il précise que la Recherche n'exécute pas le JavaScript des fichiers bloqués ni des pages bloquées : si votre robots.txt interdit le dossier des scripts, le contenu qu'ils produisent peut rester invisible.

Les pages qui répondent avec un code 200 sont mises en file d'attente pour le rendu. Selon Google, une page peut y rester quelques secondes, mais « cela peut prendre plus de temps ». Quand les ressources le permettent, un Chromium sans écran exécute le JavaScript, et Google analyse le HTML obtenu pour y chercher des liens et indexer la page. Autrement dit, ce qui compte pour l'indexation est le HTML rendu, pas seulement celui que le serveur envoie au départ.

Pourquoi ne pas tout miser sur le rendu

Dans la même page, Google recommande le rendu côté serveur ou le pré-rendu, parce que cela rend le site plus rapide pour les internautes comme pour les robots, et parce que tous les robots ne savent pas exécuter JavaScript. Cette remarque vaut surtout pour les assistants IA : la documentation de Google ne décrit que le comportement de Google, et aucune des sources consultées pour cet article ne dit comment chaque robot d'assistant traite les scripts. Le raisonnement prudent est donc le suivant : ce qui est présent dès le HTML de départ est lisible par tous, ce qui dépend d'un script l'est seulement par ceux qui l'exécutent.

Pour une entreprise locale, cela concerne en premier lieu quatre éléments : la présentation de l'activité, la liste des services, la ville ou la zone d'intervention, et les coordonnées. Si l'un d'eux n'apparaît qu'après le chargement d'un script, un robot qui n'exécute pas JavaScript ne le verra pas. Le guide Données structurées LocalBusiness explique comment décrire ces informations de façon lisible par une machine.

Les pièges propres aux sites construits avec des scripts

• Les liens. Google précise qu'il ne découvre vos liens que s'ils sont des éléments HTML a avec un attribut href. Un bouton ou un élément cliquable qui change de page par script, sans vrai lien, n'est pas suivi.
• Les adresses. Pour passer d'une vue à l'autre dans une application, Google conseille l'API History. Il déconseille d'utiliser les fragments (la partie de l'adresse après le dièse) pour charger un contenu différent.
• La consigne noindex. Google indique que, lorsqu'il rencontre noindex, il peut ne pas faire le rendu ni exécuter le JavaScript. Retirer ou modifier une balise robots noindex par script peut donc ne pas fonctionner comme prévu : si une page doit être indexée, la balise ne doit pas contenir noindex dans le HTML de départ.
• Les pages d'erreur. Avec un affichage côté navigateur, une page inexistante peut répondre 200 avec un message d'erreur (soft 404). Google propose soit de rediriger par script vers une adresse qui répond réellement 404, soit d'ajouter une balise noindex aux pages d'erreur.

Vérifier ce que Google voit réellement

Google indique que son moteur ne voit que ce qui figure dans le HTML rendu, et recommande de contrôler ce HTML avec le test des résultats enrichis ou l'outil d'inspection d'URL. L'aide de la Search Console précise que l'inspection d'URL peut s'exécuter en test en direct : l'outil récupère alors l'adresse en temps réel, et affiche le HTML renvoyé, les en-têtes, les messages de la console JavaScript et les ressources chargées. La capture d'écran de la page rendue n'est disponible que dans ce test en direct. Sans test en direct, les résultats viennent de la dernière version indexée, pas de la version actuellement en ligne.

La démarche tient en quatre gestes :

1. Dans la Search Console, inspectez l'adresse de votre page d'accueil, puis lancez le test en direct.
2. Affichez la page testée et vérifiez que votre texte, vos services et vos liens y figurent.
3. Comparez avec le code source brut de la page (affichage du code source dans le navigateur) : ce qui manque du code source mais apparaît dans le rendu dépend d'un script.
4. Pour ce qui dépend d'un script, demandez à votre prestataire un rendu côté serveur ou un pré-rendu, au moins pour les pages qui portent vos services et vos coordonnées.

Ce que cela change pour apparaître dans les réponses d'un assistant

Être lisible n'est qu'une condition de départ : les accès des robots, décrits dans Robots.txt : faut-il autoriser GPTBot, OAI-SearchBot, PerplexityBot et ClaudeBot ?, et l'indexation par Google restent à vérifier. Aucune de ces vérifications ne garantit d'être cité : elles évitent seulement qu'un blocage technique vous écarte avant même que le contenu soit examiné.

Contrôler le texte visible sans script

Lisible, un service Velyria, regarde votre page d'accueil comme le ferait un robot qui n'exécute pas JavaScript : il vérifie si le texte de présentation est présent dans le HTML de départ, en plus du robots.txt et des données structurées. Lancez l'audit gratuit de votre site avec Lisible pour savoir ce qui est lisible sans script, puis consultez le rapport du service pour connaître vos priorités.