JavaScript SEO : pourquoi Google ne voit parfois pas votre contenu

Le JavaScript SEO consiste à faire en sorte que les moteurs de recherche voient le contenu que votre JavaScript affiche à l’écran. La réponse courte : Google rend bien le JavaScript, mais pas toujours comme vous le pensez, et si le rendu échoue, Google n’indexe pas votre contenu. Presque tous les sites modernes tournent au JavaScript (selon W3Techs, 98,9 % de tous les sites web l’utilisent), donc cela concerne pratiquement tout le monde. Dans cet article, vous découvrez quels problèmes de rendu reviennent le plus souvent, comment les détecter et comment les corriger sans attendre des mois.

Mesurez-le vous-même : passez votre page dans notre test de vitesse de site gratuit et examinez vos Core Web Vitals.

Qu’est-ce que le rendu JavaScript et pourquoi compte-t-il pour le SEO ?

Une page existe en deux versions. Le HTML brut est ce que le serveur envoie avant que le JavaScript ne s’exécute. Le HTML rendu est ce que vous voyez une fois le JavaScript exécuté. La différence entre les deux, c’est exactement ce dont parle le JavaScript SEO.

Il existe deux façons de réaliser ce rendu. Avec le server-side rendering, le serveur construit déjà la page complète et l’envoie prête à l’emploi au navigateur. Avec le client-side rendering, le navigateur (ou le crawler) reçoit d’abord un HTML nu et doit lui-même exécuter le JavaScript pour terminer la page. Cette seconde approche est plus lente et plus sujette aux erreurs, et elle est déconseillée pour la plupart des sites, comme l’explique aussi web.dev à propos du client-side rendering.

Le point clé est celui-ci : si le JavaScript ne se rend pas pour votre visiteur, il ne se rendra certainement pas pour le crawler de Google. Et ce que Google ne peut pas rendre, il ne peut ni l’indexer ni le positionner. Pour un site B2B, une page invisible ne signifie pas un clic manqué, mais un lead manqué. C’est pourquoi le JavaScript SEO a sa place dans votre stratégie de site web, à côté de votre contenu et de votre SEO technique.

Google sait-il vraiment lire le JavaScript ?

Nuance importante : Google ne crawle pas le JavaScript, mais il peut le rendre. Il convertit donc votre JavaScript en HTML rendu, puis crawle et indexe ce HTML. En théorie, votre contenu finit donc bien par y entrer.

En pratique, le diable se cache dans les détails. Ce rendu coûte à Google du temps et des ressources supplémentaires, il intervient dans une étape séparée après le premier crawl, et il peut échouer de dizaines de façons. Un seul fichier bloqué, une seule instruction contradictoire, et votre contenu passe à la trappe. Ne comptez donc pas sur le fait que Google va toujours « s’en sortir tout seul ». C’est à vous de le vérifier.

Voyez le traitement de Google comme une chaîne que votre page doit parcourir étape par étape. Chaque étape après le crawl est un endroit supplémentaire où une page JavaScript peut s’arrêter net.

Comment détecter les problèmes de rendu ?

Le principe reste toujours le même test : comparez votre HTML brut avec votre HTML rendu, une approche que Semrush place elle aussi au centre de son explication sur le rendu JavaScript. S’ils divergent sur des éléments qui comptent (le titre de la page, le H1, le corps de texte, les liens, le hreflang), vous courez un risque dès que le rendu se met à flancher.

Quelques façons concrètes de vérifier cela :

• Google Search Console. L’inspection d’URL vous montre le HTML rendu et une capture d’écran de la page telle que Google la récupère. Cela fait partie des bases que Google décrit dans sa documentation sur le JavaScript SEO. Si vous n’y voyez pas votre contenu, Google ne le voit pas non plus. Comment lire cela est expliqué dans Google Search Console.
• Un crawler comme Screaming Frog. Il peut placer les deux versions côte à côte et montre exactement où le JavaScript ajoute du contenu qui manque dans le HTML brut.
• Consulter le code source. Ouvrez votre page, affichez le code source et cherchez vos textes et titres les plus importants. S’ils n’y sont pas, c’est qu’ils n’arrivent que via le JavaScript.

Une analyse de trois sites SaaS connus (Zoom, Asana et un blog marketing) a montré que même de grandes marques, techniquement matures, en souffrent. Chez Zoom, l’attribut hreflang manquait dans le HTML brut, le H1 n’y figurait pas, et le titre brut affichait « Loading » alors que le titre rendu était « Zoom Learning Center ». En soi, ce n’est souvent pas dramatique tant que le rendu réussit, mais chaque écart est une fuite potentielle dès que ce rendu échoue une fois.

Quels problèmes de rendu JavaScript reviennent le plus souvent ?

Trois problèmes ressortent systématiquement. Bonne nouvelle : tous les trois se corrigent.

Des fichiers .js bloqués dans le robots.txt

Si je ne devais en épingler qu’un seul, ce serait celui-ci. Si vous bloquez vos fichiers JavaScript dans votre robots.txt, Google ne peut jamais les récupérer, donc jamais les rendre, donc jamais indexer le contenu qu’ils portent. Dans l’analyse SaaS, les trois sites avaient, à des degrés divers, des ressources JS bloquées ; sur le site le plus performant, les dégâts se limitaient à une poignée d’URL.

Le correctif est étonnamment simple : faites adapter votre robots.txt afin que les ressources critiques (vos fichiers JavaScript) ne soient plus bloquées. Ensuite, pas besoin d’attendre des semaines que Google revienne de lui-même ; vous pouvez demander explicitement un nouveau crawl de vos URL via la Search Console.

