SEO et JavaScript : Problèmes courants et bonnes pratiques

Aujourd’hui, le JavaScript est omniprésent sur le Web. La plupart des sites l’intègrent pour ajouter de l’interactivité et améliorer l’expérience utilisateur.

Pourtant, la majeure partie du JavaScript présent sur de nombreux sites n’a aucun impact sur le SEO. Si vous avez une installation WordPress classique sans trop de personnalisations, il y a de fortes chances qu’aucun de ces problèmes ne vous concerne.

Les ennuis commencent lorsque le JavaScript sert à générer une page entière, à ajouter ou supprimer des éléments, ou à modifier ce qui s’y trouvait déjà. Certains sites s’en servent pour afficher leurs menus, leurs produits ou leurs prix, pour agréger du contenu issu de plusieurs sources, voire pour piloter l’intégralité du site. Si c’est votre cas, la suite va vous intéresser.

On observe aujourd’hui des systèmes et des applications entiers construits avec des frameworks JavaScript, et même des CMS traditionnels revisités à la sauce JS lorsqu’ils sont headless ou découplés. Le CMS sert de base de données en backend, mais l’affichage en frontend est géré par JavaScript.

Rassurez-vous, vous n’avez pas besoin d’apprendre à coder en JavaScript (c’est même déconseillé, car vous manipulerez rarement le code). En revanche, vous devez comprendre comment Google traite le JavaScript et comment diagnostiquer les anomalies.

Le SEO JavaScript est une branche du SEO technique visant à rendre les sites riches en JavaScript faciles à explorer, à indexer et à comprendre pour les moteurs de recherche. L’objectif : qu’ils ressortent bien dans les résultats de recherche.

Le JavaScript n’est pas mauvais pour le SEO, et ce n’est pas l’ennemi. C’est simplement différent de ce dont beaucoup de référenceurs ont l’habitude, ce qui demande un certain temps d’adaptation.

La plupart des processus seront très familiers aux professionnels du SEO, avec quelques nuances. Vous passerez toujours le plus clair de votre temps à analyser du code HTML, et non le JavaScript en lui-même.

Toutes les bonnes pratiques classiques du SEO on-page restent valables : consultez notre guide dédié.

Vous trouverez même des options familières, semblables à des extensions de CMS, pour gérer la plupart des éléments SEO de base (si ce n’est pas déjà natif dans le framework choisi). Pour les frameworks JavaScript, on parle de « modules », et il existe de nombreux paquets prêts à être installés.

Il existe des versions pour la majorité des frameworks populaires comme React, Vue, Angular et Svelte. Vous pouvez les trouver en cherchant le nom du framework suivi de « module » (par exemple, « React Helmet »). Meta tags, Helmet et Head sont des modules très répandus offrant des fonctionnalités similaires et permettant de configurer la plupart des balises utiles au SEO.

Sur certains points, le JavaScript surpasse le HTML traditionnel, notamment pour la facilité de développement et la gestion de fonctions avancées. Sur d’autres aspects, il s’avère moins performant : il ne peut pas être analysé progressivement par les navigateurs (contrairement au HTML et au CSS), et il peut alourdir les temps de chargement. Bien souvent, on sacrifie un peu de performance au profit des fonctionnalités.

Le JavaScript n’est pas parfait et n’est pas toujours l’outil idéal. Les développeurs en abusent parfois pour des tâches qui trouveraient de meilleures solutions autrement. Mais la plupart du temps, vous devrez travailler avec l’existant.

Voici les problèmes SEO les plus courants que vous pouvez rencontrer en travaillant sur des sites JavaScript.

Vous devez toujours veiller à avoir des balises Title et des méta-descriptions uniques sur l’ensemble de vos pages. Comme beaucoup de frameworks JavaScript fonctionnent avec des modèles (templates), vous pouvez facilement vous retrouver avec le même titre ou la même description dupliqués sur toutes vos pages ou toute une catégorie.

Consultez le rapport Doublons dans Site Audit d’Ahrefs et cliquez sur l’un des groupes pour afficher le détail des problèmes détectés.

Un module SEO comme Helmet vous permet de définir des balises personnalisées sur chaque page.

Le JavaScript peut aussi écraser des valeurs par défaut. Google traite ça correctement et utilise le titre ou la description modifiée. Côté utilisateur, c’est gênant : un premier titre s’affiche dans l’onglet du navigateur, puis les internautes voient un « flash » au moment où il est remplacé.

Si vous observez ce clignotement du titre, vous pouvez utiliser l’extension SEO gratuite d’Ahrefs pour comparer le code HTML brut avec la version rendue.

De toute façon, Google n’utilisera peut-être pas vos titres ou méta-descriptions. Comme évoqué, il vaut la peine de corriger les titres pour l’expérience utilisateur. Mais le faire pour les méta-descriptions ne changera pas grand-chose.

