JavaScript SEO

Ce que le JavaScript SEO recouvre vraiment

La question opérationnelle n'est jamais « mon site utilise-t-il du JavaScript ». Tous les sites en utilisent. La question est : quelle part du contenu, des liens internes et des balises de tête n'existe que dans le DOM final, après exécution du script. Le test tient en trente secondes : récupérez la réponse brute du serveur en ligne de commande et cherchez-y une phrase précise du corps de l'article, ou l'URL d'un lien de navigation. Si la chaîne est absente du HTML servi mais présente dans l'inspecteur du navigateur, cette information dépend du rendu, donc d'un robot qui accepte de le faire.

La vidéo officielle de Google Search Central pose le cadre en quelques minutes, avant d'entrer dans la mécanique :

Le JavaScript SEO n'est pas une discipline à part, c'est du SEO technique appliqué à un décalage temporel : celui qui sépare la réponse HTTP initiale du DOM final. Trois choses circulent dans ce décalage, et elles n'ont pas la même valeur. Le contenu indexable, d'abord, parce qu'une page dont le corps arrive en seconde vague est une page dont le positionnement démarre en retard. Les liens, ensuite, parce qu'ils portent à la fois la découverte d'URL et la circulation du PageRank interne. Les signaux de tête enfin : title, meta robots, canonical, données structurées, qui gouvernent l'indexation elle-même.

Sur le millésime 2026, un point de doctrine mérite d'être posé net. Google a supprimé le 4 mars 2026 la section accessibilité de sa page JavaScript SEO Basics, celle qui conseillait depuis des années de tester son site avec JavaScript désactivé, en la qualifiant de périmée (Search Engine Land, mars 2026). C'était la cinquième mise à jour de cette page depuis décembre 2024. Beaucoup l'ont lue comme un feu vert : le JavaScript ne serait plus un sujet. C'est l'inverse. Google reconnaît que son propre moteur de rendu, sur Chromium evergreen depuis 2019, fait le travail. Il ne dit rien du reste de l'écosystème de robots, et c'est précisément là que le problème s'est déplacé.

CSR, SSR, SSG : l'arbitrage se joue sur le HTML initial

Le vocabulaire est connu, l'arbitrage l'est moins. En rendu côté client (client-side rendering), le serveur renvoie une coquille quasi vide et le navigateur construit la page. En rendu côté serveur, le serveur renvoie du HTML complet, que le JavaScript vient ensuite hydrater pour rendre interactif. En génération statique, le HTML est calculé au build et servi tel quel depuis un CDN. Le pré-rendu et le dynamic rendering, longtemps vendus comme rustines, ne sont plus des cibles d'architecture : Google les tolère, il ne les recommande plus.

La position que nous défendons est simple : en 2026, le client-side rendering pur sur une page censée ranker n'est plus défendable. Pas parce que Google échoue à la rendre, il y arrive la plupart du temps, mais parce que le coût du retard et la fragilité de la chaîne ne sont compensés par aucun gain. L'éditorial et les pages de contenu vont en statique. Les catalogues avec état, filtres et stock temps réel vont en rendu serveur, avec des URL propres et indexables pour chaque combinaison qui mérite d'exister. Le rendu client se réserve aux zones derrière authentification, aux tableaux de bord, à tout ce qui n'a de toute façon pas vocation à être indexé. L'arbitrage se fait par route, pas par site : une application peut parfaitement servir sa homepage et ses fiches en statique et son espace client en client-side.

L'hydratation, elle, se paie ailleurs. Un HTML complet qui arrive vite mais dont le JavaScript bloque le thread principal pendant deux secondes produit une page correcte pour l'indexation et mauvaise pour l'expérience. C'est exactement ce que mesurent les indicateurs de performance perçue de Google, et en particulier le délai de réponse aux interactions, que l'hydratation dégrade plus sûrement que n'importe quelle image mal compressée. Dernier point d'architecture souvent négligé : le routage par fragment, du type /#/produit/123, reste non explorable, puisque la partie située après le dièse n'est jamais transmise au serveur. Aucun robot ne peut demander cette URL. Si votre application en dépend encore, la question du rendu passe après celle du routage.

