Rendu dynamique : ce qu'il corrige sur un site JavaScript (et ce qu'il ne corrige pas)
Par Toy Wen Da, Cofondateur · Mis à jour le · 7 min de lecture
Traduit de l'original en anglais. Lire en anglais
Le rendu dynamique consiste à faire vérifier par votre serveur si un visiteur est un navigateur ou un robot d'indexation, puis à envoyer aux robots une version HTML statique et prérendue de la page, tandis que les humains profitent de l'expérience JavaScript complète. Il règle les cas où Googlebot ne parvient pas à lire un contenu qui n'apparaît qu'après l'exécution des scripts, mais il ne résout pas tous les problèmes d'indexation.
Avant de toucher au moindre code serveur, vérifiez ce que Googlebot voit sur la page concernée. Le Googlebot Simulator gratuit récupère une URL comme le fait le robot de Google et vous montre le HTML rendu : en une minute, vous savez si votre contenu JavaScript est absent de ce que le robot reçoit.
Comment ça fonctionne
Détecter le visiteur
Votre serveur, ou une couche CDN placée devant lui, examine l'en-tête User-Agent de chaque requête. Lorsque l'en-tête correspond à un robot connu comme Googlebot ou Bingbot, ou de plus en plus à un robot d'IA, la requête est aiguillée différemment de celle d'un navigateur ordinaire.
Servir deux versions de la même page
Les visiteurs humains reçoivent toujours votre application React, Vue ou Angular avec toute son interactivité. Les robots reçoivent un instantané HTML prérendu, généré par un outil de navigateur sans interface (headless) comme Puppeteer ou Rendertron, ou par un service tiers tel que Prerender.io ; comme cet instantané est statique, aucun script n'a besoin de s'exécuter pour que le contenu soit visible.
Pourquoi les sites en ont besoin
Googlebot sait exécuter du JavaScript, mais le rendu consomme beaucoup de ressources et se fait avec un délai : les pages sont donc souvent explorées une première fois puis rendues plus tard, ce qui peut retarder l'indexation. La plupart des moteurs de réponse IA n'exécutent pas du tout le JavaScript, si bien qu'une page qui dépend du rendu côté client peut leur être invisible dès le départ. Une page qui n'est jamais indexée n'obtient aucune visibilité et aucun taux de clic, et encore moins un bon.
Le corriger sur votre propre site, étape par étape
- Confirmez qu'il existe réellement un écart : récupérez la page comme un robot et comparez-la à ce que charge un navigateur normal. Si le contenu est identique, rien de tout cela n'est nécessaire.
- Déterminez si le problème touche un seul gabarit, une section du site ou tout le site, car cette étendue détermine l'ampleur du travail d'infrastructure à engager.
- Ajoutez une détection du user agent au niveau du serveur ou du CDN, par exemple avec un Cloudflare Worker ou une règle Nginx, qui compare les requêtes entrantes à une liste de robots tenue à jour.
- Aiguillez le trafic des robots vers un service de prérendu qui génère le HTML statique de chaque URL et le met en cache, afin de ne pas refaire le rendu à chaque visite d'un robot.
- Gardez un contenu équivalent : la version prérendue doit correspondre à ce que voit finalement un humain, avec le même texte, les mêmes liens et les mêmes données structurées.
- Refaites des tests après la mise en ligne, puis après chaque déploiement du front-end, car une modification de l'interface peut casser sans bruit ce que capture le service de prérendu.
- Surveillez le dispositif en continu. Si le service de rendu tombe en panne, les robots peuvent se mettre à recevoir des pages blanches ou des erreurs, ce qui peut entraîner rapidement une désindexation.
Quand vos propres outils suffisent, et quand ils ne suffisent pas
Vérifier une seule page n'a rien à voir avec corriger le rendu de tout un site.
| Situation | Ce que vous vérifiez | Bon outil | La voie gratuite suffit-elle ? |
|---|---|---|---|
| Une URL vous paraît correcte mais pas dans l'index de Google | Ce que Googlebot voit sur cette page | Googlebot Simulator | Oui, confirme ou écarte un écart de rendu en quelques minutes |
| Site entier construit en React/Vue/Angular sans rendu côté serveur | Explorabilité de l'ensemble du site | Un crawl technique complet et un audit du rendu | Non, c'est un changement d'infrastructure, pas une vérification d'une seule page |
| La mise en page mobile d'une page semble défaillante en plus du problème d'indexation | Rendu mobile, viewport, ergonomie | Test gratuit d'adaptation aux mobiles | Oui, pour diagnostiquer la partie propre au mobile |
| Des pages étaient bien indexées, puis ont disparu après une refonte | Régression récurrente, pas un incident isolé | Suivi continu et revue du dispositif de prérendu | Non, une vérification ponctuelle ne détectera pas un problème qui revient à chaque déploiement |
Un contrôle ponctuel sur une seule URL est précisément ce pour quoi les outils gratuits sont conçus, alors qu'un schéma récurrent à l'échelle du site appelle une correction d'infrastructure, qui implique généralement un développeur et un service de prérendu.
Comparaison avec les alternatives
| Approche | Fonctionnement | Cas idéal | Charge de maintenance |
|---|---|---|---|
| Rendu dynamique | Sert du HTML statique aux robots, l'application JS aux humains | Sites très JS avec des problèmes de budget de crawl ou de visibilité dans les IA, qui ne peuvent pas encore tout réécrire | Élevée, un pipeline de rendu distinct à maintenir |
| Rendu côté serveur (SSR) | Le serveur génère le HTML à chaque requête, pour tout le monde | Nouveaux projets ou sites ayant les ressources pour reconstruire leur front-end | Modérée, un seul chemin de rendu pour tous les visiteurs |
| Génération de site statique (SSG) | Le HTML est construit à l'avance, au moment du déploiement | Contenus qui ne changent pas à chaque requête, comme les blogs ou les pages marketing | Faible, reconstruction à chaque changement de contenu |
| Rendu côté client (aucune correction) | Le navigateur construit la page à partir de JavaScript, les robots reçoivent la même chose | Outils internes, pas les pages publiques destinées à la recherche | Peu d'effort, risque élevé pour le référencement |
Les recommandations de Google présentent cette technique comme une solution provisoire plutôt que comme un point d'arrivée, et le SSR ou le SSG sont des corrections plus durables dès que vous pouvez vous offrir la reconstruction.
Est-ce considéré comme du cloaking ?
Non, tant que vous la mettez en œuvre de bonne foi. La documentation Google Search Central indique que Googlebot ne la traite généralement pas comme du cloaking, à condition que le contenu rendu servi aux robots soit équivalent à ce que les visiteurs humains finissent par voir. L'infraction n'est pas l'existence de deux versions, mais le fait de montrer aux robots et aux humains des contenus réellement différents, comme une page bourrée de mots-clés sur des chaussures de course pour les robots alors que les visiteurs voient une page sur tout autre chose. Gardez le même fond dans les deux versions et vous respectez la règle.
Erreurs courantes
- La considérer comme permanente, alors qu'elle ne fait que masquer un problème d'explorabilité et ne supprime pas le besoin, à terme, d'une architecture plus facile à explorer.
- Laisser le service de prérendu devenir obsolète, de sorte que les robots voient une version périmée ou cassée de la page chaque fois qu'il rate une modification du front-end.
- S'appuyer sur une liste de robots incomplète : la détection par user agent ne fonctionne que pour les robots que vous avez listés, et un nouveau robot d'IA que vos règles ne reconnaissent pas reçoit la version JavaScript brute, qu'il ne sait probablement pas lire.
- Sauter les nouveaux tests après les déploiements, alors qu'une mise en production du front-end que personne n'a revérifiée côté robots est la cause la plus fréquente de panne silencieuse d'un tel dispositif.
- L'appliquer à un site qui n'en a pas besoin, car les petits sites surtout statiques ont rarement un problème de rendu qui justifie autant d'infrastructure.
Questions fréquentes
Le rendu dynamique nuit-il à mon classement ?
Pas en soi. Le risque vient d'une version mal configurée qui sert des pages périmées ou des erreurs et s'éloigne de ce que voient les visiteurs humains.
Le rendu dynamique, c'est la même chose que le cloaking ?
Non. Le cloaking consiste à servir aux robots et aux humains des contenus substantiellement différents, alors que cette technique sert le même contenu dans un format différent, ce que les moteurs de recherche autorisent explicitement.
Comment savoir si mon site a vraiment besoin du rendu dynamique ?
Récupérez une page comme Googlebot et comparez-la à la version du navigateur. Si votre contenu principal et vos liens sont absents de la vue du robot, vous avez votre signal.
Quelle est l'alternative à long terme au rendu dynamique ?
Le rendu côté serveur ou la génération de site statique, qui servent le même HTML rendu à tout le monde au lieu de maintenir deux chemins distincts.
Les sites de petites entreprises peuvent-ils ignorer complètement le rendu dynamique ?
Généralement, oui. Il compte surtout pour les grands sites très axés JavaScript, dont le contenu change fréquemment ou qui subissent des contraintes de budget de crawl, et non pour un petit site classique construit sur des gabarits de page standards.
Vérifiez votre page avant de construire quoi que ce soit
Ne vous lancez pas dans la construction d'un pipeline de prérendu sur une simple intuition. Récupérez la page en question, regardez ce que reçoit Googlebot, et n'investissez dans l'infrastructure que s'il existe un véritable écart entre ce que voient les robots et les humains. Si vous souhaitez un second regard sur ce qui freine votre indexation, parlez-en à l'équipe et demandez un exemple de rapport SEO.
Sources
À propos de l'auteur
SearchBlueprint a recherché, rédigé et noté cet article avec la chaîne de production de contenu que nos clients utilisent sur leurs propres sites. La note affichée dans la signature est celle que notre moteur de contenu a attribuée à cette page avant sa publication. Rien ici n'est relu à la main, et c'est tout l'intérêt : c'est le résultat du produit, publié là où chacun peut le vérifier.