Lors de notre étude sur les réécritures par Google, nous avons constaté que Google modifie les titres dans 33,4 % des cas et les méta-descriptions dans 62,78 % des cas. Dans Site Audit, nous vous montrons même quelles balises Title Google a altérées.

Pendant des années, Google affirmait ne pas tenir compte des balises canoniques insérées via JavaScript. Il a fini par ajouter une exception dans sa documentation pour les cas où aucune balise n’était présente au départ. C’est en partie de ma faute : j’ai mené des tests démontrant que cela fonctionnait, alors même que Google soutenait le contraire.

Si une balise canonique est déjà présente et que vous en ajoutez une autre ou écrasez l’existante avec du JavaScript, vous envoyez deux balises canoniques aux moteurs. Google devra deviner laquelle utiliser, ou ignorera vos instructions au profit d’autres signaux de canonisation.

Le fameux conseil SEO stipulant que « chaque page doit avoir une balise canonique auto-référentielle » cause souvent des problèmes. Un développeur va appliquer cette consigne à la lettre, ajoutant une balise canonique auto-référentielle à la fois sur la version avec et sans slash final (trailing slash).

Ainsi, example.com/page pointe vers example.com/page et example.com/page/ pointe vers example.com/page/. C’est une erreur. Vous devriez plutôt rediriger l’une de ces versions vers l’autre.

Le même scénario peut se produire avec des URL paramétrées que vous souhaiteriez consolider, mais qui s’avèrent toutes auto-référentielles.

Pour les balises meta robots, Google applique toujours la directive la plus stricte, quel que soit son emplacement.

Si vous avez une balise « index » dans le HTML brut et une balise « noindex » dans le HTML rendu, Google la considérera comme « noindex ». Si vous avez un « noindex » dans le HTML brut, mais que vous l’écrasez par un « index » via JavaScript, la page sera quand même traitée comme « noindex ». En fait, la page « noindex » ne passera même pas par l’étape de rendu.

Même principe pour les balises « nofollow » : la directive la plus stricte l’emporte.

L’absence d’attributs alt pose un problème d’accessibilité (et même un risque légal de conformité dans de nombreux pays). Je vous conseille de les renseigner pour les images importantes du contenu, mais vous pouvez laisser l’attribut vide pour les images purement décoratives ou de remplissage.

Pour la recherche web classique, le texte des attributs alt compte comme du texte présent sur la page, mais c’est à peu près tout. Son importance globale en SEO est souvent surestimée à mon avis. Néanmoins, cela aide indéniablement pour le référencement dans la recherche d’images.

Beaucoup de développeurs JavaScript omettent les attributs alt : vérifiez donc qu’ils sont présents. Le rapport Images de Site Audit les liste.

Ne bloquez pas l’accès aux ressources si elles sont nécessaires pour construire une partie de la page ou y ajouter du contenu. Google doit pouvoir accéder à ces ressources et les télécharger afin d’effectuer le rendu de la page correctement. Dans votre fichier robots.txt, la méthode la plus simple pour autoriser l’exploration des fichiers requis est d’ajouter :

User-Agent: Googlebot
Allow: .js
Allow: .css

Vérifiez également les fichiers robots.txt des sous-domaines ou des domaines tiers vers lesquels vous effectuez des requêtes, par exemple pour vos appels API.

Si vous avez bloqué des ressources via le robots.txt, vous pouvez vérifier si cela affecte le contenu de la page en utilisant les options de blocage dans l’onglet « Réseau » (Network) des outils pour développeurs de Chrome. Sélectionnez le fichier, bloquez-le, puis rechargez la page pour voir si cela modifie l’affichage.

Sur de nombreuses pages utilisant du JavaScript, il arrive que Google ne puisse pas voir la totalité du contenu par défaut. Si vous en parlez à vos développeurs, ils vous diront peut-être que le contenu n’est pas chargé dans le DOM (Document Object Model). Cela signifie que le texte n’est pas présent initialement et qu’il nécessite une action de l’utilisateur (comme un clic) pour s’afficher.

Un test rapide consiste à isoler un extrait de votre texte et à le rechercher sur Google entre guillemets. Prenez une phrase exacte de votre contenu et regardez si votre page ressort dans les résultats. Si c’est le cas, elle a bien été vue par Google.

Vous pouvez aussi faire un clic droit et sélectionner l’option « Inspecter ». Cherchez le texte directement dans l’onglet « Éléments ».

La vérification la plus fiable reste d’explorer le contenu via l’un des outils de test de Google, comme l’outil d’inspection d’URL dans la Google Search Console. Nous en reparlerons plus loin.

Inspectez tout ce qui est caché derrière un accordéon ou un menu déroulant. Souvent, ces éléments déclenchent des requêtes pour charger le contenu uniquement lors du clic. Google ne clique pas, donc il ne le verra pas.