Comment Google crawle, rend et indexe le JavaScript

Le modèle à garder en tête est celui des deux vagues. Googlebot récupère d'abord la réponse HTTP, en extrait ce qu'il peut immédiatement, puis place la page dans une file d'attente de rendu servie par un Chromium sans interface. Seules les pages qui répondent 200 et ne sont pas bloquées par une directive robots entrent dans cette file. Le temps d'attente, selon la documentation Google, va de quelques secondes à bien davantage selon les ressources disponibles. Une fois rendue, la page est réanalysée : nouveau contenu, nouveaux liens, nouvelles balises.

Google détaille lui-même ce processus d'indexation en deux temps :

Ce délai n'est pas gratuit, et c'est là que le raisonnement en budget de crawl devient concret. Le rendu d'une page JavaScript coûterait à un moteur environ cent fois plus de ressources que le traitement du HTML statique équivalent, un ordre de grandeur attribué à Conductor Academy et repris par les guides techniques 2026. Sur un site de trois cents pages, personne ne le sent. Sur un catalogue de cent mille URL, cela signifie mécaniquement moins de pages rendues par unité de temps. Un guide consacré aux applications monopages publié en 2026 évoque des cas où trois à six semaines s'écoulent avant que certaines pages soient rendues, et note que les sites à faible autorité peuvent ne jamais voir l'intégralité de leur JavaScript exécutée à grande échelle. C'est cohérent avec ce qu'on observe en audit : le retard de rendu frappe d'abord les domaines qui ont le moins de crédit auprès du moteur, donc précisément ceux qui auraient besoin que tout aille vite.

Pour mesurer, trois outils suffisent. L'inspection d'URL dans la Search Console, en test en direct, montre le HTML rendu par Google et les ressources qu'il n'a pas pu charger : c'est la source de vérité. Un crawler configuré en mode rendu JavaScript permet de comparer, à l'échelle du site, le HTML brut et le DOM rendu, et de sortir la liste des liens qui n'existent que dans le second. Les journaux serveur, enfin, disent qui passe réellement et à quelle fréquence, ce qu'aucun outil de simulation ne remplace.

Les crawlers IA ne rendent pas le JavaScript

C'est le déplacement majeur de ces dix-huit mois, et il change la façon dont on conçoit un lien. L'étude Vercel/MERJ publiée le 17 décembre 2024, fondée sur plus de 500 millions de requêtes GPTBot analysées dans des journaux serveur, conclut qu'aucun des grands robots d'IA n'exécute de JavaScript. GPTBot téléchargeait des fichiers JavaScript dans environ 11,5 % de ses requêtes et ClaudeBot dans environ 23,8 %, sans la moindre trace d'exécution. Les relevés de Lantern de juin 2026 confirment le constat pour GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot, Meta-ExternalAgent et Bytespider.

Le volume interdit de traiter ça comme un détail. Une analyse fondée sur Cloudflare Radar publiée en 2026 attribue environ 48 % du trafic de bots mondial à Googlebot, 12 % à GPTBot et 9,2 % à ClaudeBot, ce qui place ces deux derniers au niveau de Bingbot ou au-dessus. Et la qualité du trafic renvoyé suit : Lantern mesure un taux de conversion de 14,2 % pour les visiteurs venus d'une réponse d'IA, contre 2,8 % pour un clic organique Google standard.

La conséquence pour une opération de netlinking est directe et rarement formulée. Un lien inséré côté client, dans un bloc « articles liés » alimenté par une API, dans un widget de recommandation, dans un carrousel monté après coup, existe pour l'utilisateur, existe pour Google avec un retard variable, et n'existe pas du tout pour les modèles qui construisent aujourd'hui leurs réponses. Vous avez payé pour un lien que la moitié de l'écosystème ne verra jamais. C'est une raison de fond pour laquelle nous servons du HTML statique sur nos médias : le lien est dans la réponse initiale, point. Quand vous étudiez le catalogue de médias consultable sans inscription, la vérification prend une seconde, il suffit de regarder le code source d'un article existant. Et si un éditeur vous propose un emplacement dont le lien n'apparaît qu'après exécution du script, ce n'est pas un détail technique, c'est un argument de négociation sur ce que vaut réellement l'emplacement.

Ce qui casse vraiment en audit

Le canonical arrive en tête, et de loin. Google a précisé sa doctrine en décembre 2025 : le meilleur endroit pour déclarer une URL canonique reste le HTML, et si vous devez passer par JavaScript, la valeur posée doit être identique à celle du HTML d'origine. Le canonical est traité avant et après rendu, donc un conflit entre les deux versions crée une ambiguïté que le moteur tranche seul, rarement dans votre sens. L'ampleur du problème est documentée : une analyse fondée sur HTTP Archive, citée par Search Engine Land en avril 2026, relève que 2 à 3 % des pages rendues présentent un canonical modifié après exécution du script, et que la part des pages avec un canonical valide décline sur le web depuis novembre 2024. Les facteurs avancés sont des CMS récents mal configurés et des sites construits à la va-vite avec des outils assistés par IA, où un script mute la balise après le rendu.

Vient ensuite la famille des pages non-200. Le JavaScript n'est pas nécessairement exécuté sur une réponse qui n'est pas 200, ce qui condamne les 404 personnalisées dont la navigation est montée côté client : le robot arrive sur un cul-de-sac. Les applications monopages ajoutent leur variante, le soft 404, où une URL inexistante répond 200 avec un message d'erreur affiché par le script. Google indexe alors une page vide ou la déduplique avec la homepage, et vous perdez le contrôle du signal.

Le reste est une liste de gestes qu'on voit se répéter. Bloquer dans le robots.txt le répertoire qui contient les bundles, ce qui revient à demander un rendu en interdisant les ingrédients. Poser les liens de navigation sur des éléments non cliquables au sens HTML, un span avec un gestionnaire d'événement au lieu d'une balise avec un attribut href, ce qui les rend invisibles à la découverte. Charger les images ou les blocs de contenu à l'apparition dans le viewport sans repli, alors qu'un robot ne fait pas défiler la page. Injecter les titres et méta-descriptions côté client, ce qui les rend dépendantes du rendu pour un gain nul. Manipuler l'historique du navigateur sans que chaque état atteignable corresponde à une URL réelle que le serveur sait servir.

React, Angular, Vue : ce que le framework change vraiment

La question « quel framework JavaScript est le meilleur pour le SEO » est mal posée, et elle occupe pourtant une part importante des pages qui se positionnent sur le sujet. Aucun framework n'est bon ou mauvais pour le référencement. Ce qui compte, c'est le mode de rendu que vous en tirez, et tous les grands frameworks proposent aujourd'hui les trois modes. La ressource officielle de Google sur React, ci-dessous, tourne d'ailleurs entièrement autour de cette bascule et jamais autour de la bibliothèque elle-même :

React seul, monté avec un simple point d'entrée client, produit une coquille vide : c'est le pire scénario, et c'est encore le plus répandu dans les projets internes. Le même React sous Next.js, en génération statique ou en rendu serveur, produit un HTML complet indiscernable d'un site classique. Angular a son rendu serveur intégré, Vue a le sien via Nuxt, et les approches à îlots ne chargent du JavaScript que sur les composants qui en ont besoin, ce qui limite mécaniquement la surface de risque. Le critère de choix pertinent est donc la compétence de l'équipe, l'écosystème et la maintenabilité. Le critère SEO se réduit à une seule exigence : le HTML servi contient-il le contenu, les liens et les balises de tête.

La vérification finale ne demande aucun outil. Affichez le code source de la page, pas l'inspecteur, et cherchez le titre de l'article, trois liens internes, la balise canonical et le bloc de données structurées. S'ils y sont, votre architecture est saine quel que soit le framework. S'ils n'y sont pas, aucune optimisation de contenu ne rattrapera ce qui manque en amont, et le netlinking que vous financerez viendra pousser une page que la moitié des robots lit comme une coquille.