Rendu dynamique
Le rendu dynamique est une technique par laquelle un site sert deux versions de chaque page : un instantané HTML statique pré-rendu aux crawlers des moteurs de recherche, et une expérience d'application monopage JavaScript complète aux utilisateurs humains. Google l'a publiquement recommandé en 2018 comme solution de contournement pour les sites lourds en JS, puis l'a discrètement rétrogradé au rang de « solution de contournement héritée » d'ici 2024, à mesure que le rendu JS de Googlebot gagnait en maturité.
Le rendu dynamique est une technique par laquelle un site sert deux versions de chaque page : un instantané HTML statique pré-rendu aux crawlers des moteurs de recherche, et une expérience d'application monopage JavaScript complète aux utilisateurs humains. Google l'a publiquement recommandé en 2018 comme solution de contournement pour les sites lourds en JS, puis l'a discrètement rétrogradé au rang de « solution de contournement héritée » d'ici 2024, à mesure que le rendu JS de Googlebot gagnait en maturité.
Pourquoi c'est important
Les sites lourds en JavaScript avaient l'habitude de livrer des coquilles HTML vides, comptant sur le crawler pour exécuter le JS et voir le contenu réel. Googlebot y est finalement parvenu, mais lentement, souvent plusieurs jours après la récupération initiale du HTML, et les autres crawlers (Bing, robots d'IA, prévisualisation Facebook) étaient pires. Le rendu dynamique permettait aux équipes SEO de garantir que les crawlers voyaient immédiatement un HTML entièrement rendu, sans réécrire l'application. Pour les catalogues d'e-commerce, les tableaux de bord en JS et les SPA aux besoins SEO critiques, c'était un pont pragmatique. Le comprendre reste important, car de nombreux sites fonctionnent encore aujourd'hui avec le rendu dynamique et doivent migrer.
Comment ça fonctionne
1. Une requête arrive : le edge ou le serveur inspecte le user-agent.
2. Détection du crawler : si le user-agent correspond à un robot de recherche connu (Googlebot, Bingbot, Twitterbot, LinkedInBot, crawlers d'IA), la requête est acheminée vers un service de pré-rendu. Sinon, elle aboutit à la SPA normale.
3. Service de pré-rendu : un Chrome headless (souvent via prerender.io, Rendertron, Puppeteer ou Playwright) récupère la page, attend la fin du JS, capture le DOM et renvoie du HTML statique.
4. Mise en cache : le HTML rendu est mis en cache afin que les visites ultérieures des crawlers ne déclenchent pas de nouveau rendu.
5. Le robot voit le HTML ; l'utilisateur voit la SPA : même URL, deux expériences.
Pourquoi c'est désormais une « solution de contournement héritée »
Les recommandations de Google en 2024 ont fait passer le rendu dynamique de « recommandé » à « une solution de contournement et non une solution à long terme ». Les raisons :
Googlebot rend désormais bien le JS : Google exécute un Chrome headless à jour et traite rapidement le JS sur la plupart des pages. La raison d'origine du rendu dynamique a en grande partie disparu pour Google.
Charge de maintenance : faire fonctionner en parallèle un second pipeline de rendu représente une complexité opérationnelle qui dépasse généralement le bénéfice.
Risque de divergence : lorsque le service de pré-rendu tombe en panne ou devient obsolète, les robots voient un ancien contenu et les utilisateurs un nouveau, signal classique de cloaking.
Pas une pénalité de cloaking, mais presque : Google indique explicitement que le rendu dynamique n'est pas du cloaking, mais une divergence entre les vues du robot et de l'utilisateur peut déclencher un examen manuel.
Le SSR / SSG moderne est meilleur : Next.js, Nuxt, SvelteKit, Astro et Remix livrent par défaut des pages rendues côté serveur ou générées statiquement. Aucun rendu dynamique nécessaire.
Quand (si jamais) cela a encore du sens
SPA héritées impossibles à réécrire : une application mature et lourde en JS sans budget pour une migration vers le SSR. Le rendu dynamique reste viable comme solution d'attente.
Crawlers non-Google : les crawlers d'IA, Bing, Baidu et les robots de niche rendent encore moins bien le JS que Google. Si ceux-ci comptent pour votre trafic, le rendu dynamique peut aider.
Widgets et intégrations : un contenu qui se charge via JS après le HTML initial, parfois le seul moyen de l'exposer aux crawlers.
Solutions de contournement au niveau du edge : un rendu dynamique léger au niveau du edge du CDN qui transforme la SPA en HTML à la volée, sans service de pré-rendu distinct.
Comment migrer hors du rendu dynamique
1. Auditez ce qui échoue réellement en JS : utilisez l'inspection d'URL de Search Console et les comparaisons de rendu. De nombreux « problèmes de SEO JS » ne sont qu'un SSR manquant sur des pages critiques.
2. Migrez les pages critiques vers le SSR ou le SSG : pages d'accueil, d'atterrissage, produit et articles en premier. Conservez les tableaux de bord et les zones connectées en SPA.
3. Utilisez un framework moderne : Next.js / Nuxt / SvelteKit gèrent le rendu hybride d'emblée.
4. Vérifiez la parité : après la migration, explorez le nouveau site avec Screaming Frog et confirmez que le HTML correspond à ce que produisait l'ancien pré-rendu.
5. Mettez hors service le service de pré-rendu : seulement après plusieurs semaines de rapports de couverture Search Console sans anomalie.
Erreurs courantes
Servir intentionnellement un contenu différent : le rendu dynamique, c'est « même contenu, forme différente ». Un contenu différent constitue du cloaking et est pénalisé.
Ne pas mettre à jour le cache de pré-rendu : des pré-rendus obsolètes alimentent les robots avec un ancien contenu, se classant pour le produit de la veille.
Tout faire reposer sur le pré-rendu : placer un pré-rendu devant un site sans stratégie SSR signifie que vous êtes toujours à une panne près de la cécité des crawlers.
Ignorer les listes d'UA non-Googlebot : Bing, Yandex, Baidu et les crawlers d'IA ont tous des UA différents. En oublier un vous masque de ce robot.
Utiliser le rendu dynamique pour de nouveaux projets : ne le faites pas. Utilisez plutôt le SSR/SSG dans un framework moderne.
Sources: