JavaScript et SEO

Il y a encore trois ans, une phrase suffisait à clore la discussion en réunion technique. Google rend le JavaScript, donc le sujet est réglé. Elle reste vraie, et elle ne suffit plus, parce que Google n'est plus le seul destinataire de vos pages. Les robots qui alimentent les réponses génératives sont passés d'anecdotiques à structurants, et ils sont beaucoup plus rudimentaires que Googlebot.

Comment Googlebot traite le JavaScript

Le traitement se fait en deux temps, et presque tous les symptômes observés sur un site en rendu client viennent de cette séparation.

Dans un premier temps, Googlebot récupère le HTML brut renvoyé par votre serveur. Il y trouve les liens, le texte présent, les balises. Cette étape est rapide et peu coûteuse.

Dans un second temps, la page part dans une file d'attente de rendu, où une instance de Chromium l'exécute réellement, scripts compris. Le contenu produit à ce moment-là rejoint alors l'index. Cette seconde étape coûte cher en ressources, elle est donc différée, et le délai varie de quelques minutes à plusieurs jours selon l'importance accordée au site.

Deux limites persistent, même chez Google. Les liens créés par script au moment d'un clic ne sont pas suivis, et un menu de navigation qui n'existe qu'après interaction ne transmet rien. Et le contenu conditionné à une action de l'utilisateur, comme un onglet qui charge son texte au moment où on l'ouvre, n'est pas vu.

Les robots des moteurs génératifs n'exécutent rien

Deux ans après leur arrivée, ces robots restent absents de la plupart des cahiers des charges techniques. GPTBot pour OpenAI, ClaudeBot pour Anthropic, PerplexityBot pour Perplexity : tous récupèrent le HTML initial, en extraient ce qu'ils trouvent, et n'y reviennent pas. Aucun n'attend un rendu, aucun ne fait de seconde tentative.

Les mesures publiées en 2026 sont sans ambiguïté. Une analyse portant sur plus de 500 millions de récupérations de GPTBot n'a relevé aucune trace d'exécution de JavaScript. Le robot télécharge pourtant des fichiers de script dans environ 11,5 % de ses requêtes, sans jamais les exécuter. Le comportement de ClaudeBot est identique, avec un taux de téléchargement d'environ 23,8 %.

Il en résulte une situation que je qualifie de dissociation de visibilité, et que je rencontre de plus en plus souvent en audit : une application bien classée sur Google, invisible dans les réponses génératives, sans que personne dans l'entreprise ne comprenne pourquoi. Ces moteurs n'ont jamais vu autre chose qu'un écran d'attente sur leur site.

Comment vérifier ce que chacun voit

Deux contrôles suffisent, et ils prennent cinq minutes.

1. Ce que voit Google. Dans la Search Console, inspectez l'URL puis affichez le HTML rendu, celui d'après exécution. C'est la vue de Googlebot, et elle diffère souvent du code source.
2. Ce que voient les autres. Récupérez le HTML brut de la page, sans navigateur, avec un simple appel serveur. Tout ce que vous ne trouvez pas dans ce fichier est invisible pour GPTBot, ClaudeBot et PerplexityBot. Cherchez-y votre titre, votre premier paragraphe, vos liens de navigation.

L'écart entre les deux vues est votre exposition réelle. S'il est nul, il n'y a rien à faire. S'il est large, il faut arbitrer.

Les trois architectures possibles

On n'a presque jamais besoin de trancher pour tout le site. Une même application peut servir ses pages publiques en HTML assemblé et laisser le rendu client pour l'espace connecté, où aucun robot n'entre.

Le compromis que je propose en audit

Refaire l'architecture d'une application est un chantier de plusieurs mois que peu d'entreprises acceptent sur la seule promesse d'un gain de visibilité. Dans la pratique, je propose donc presque toujours une solution intermédiaire, et elle règle l'essentiel du problème pour une fraction du coût.

Le principe consiste à générer, à côté de l'application existante, une version assemblée des seules pages qui comptent pour la recherche. Sur un catalogue, ce sont les fiches produit et les pages de catégorie. Sur un site de services, une quinzaine de pages suffisent. Cette version est servie aux robots comme aux internautes, avec le même contenu, et le reste de l'application ne bouge pas.

Deux garde-fous accompagnent cette approche. Le contenu servi doit être strictement identique à celui que voit l'internaute, faute de quoi on bascule dans le cloaking, qui est sanctionné. Et la version assemblée doit se régénérer automatiquement quand la donnée change, sans quoi elle affiche des prix périmés au bout de quelques semaines.

Reste à mesurer ce que le chantier a rapporté. Le gain sur Google se lit dans la baisse du délai entre publication et indexation. Le gain côté moteurs génératifs n'apparaît dans aucun outil du marché, et il faut interroger les moteurs eux-mêmes, sur une liste de questions définie à l'avance, avant et après la bascule.

Les erreurs que je vois le plus souvent

Charger le contenu principal au défilement. Un texte injecté quand l'utilisateur descend n'existe pas pour un robot, qui ne défile pas. Cela vaut pour les listes de produits paginées à l'infini.

Confondre code source et HTML rendu. Un développeur regarde ce que renvoie le serveur, un référenceur regarde ce que voit le navigateur. Les deux ont raison, et ils ne parlent pas de la même chose. La discussion s'éclaircit dès qu'on met les deux vues côte à côte.

Bloquer les fichiers de script dans le robots.txt. C'était un réflexe d'économie de budget de crawl. Si Googlebot ne peut pas récupérer vos scripts, il rend une page cassée et indexe cette page cassée.

Injecter les balises importantes par script. Titre, description, canonique et données structurées doivent figurer dans la réponse du serveur. Injectés après coup, ils sont vus par Google au second passage et jamais par les autres.

Ce dernier point rejoint une question plus large, celle des moteurs auxquels on s'adresse. Je la traite en détail sur ma page consacrée aux autres moteurs de recherche, parce qu'elle ne concerne plus seulement le JavaScript.

Questions fréquentes