Si vous utilisez la méthode d’inspection pour repérer un passage, veillez à le copier, puis à recharger la page (ou à l’ouvrir en navigation privée) avant de le rechercher.

En effet, si vous avez cliqué sur l’élément et que le contenu s’est chargé à ce moment-là, vous le trouverez dans le code. Vous n’obtiendrez pas forcément le même résultat sur une page fraîchement chargée sans interaction.

Avec le JavaScript, un même contenu peut être accessible depuis plusieurs URL, ce qui génère des problèmes de contenu dupliqué. Cela peut venir de la casse (majuscules/minuscules), des slashs finaux (trailing slashes), d’identifiants, de paramètres d’URL, etc. Toutes ces adresses pourraient donc exister simultanément :

domain.com/Abc
domain.com/abc
domain.com/123
domain.com/?id=123

Si vous ne voulez indexer qu’une seule version, vous devez définir une balise canonique auto-référentielle sur celle-ci, et faire en sorte que les balises canoniques des autres variantes pointent vers la version principale. Dans l’idéal, optez pour une redirection 301 de ces variantes vers l’URL canonique.

Consultez le rapport Doublons dans Site Audit. Nous y détaillons quels groupes de pages dupliquées disposent bien d’une balise canonique et lesquels posent problème.

Problème fréquent avec les frameworks JS : la coexistence de pages avec et sans slash final. Idéalement, choisissez votre format préféré, assurez-vous qu’il possède une balise canonique auto-référentielle, puis redirigez l’autre format vers le vôtre.

Avec une architecture « App Shell », le code HTML initialement envoyé contient très peu de contenu. Il se peut même que toutes les pages du site affichent ce même code source de base, un code qui peut être identique à celui d’autres sites web.

Si vous repérez de nombreuses URL comportant très peu de mots dans Site Audit, c’est probablement le signe que vous êtes touché par ce problème.

À cause de cela, les pages sont parfois traitées comme des doublons et ne passent pas immédiatement à l’étape de rendu. Pire encore, la mauvaise page, ou même le mauvais site, peut apparaître dans les résultats de recherche. La situation se résout généralement d’elle-même avec le temps, mais cela reste problématique, surtout pour les sites récents.

Le symbole # (fragment) possède déjà une fonction native pour les navigateurs : il sert à créer une ancre vers une autre partie de la page (comme le sommaire de ce blog). En règle générale, les serveurs ne traitent rien de ce qui suit un #. Donc, pour une URL comme abc.com/#quelquechose, tout ce qui suit le # sera ignoré par le serveur.

Les développeurs JavaScript ont pourtant décidé d’utiliser le # comme déclencheur pour divers usages, ce qui crée de la confusion. Les usages les plus fréquents concernent le routage et les paramètres d’URL. Techniquement, ça marche. Pour le SEO, c’est à éviter.