Des directives contradictoires

Les directives sont des instructions aux crawlers, comme noindex (ne pas indexer) et nofollow (ne pas transmettre de valeur de lien). Le problème surgit quand votre HTML brut contient une autre directive que votre HTML rendu. Si noindex figure par exemple dans une version et pas dans l’autre, Google ne sait pas quoi faire, et le résultat est souvent qu’aucune des deux versions n’est indexée. Cela peut même provoquer une erreur de timeout dans vos rapports de performance.

La solution : rendez votre intention univoque. Si vous voulez qu’une page soit indexée, retirez le noindex du HTML brut comme du HTML rendu. Si vous voulez au contraire la garder hors de l’index, veillez à ce que noindex figure dans les deux versions.

Des liens qui ne se rendent pas

Les liens qui n’existent que dans le JavaScript peuvent échouer au rendu, par exemple parce qu’un plugin est désactivé ou qu’un fichier de thème a été supprimé. La conséquence : si le lien ne se rend pas, Google ne peut pas le suivre, et vous ne transmettez aucune valeur de lien interne à la page de destination. Sur un site B2B où vous voulez renforcer vos pages de services les plus importantes avec des liens internes, l’autorité fuit donc à cet endroit. Vérifiez régulièrement quels liens JavaScript ne se rendent pas et faites le ménage, aussi pour éviter le script bloat.

Quelle est la différence entre server-side et client-side rendering ?

Pour la plupart des sites B2B, c’est le choix structurel le plus important. Avec le server-side rendering (SSR), le crawler reçoit une page complète : le serveur récupère les données, construit le HTML et l’envoie. Pas d’étape de rendu supplémentaire, pas d’attente, rien qui puisse mal tourner dans le navigateur de Google. Avec le client-side rendering, vous repoussez ce travail vers le client, avec tous les risques que cela comporte.

Si vous construisez un nouveau site ou planifiez une migration, optez pour le server-side rendering ou pour une variante qui place déjà le contenu principal dans le HTML brut. C’est la manière la plus propre d’exclure d’emblée les problèmes de rendu. Et cela rejoint vos Core Web Vitals : moins de JavaScript côté client signifie souvent une page plus rapide et plus stable.

Qu’en faire en tant qu’entreprise B2B ?

Conseil honnête : inutile de devenir paranoïaque, mais vous devez bel et bien vérifier cela une bonne fois. La plupart des erreurs de rendu n’ont aucun effet visible jusqu’au moment où elles en ont soudain un, et vous perdez alors une page importante de l’index sans vous en rendre compte.

Notre position est simple : pilotez sur les clients et le chiffre d’affaires, pas sur des chiffres de vanité. Un problème de rendu sur votre blog que personne ne visite ne vaut pas la peine d’être corrigé. Un problème de rendu sur votre page de service ou votre landing page principale est une menace directe pour votre flux de leads. Nous sommes une petite équipe, alors nous commençons toujours par les pages qui rapportent de l’argent, pas par une checklist qui vous impose 200 correctifs insignifiants.

Un site B2B n’est pas non plus une boutique en ligne. Vous n’avez pas dix mille pages produits qui doivent toutes se rendre ; vous avez une poignée de pages qui comptent vraiment. Cela rend la chose gérable. Parcourir une checklist SEO technique ou faire réaliser un audit SEO vous donne en quelques heures une réponse claire : Google voit-il correctement vos pages qui rapportent ? Un tel contrôle a sa place dans un suivi SEO continu, pas dans un grand nettoyage ponctuel.

Questions fréquentes sur le JavaScript SEO

Google peut-il indexer mon contenu JavaScript ?

Oui, Google peut rendre le JavaScript et indexer le HTML qui en résulte. Mais cela se passe dans une étape séparée qui peut échouer, par exemple à cause de fichiers bloqués ou de directives contradictoires. Ne vous y fiez donc pas aveuglément et vérifiez-le via l’inspection d’URL dans la Search Console.

Quelle est la différence entre HTML brut et HTML rendu ?

Le HTML brut est ce que le serveur envoie avant que le JavaScript ne s’exécute. Le HTML rendu est ce que vous voyez une fois le JavaScript exécuté. Les éléments importants qui ne figurent que dans la version rendue (titre, H1, texte, liens) sont à risque si le rendu échoue une fois.

Comment savoir si mon site a un problème de rendu ?

Comparez les deux versions. Utilisez l’inspection d’URL dans Google Search Console ou un crawler comme Screaming Frog, et regardez si votre contenu, vos titres et vos liens les plus importants figurent dans le HTML rendu que Google récupère.

Le server-side rendering est-il toujours meilleur ?

Pour le SEO, généralement oui : le crawler reçoit une page complète sans étape de rendu supplémentaire, il y a donc moins de choses qui peuvent mal tourner. C’est aussi favorable à la vitesse de chargement. Pour la plupart des sites B2B, c’est le choix le plus sûr.

Faites vérifier si Google voit vraiment vos pages les plus importantes

Le JavaScript SEO n’est pas un exercice académique : si Google ne rend pas votre page de service, vous perdez des leads sans même le remarquer. Nous regardons d’abord les pages qui génèrent du chiffre d’affaires, nous vous disons honnêtement s’il y a un vrai problème, et nous ne corrigeons que ce qui compte. Pas de liste de 200 correctifs cosmétiques, mais un site que Google peut lire intégralement.

Planifiez votre entretien gratuit