Les frameworks JS intègrent souvent des routeurs pour associer leurs « routes » (chemins) à des URL propres. Beaucoup de développeurs se servent des fragments (#) pour ce routage. C’est particulièrement vrai sur Vue et sur les anciennes versions d’Angular.

Pour corriger cela sous Vue, vous pouvez demander à votre développeur d’appliquer ce changement :

Vue router:
Utiliser le mode « History » au lieu du mode « Hash » traditionnel.

const router = new VueRouter ({
mode: 'history',
router: [] //the array of router links
)}

Une tendance actuelle consiste à utiliser # au lieu de ? pour les paramètres d’URL, surtout pour le tracking passif. Je le déconseille fortement, compte tenu des problèmes que cela génère. Dans de rares cas, cela peut être tolérable si cela permet d’éliminer de nombreux paramètres superflus.

Les routeurs utilisés pour créer des URL propres incluent souvent un module de sitemap. Vous les trouverez facilement en cherchant le nom de votre framework + « router sitemap » (par exemple : « Vue router sitemap »).

La plupart des solutions de rendu intègrent aussi des fonctions de sitemap. Là encore, une simple recherche Google « nom du framework + sitemap » (ex : « Gatsby sitemap ») vous permettra de trouver un outil prêt à l’emploi.

Les frameworks JS n’étant pas exécutés côté serveur, ils ne peuvent pas renvoyer directement un code d’erreur serveur comme la fameuse 404. Pour vos pages d’erreur, deux approches s’offrent à vous :

Les référenceurs maîtrisent parfaitement les redirections 301/302, gérées côté serveur. Le JavaScript, lui, s’exécute généralement côté client (navigateur). Les redirections côté serveur et les balises meta refresh seront toujours plus faciles à traiter pour Google, qui n’aura pas besoin d’effectuer le rendu de la page pour les détecter.

Les redirections JS seront tout de même lues et suivies lors du processus de rendu. Dans la plupart des cas, ça suffit, même si ce n’est pas la méthode la plus propre. Elles sont assimilées à des redirections permanentes et transfèrent correctement l’autorité (PageRank, ou « jus de lien »).

On repère souvent ces redirections dans le code en cherchant la mention « window.location.href ». Elles peuvent aussi se trouver dans les fichiers de configuration. Par exemple, sur Next.js, une fonction dédiée permet de paramétrer les redirections. Sur d’autres systèmes, elles se trouvent directement dans le routeur.

La plupart des frameworks disposent de modules prenant en charge les attributs d’internationalisation, comme les balises hreflang. Souvent nommés i18n ou intl, ces modules sont déclinés sur les différents frameworks. Parfois, les extensions gérant les balises d’en-tête (comme Helmet) permettent aussi d’insérer ces balises linguistiques.

Nous signalons ces erreurs dans le rapport de localisation de Site Audit. Une de nos études a d’ailleurs révélé que 67 % des domaines utilisant l’attribut hreflang présentaient des erreurs.

Restez vigilant si votre site bloque ou redirige les internautes en fonction de leur pays ou de leur adresse IP. Cela peut empêcher Googlebot d’accéder à votre contenu. Si vous appliquez ce type de logique de redirection, veillez à en exclure les robots d’exploration.

Nous vous avertirons si un tel blocage se produit lors de la configuration de votre projet dans Site Audit.

Le JavaScript s’avère très utile pour générer ou injecter dynamiquement des données structurées sur vos pages. C’est une pratique courante avec le format JSON-LD, qui pose rarement problème. Effectuez tout de même quelques tests pour vous assurer que les données s’affichent correctement.

Nous répertorions les données structurées dans l’onglet Tous les problèmes de Site Audit. Cherchez l’erreur signalant un défaut de validation schema.org : nous vous indiquerons précisément la nature du problème pour chaque URL.

Tout lien pointant vers une autre page doit respecter les standards du web. Les liens internes comme externes doivent utiliser la balise <a> associée à un attribut href. En JavaScript, il existe une multitude de façons de créer des liens fonctionnels pour l’utilisateur, mais totalement illisibles pour les moteurs de recherche.

Bonne pratique :

<a href="/page">simple et efficace</a>

<a href="/page" onclick="goTo('page')">toujours valide</a>

Mauvaise pratique :

<a onclick="goTo('page')">non, pas d'attribut href</a>

<a href="javascript:goTo('page')">non, lien invalide</a>

<a href="javascript:void(0)">non, lien invalide</a>

<span onclick="goTo('page')">mauvais élément HTML</span>

<option value="page">non, mauvais élément HTML</option>

<a href="#">aucun lien de destination</a>

L’utilisation de boutons ou de directives comme ng-click est un autre exemple de mauvaise intégration.

D’expérience, Google parvient tout de même à traiter et explorer de nombreux liens mal formés. En revanche, je doute qu’ils transmettent des signaux SEO comme le PageRank avec la même efficacité. Le web est chaotique, les analyseurs de Google ont appris à être tolérants.

Gardez en tête que les liens internes générés via JavaScript ne seront détectés qu’une fois la page rendue. Le processus est généralement rapide, mais ça reste une étape supplémentaire.

Google met massivement en cache toutes les ressources. J’y reviendrai plus en détail, mais sachez que ce mécanisme peut amener le moteur à indexer des versions « impossibles » de votre page. Lors du rendu, il s’appuie parfois sur d’anciennes versions de fichiers en cache. Résultat : il indexe une page avec des morceaux de code obsolètes.

Pour contourner cela, utilisez le versionnage de fichiers ou l’empreinte numérique (ex : fichier.12345.js). Générer un nouveau nom de fichier à chaque mise à jour majeure force Google à télécharger la ressource la plus récente pour effectuer son rendu.

Il vous faudra parfois modifier votre User-Agent (agent utilisateur) pour diagnostiquer certaines erreurs. Le rendu d’un contenu peut varier selon l’User-Agent ou l’adresse IP. Assurez-vous toujours de vérifier ce que Google perçoit réellement via ses propres outils de test (que nous aborderons plus bas).

Vous pouvez définir un User-Agent personnalisé dans Chrome DevTools pour débugger les sites qui adaptent leur prérendu en fonction du visiteur. Notre barre d’outils (SEO Toolbar) vous permet également de le faire très simplement.

Certaines technologies utilisées par vos développeurs ne sont pas forcément supportées par Googlebot. Vos équipes peuvent recourir à la détection de fonctionnalités (feature detection). Si une brique est incompatible, ils auront le choix : soit désactiver cette fonction, soit mettre en place une méthode de repli à l’aide d’un polyfill pour forcer son exécution.

C’est surtout une information à destination des référenceurs. Si un élément qui devrait être indexé ne l’est pas, c’est peut-être un problème d’implémentation de ce type.

Depuis la première version de cet article, le lazy loading (chargement différé) n’est presque plus géré via JavaScript, mais nativement par les navigateurs eux-mêmes.

Vous croiserez tout de même des implémentations historiques basées sur du JS. En règle générale, elles ne posent aucun problème s’il s’agit uniquement d’images. Là où je vous invite à la prudence, c’est si du texte (contenu) est chargé en différé. Reportez-vous à la section « Vérifier que Google accède bien à votre contenu » un peu plus haut : ce type de configuration empêche régulièrement la bonne détection du texte.

Si votre site propose un défilement infini, je vous recommande vivement de maintenir une version paginée classique pour garantir une exploration optimale par Google.

J’ai aussi observé un autre problème : il arrive parfois que deux pages fusionnent dans l’index. Certains webmasters se plaignent que leur page ne s’indexe pas, alors que je finis par retrouver son contenu imbriqué dans l’indexation d’une autre URL (généralement l’article précédent).

Mon hypothèse est que lorsque Google allonge virtuellement l’écran pour son analyse (nous y reviendrons), il déclenche involontairement le scroll infini, ce qui injecte l’article suivant en plein rendu. Si vous y êtes confronté, bloquez le script responsable du scroll infini dans le robots.txt pour empêcher son déclenchement par les robots.

Les frameworks JavaScript modernes intègrent nativement d’excellents mécanismes d’optimisation des performances.

Bien que les règles fondamentales en matière de performance restent d’actualité, vous disposez de nouvelles options. Le Code Splitting fragmente les ressources en fichiers plus légers. Le Tree Shaking ne garde que le code nécessaire à la page, au lieu de charger toute l’application d’un bloc comme sur les systèmes monolithiques.

Une architecture JavaScript bien conçue est remarquablement efficace. À l’inverse, un projet mal conçu s’alourdit et les temps de chargement explosent.

N’hésitez pas à consulter notre guide sur les Core Web Vitals pour en savoir plus sur l’optimisation des temps de chargement.

Les requêtes JavaScript XHR consomment énormément de budget de crawl. Contrairement à la majorité des ressources qui profitent de la mise en cache, celles-ci sont récupérées en direct durant la phase de rendu.

Autre point : le service de rendu ignore les ressources qu’il juge inutiles pour l’affichage du contenu. S’il se trompe dans son évaluation, vous risquez de voir une partie de vos textes disparaître.

Historiquement, Google a toujours affirmé qu’il rejetait les service workers et que ces derniers ne pouvaient pas manipuler le DOM. Toutefois, Martin Splitt (de chez Google) a laissé entendre qu’il était parfois possible de contourner cette limite avec des web workers.

Googlebot gère les requêtes HTTP, mais pas les autres protocoles comme les WebSockets ou le WebRTC. Si votre plateforme repose sur ces technologies, prévoyez un mécanisme de secours en HTTP classique.

Le principal piège des sites JS : ils ne rafraîchissent que partiellement le DOM. En tant qu’utilisateur, naviguer d’une page à l’autre ne mettra pas toujours à jour certaines balises (comme la balise Title ou canonique) dans le DOM, ce qui n’est pas forcément un problème pour les moteurs de recherche.

Google traite chaque page de manière isolée (« stateless »), comme s’il s’agissait d’un tout premier chargement. Il ne conserve aucune donnée de la session précédente et ne simule pas un parcours utilisateur de page en page.

J’ai souvent vu des référenceurs s’inquiéter à tort d’une balise canonique figée après un clic vers une autre page. En réalité, Google ne sera jamais confronté à ce cas de figure précis.

Les développeurs peuvent combler cette lacune en forçant la mise à jour de l’état via l’API History. Mais, je le répète, ce n’est généralement pas un problème bloquant. Les référenceurs alertent souvent les développeurs pour des détails sans importance. Appuyez sur F5 pour rafraîchir la page et observez le résultat : c’est ce qui importe. Encore mieux : analysez-la via les outils de Google.

En parlant des outils de test de Google, faisons un petit tour d’horizon.

Google propose plusieurs interfaces pertinentes pour le JavaScript.

C’est votre outil de référence. En inspectant une URL, vous voyez exactement ce que Google voit, incluant le code HTML tel qu’il a été rendu par ses propres systèmes.

Vous avez également la possibilité d’exécuter un test en direct.

Gardez à l’esprit qu’il existe quelques disparités entre le service de rendu principal (celui qui indexe vos pages) et le test en direct. Le moteur d’indexation utilise des ressources en cache et se montre très patient. Les outils de test en direct, eux, chargent les ressources en temps réel et coupent l’analyse plus tôt pour ne pas vous faire attendre (nous reviendrons sur ce point).

Par ailleurs, les captures d’écran fournies par ces outils affichent le rendu final avec les pixels peints (l’interface visuelle), étape que Google s’épargne lors de son véritable processus de rendu.

Ces outils restent précieux pour vérifier que le contenu est bien dans le DOM. Le code HTML affiché correspond au DOM tel qu’il a été généré. Vous pouvez donc y chercher un bout de texte pour vous assurer qu’il se charge par défaut.

Ils identifieront aussi d’éventuelles ressources bloquées et afficheront les erreurs de la console, ce qui s’avère précieux pour le dépannage.

Astuce : même sans accès à la Search Console d’un site, vous pouvez tester ses URL. Il suffit de créer une redirection depuis l’un de vos propres sites (dont vous possédez l’accès GSC) vers le domaine ciblé. Inspectez votre URL : l’outil suit la redirection et analyse la page externe.

Dans la capture d’écran ci-dessous, j’ai redirigé une URL de mon site vers la page d’accueil de Google. Le test en direct a suivi la redirection et affiche la home de Google. (Et non, je n’ai malheureusement pas les clés de la Search Console de Google).

L’outil de test des résultats enrichis affiche le rendu de votre page tel que Googlebot le voit sur mobile ou sur ordinateur.

Note de mise à jour : l’outil d’optimisation mobile ayant été définitivement retiré par Google en décembre 2023, ces tests s’effectuent désormais via les autres outils de la Search Console.

Ahrefs effectue le rendu des pages lors du crawl. Nous collectons ainsi des données sur les sites JS que les autres outils ne captent pas. Nous rendons près de 200 millions de pages par jour (une fraction de notre volume d’exploration total).

Nous repérons les redirections JavaScript et les liens ajoutés dynamiquement, que nous marquons avec un libellé “JS” dans nos rapports de backlinks :

Dans les menus déroulants de Site Explorer, notre option d’inspection compare une page avec ses explorations précédentes. Vous y trouverez ce même badge “JS” si le rendu JavaScript était activé lors de l’analyse.

Vous pouvez tout à fait cocher l’option JavaScript lors des crawls de Site Audit pour des audits plus complets.

Lorsque le rendu JavaScript est activé, nous capturons simultanément le code source brut et le code rendu pour chaque URL. En cliquant sur la loupe face à une adresse dans l’Explorateur de pages, puis sur « Voir le code source », vous accéderez à ces deux versions. Une fonction de recherche permet même de chercher dans le code brut et rendu de tout le site.

En croisant les données d’un crawl statique (sans JS) et d’un crawl dynamique (avec JS), nos outils de comparaison affichent toutes les différences.

La SEO Toolbar d’Ahrefs supporte le JavaScript et compare instantanément les balises du code source brut avec leur version rendue.

Lors d’un clic droit dans votre navigateur, deux options s’affichent : « Afficher le code source de la page » (View source) et « Inspecter » (Inspect). Le code source montre la réponse brute du serveur à une requête GET : le HTML avant exécution du JavaScript.

L’option « Inspecter » montre le DOM après exécution des scripts. C’est bien plus proche de ce que Googlebot analyse.

Sur un site JS, privilégiez « Inspecter ».

Comme Google analyse à la fois le code brut et la version rendue pour certains éléments, un coup d’œil au code brut reste nécessaire. Par exemple, si les outils de Google indiquent qu’une page est en « noindex », mais que la version rendue en est dépourvue, c’est que la directive était dans le code brut avant d’être écrasée par le script.

En cas de balises noindex, nofollow ou canoniques contradictoires, analysez le code source. Google appliquera toujours la directive meta robots la plus stricte, et ignorera vos directives canoniques si le code renvoie des signaux contradictoires.

C’est un conseil obsolète que j’entends encore beaucoup trop souvent. Google exécute bel et bien le JavaScript : désactiver le JS de votre navigateur pour « voir comme Google » n’a aucun sens.

Le système de cache de Google ne reflète en rien la perception du bot. La vue en cache n’est qu’une capture figée du HTML brut. C’est votre propre navigateur qui exécute ensuite le JavaScript référencé dans ce HTML. Le résultat est faussé.

Pour ne rien arranger, les politiques CORS (Cross-Origin Resource Sharing) bloquent régulièrement le chargement de ressources depuis un domaine tiers.

Le cache étant hébergé sur webcache.googleusercontent.com, si ce nom de domaine tente de solliciter des scripts sur le site d’origine, la règle CORS bloquera la requête. Les fichiers ne se chargeront pas et la page apparaîtra cassée dans la vue en cache.

Cette fonctionnalité a été conçue pour afficher une version texte de la page en cas de panne du serveur, pas comme un outil de diagnostic.

Aux débuts du web, la simple réponse HTML du serveur suffisait aux moteurs pour analyser le contenu. Avec le JavaScript partout, ils doivent désormais simuler un navigateur complet pour « voir » les pages de la même manière qu’un visiteur humain.

Chez Google, c’est le rôle du Web Rendering Service (WRS). Le schéma ci-dessous, fourni par Google, illustre de manière simplifiée ce flux de travail.

Voyons le processus étape par étape, en partant d’une URL fraîchement découverte.

Le robot d’exploration initie une requête GET vers le serveur. Ce dernier lui retourne les en-têtes (headers) et le code du fichier, que Google sauvegarde instantanément.

Cette visite provient le plus souvent d’un User-Agent mobile (Google ayant basculé sur l’indexation « mobile-first »), bien que l’analyse via l’User-Agent Desktop reste active en parallèle.

La plupart de ces requêtes viennent de Mountain View (Californie), avec quelques crawls localisés pour tester l’adaptation linguistique. Comme vu plus haut, bloquer par pays ou par IP peut donc bloquer Googlebot.

Le schéma de Google parle de sortie « HTML », mais en réalité le robot capture et stocke toutes les ressources de la page (HTML, JS, CSS). Notez aussi la limite de 15 Mo sur les fichiers HTML.

Derrière l’étiquette « Processing » du schéma se cachent de nombreux systèmes. Concentrons-nous sur ceux ayant trait au JavaScript.

À l’inverse d’un humain, Google ne navigue pas en sautant de lien en lien. Lors du traitement, il extrait tous les liens internes et les chemins des fichiers nécessaires à la construction de la page. Ces URL rejoignent ensuite la file d’attente de crawl.

Google s’appuie sur les balises <link> pour identifier les ressources de la page (CSS, JS, etc.).

Comme nous l’avons évoqué, les liens internes construits en JS ne seront repérés qu’une fois le rendu terminé. Le processus est assez rapide pour passer inaperçu, sauf pour les sites d’actualités où chaque seconde compte.

Google met en cache de façon agressive tout ce qu’il télécharge (HTML, JS, CSS). Il ignore vos délais de cache et récupère une nouvelle version quand il le décide. Ce point est important pour la suite, j’y reviendrai dans la section sur le moteur de rendu.

Les doublons stricts peuvent être écartés ou déclassés directement depuis le flux HTML, avant même d’atteindre le moteur de rendu (voir la section sur les contenus dupliqués).

Entre le code brut et le code rendu, la directive la plus stricte l’emporte. Un « noindex » écrase un « index », et un « noindex » dans le HTML brut exclut la page de l’étape de rendu.

L’indexation en deux temps (HTML brut, puis version rendue) inquiète souvent les référenceurs. Beaucoup craignent que le rendu prenne des jours, voire des semaines. Les mesures de Google disent le contraire : le délai médian de passage en rendu s’établit à 5 secondes, avec 90 % des pages traitées en quelques minutes. Dans la grande majorité des cas, ce délai est négligeable.

Attention : toutes les pages n’atteignent pas l’étape du rendu. Comme vu plus haut, un « noindex » écarte la page. Google ne dépense pas de ressources de rendu pour une page qu’il n’indexera pas.

Google applique aussi des filtres de qualité. Si les premiers signaux ou le HTML brut indiquent un contenu de faible valeur, la page ne sera pas rendue.

Exception pour les sites d’actualités : Google indexe d’abord rapidement à partir du HTML brut, puis complète son analyse après le rendu.

Le service de rendu, c’est là que Google voit la page comme un visiteur. Le moteur exécute le JavaScript et applique toutes les modifications apportées au DOM.

Il utilise un Chrome headless « evergreen », toujours aligné sur la dernière version de Chrome. Il y a encore quelques années, Google tournait sur un vieux Chrome 41 incapable de gérer les fonctionnalités modernes.

La documentation officielle de Google apporte davantage de précisions techniques sur le WRS (gestion des permissions, fonctionnement sans état, aplatissement des Light et Shadow DOM, etc.). Sa lecture est fortement recommandée.

Faire tourner un tel service de rendu à l’échelle du web est un exploit technique. Pour tenir la charge, Google prend des raccourcis.

Tout repose sur le cache. Les URL sont en cache. Les fichiers sont en cache. Quasiment tout passe par le cache avant d’atteindre le moteur de rendu. Télécharger chaque ressource à la demande serait ingérable, pour Google comme pour vos serveurs.

Seuls les appels XHR échappent à cette règle : ils sont traités en temps réel.

Un vieux mythe SEO prétend que Google abandonne si votre page ne charge pas en 5 secondes. Un site rapide reste indispensable, mais ce mythe ne colle pas avec le fonctionnement du cache décrit plus haut. Lors du rendu, Google dispose déjà de tous les fichiers nécessaires sur ses propres serveurs.

Avec une vraie limite de 5 secondes, une énorme partie du web serait absente de l’index de Google.

Cette rumeur vient probablement des outils de test de la Search Console. Là, Google désactive le cache et charge les fichiers en direct, car il doit vous renvoyer un résultat rapidement. Elle s’est aussi nourrie des faibles priorités de crawl de certains domaines, qui laissaient croire que le rendu traînait pendant des jours.

Retenez qu’il n’y a pas de compte à rebours. Le service de rendu simule l’écoulement du temps pour capter les chargements différés. Il surveille aussi la boucle d’événements du navigateur pour savoir quand plus rien ne se passe. Il est patient. Le chrono n’est pas votre problème.

Il existe quand même des garde-fous contre les boucles infinies et le minage de cryptomonnaies clandestin. Oui, vous avez bien lu. Nous avons dû protéger notre propre moteur de recherche contre ce phénomène, qui a fait l’objet d’une de nos études.

Googlebot observe, il n’interagit pas. Il ne clique pas sur vos menus et ne fait pas défiler la page. Il a toutefois quelques astuces. Si un élément est dans le DOM sans exiger d’action, Google le récupère. Si son affichage nécessite une interaction, le contenu est ignoré.

S’il ne scrolle pas, comment accède-t-il au bas de page ? Simple : sur mobile, il charge la page dans une fenêtre de 411x731 pixels… qu’il étire ensuite jusqu’à 12 140 pixels de haut.

En clair, le robot navigue avec un smartphone géant. Même méthode sur ordinateur, en passant d’un affichage de 1024x768 à 1024x9307 pixels. Ces valeurs n’ont pas été revérifiées récemment et pourraient s’adapter à la longueur de la page.

Le plus gros gain de performance : Google ne peint pas les pixels. Cette étape consomme beaucoup de ressources, et le moteur n’a pas besoin du rendu visuel final de la page. (Et puis, avec l’envolée des prix des cartes graphiques, pillées par le gaming, la crypto et l’IA, on le comprend !).

Il se concentre sur la structure et le contenu du document, sans afficher le moindre pixel. Martin Splitt l’explique :

Un graphique le montre bien. Dans l’onglet « Performances » de Chrome DevTools, le rendu d’une page s’affiche sur une frise chronologique. La partie verte correspond à la phase d’affichage (le « paint »). En sautant cette étape, Googlebot économise énormément de ressources.

Gris = Téléchargements
Bleu = HTML
Jaune = JavaScript
Violet = Structure (Layout)
Vert = Affichage (Painting)

Google met à disposition une documentation complète sur le budget de crawl. Retenez que ce quota est propre à chaque site et que chaque URL reçoit une priorité. Google arbitre en permanence entre vos URL et le reste du web.

Les sites récents et ceux qui génèrent beaucoup de pages dynamiques seront crawlés plus lentement. Avec le temps, Google ajuste sa fréquence de crawl au rythme de mise à jour de vos pages et de vos fichiers.

Il existe de nombreuses options pour le rendu JavaScript. Plutôt que de les lister, je vous renvoie à ce tableau récapitulatif de Google. Retenez l’essentiel : le SSR (Server-Side Rendering), le rendu statique et le pré-rendu fonctionnent très bien avec les moteurs de recherche. Des outils comme Gatsby, Next ou Nuxt sont recommandés.

Le seul modèle réellement problématique reste le rendu 100 % côté client (Client-Side Rendering), où le navigateur prend en charge l’intégralité des opérations. Google arrivera sans doute à traiter votre page, mais ce choix ruinera votre visibilité sur les autres moteurs de recherche.

Bing supporte le rendu JS, bien que sa capacité réelle soit floue. D’après mes observations, Yandex et Baidu le gèrent mal. La plupart des autres moteurs ne le gèrent pas du tout. Notre propre moteur de recherche, Yep, possède un module de rendu d’une capacité d’environ 200 millions de pages/jour, ce qui reste bien inférieur à notre rythme de crawl global.

Reste le rendu dynamique, qui sert une version différente selon l’User-Agent. C’est du bricolage. Je l’ai toujours déconseillé, et Google le déconseille désormais aussi.

Rares sont les cas qui le justifient, par exemple pour les bots des réseaux sociaux qui n’exécutent pas le JS. Sans rendu préalable, ils ne verront pas vos balises Open Graph.

À l’échelle d’un site, ça multiplie les problèmes SEO. Et soyons honnêtes : c’est du cloaking, quoi qu’en dise Google.

Le JavaScript n’a pas à être le cauchemar des référenceurs. J’espère que ces explications vous aideront à mieux le maîtriser.

Allez discuter avec vos développeurs. Ce sont vos meilleurs alliés pour faire d’un site JS un atout SEO.

Si vous avez des questions, contactez-nous sur LinkedIn pour les francophones.