Pourquoi vos pages JavaScript mettent-elles des semaines à être indexées ?

Quelle est la différence entre crawl, rendu et indexation pour le JS ?

Googlebot opère en deux passages distincts pour les pages JavaScript. Premier passage : le crawl récupère le HTML brut. Deuxième passage : le moteur de rendu exécute le JavaScript, génère le DOM complet, puis indexe le contenu visible.

Ce double processus crée un délai incompressible. Entre le crawl initial et le rendu final, plusieurs jours voire semaines peuvent s'écouler, selon les ressources que Google alloue à votre site. Si votre HTML de base est vide ou quasi-vide, Google ne voit rien lors du premier passage.

Pourquoi le rendu JavaScript consomme-t-il autant de ressources côté Google ?

Exécuter du JavaScript requiert du temps CPU et de la mémoire. Googlebot doit charger toutes les dépendances, exécuter les scripts, attendre les appels API, puis construire le DOM. Chaque page JS monopolise davantage de ressources qu'une page HTML statique.

Google priorise ses ressources sur les sites à forte autorité ou à forte fréquence de mise à jour. Si votre crawl budget est limité, vos pages JS passeront en queue. Le résultat : un site neuf en full JS peut attendre plusieurs semaines avant indexation complète, là où un site HTML classique serait indexé en quelques jours.

Que signifie concrètement "pré-rendu" et "rendu dynamique" ?

Le pré-rendu génère des fichiers HTML statiques en amont (au build), que vous servez directement à Googlebot. Next.js avec Static Generation, Nuxt en mode SSG, ou des outils comme Prerender.io entrent dans cette catégorie. Google reçoit du HTML complet dès le premier passage.

Le rendu dynamique détecte le user-agent de Googlebot et lui sert une version HTML rendue côté serveur (SSR) à la volée, tandis que les utilisateurs humains reçoivent la version JS classique. Cette approche évite le cloaking car le contenu reste identique, seule la méthode de génération diffère.

• Pages JS sans optimisation : crawl → attente → rendu → indexation (délai de plusieurs jours à semaines)
• Pages pré-rendues ou SSR : crawl → indexation immédiate (délai réduit à quelques heures ou jours)
• Le crawl budget reste consommé dans les deux cas, mais le time-to-index chute drastiquement
• Google recommande officiellement le rendu dynamique pour les sites JS lourds depuis plusieurs années
• Les frameworks modernes (Next, Nuxt, SvelteKit) intègrent nativement ces solutions

Cette déclaration est-elle cohérente avec les observations terrain ?

Totalement. Les audits terrain confirment systématiquement que les sites full-client JS souffrent de latences d'indexation mesurables. Un site e-commerce migré de Magento vers une PWA React sans SSR peut voir ses nouvelles fiches produit indexées avec 10-15 jours de retard.

Google Search Console affiche clairement les pages "Crawlées, actuellement non indexées" en masse sur ces architectures. La corrélation entre absence de SSR et délais d'indexation n'est plus à prouver. Ce n'est pas une théorie, c'est du quotidien praticien.

Quelles nuances faut-il apporter à cette recommandation ?

Google ne dit pas que le JS est pénalisé au ranking, seulement qu'il ralentit l'indexation. Une fois la page rendue et indexée, elle concourt normalement. Le problème touche surtout les sites à forte vélocité éditoriale : médias, e-commerce, marketplaces.

Si votre site publie 2 articles par mois et possède une autorité solide, le délai d'indexation JS restera gérable. Mais si vous sortez 50 fiches produit par jour avec un crawl budget limité, chaque jour perdu coûte du CA. [À vérifier] : Google n'a jamais communiqué de SLA précis sur le délai moyen de rendu JS selon les tiers de sites.

Dans quels cas le rendu dynamique pose-t-il problème ?

Le rendu dynamique introduit une dette technique : vous maintenez deux chemins de rendu distincts. Si votre équipe modifie le front sans tester la version SSR, Googlebot peut recevoir du contenu obsolète ou cassé. Les régressions passent inaperçues jusqu'au prochain audit.

Certains outils de pre-rendering tiers (Prerender.io, Rendertron) ajoutent de la latence serveur et un point de défaillance supplémentaire. Si le service tombe, Googlebot reçoit du HTML vide. Privilégie toujours une solution intégrée au build (SSG) ou au runtime applicatif (SSR natif) plutôt qu'un proxy externe.

Que faut-il faire concrètement sur un site JS existant ?

Audite d'abord ton taux de couverture dans Search Console : ratio pages soumises / pages indexées. Si moins de 70 % de tes URLs stratégiques sont indexées après 30 jours, tu as un problème de rendu JS. Vérifie ensuite l'outil "Inspection d'URL" pour comparer le HTML brut et le HTML rendu.

Ensuite, mesure le time-to-index réel. Publie une page test, soumets-la via sitemap, et track combien de jours s'écoulent avant indexation complète. Compare avec un concurrent en HTML statique ou SSR. L'écart te donnera la perte sèche en jours de visibilité.

Quelles erreurs éviter lors de la migration vers SSR ou pré-rendu ?

Erreur classique : migrer vers Next.js mais oublier de configurer les fallbacks et les rewrites correctement. Résultat : Googlebot tombe sur des 404 ou des pages blanches alors que l'utilisateur voit le contenu. Teste systématiquement avec le user-agent Googlebot avant de déployer.

Autre piège : générer du pré-rendu statique sans stratégie de régénération (ISR dans Next.js). Tes pages deviennent obsolètes, Google indexe du contenu périmé, et ton taux de clic chute. Si ton contenu bouge souvent, le SSR reste plus fiable que le SSG pur.

Comment vérifier que Googlebot reçoit bien le HTML complet ?

Utilise l'outil "Tester l'URL en direct" dans Search Console. Compare la capture d'écran rendue par Google avec ton rendu utilisateur. Si les deux sont identiques et que le HTML source contient déjà ton contenu, tu es bon.

Complémente avec un crawl Screaming Frog en mode "Rendering JavaScript" activé vs désactivé. La colonne "Word Count" doit rester stable entre les deux modes si ton SSR fonctionne. Un écart de 80 % signale un problème de rendu côté bot.

• Activer SSR ou SSG sur toutes les pages stratégiques (catégories, fiches produit, articles)
• Configurer un sitemap XML avec lastmod précis pour forcer le re-crawl rapide
• Tester chaque template avec le user-agent Googlebot avant déploiement
• Monitorer le ratio "Crawlées / Indexées" hebdomadairement dans Search Console
• Mettre en place une alerte si le time-to-index dépasse 7 jours sur les pages prioritaires
• Documenter les différences entre version SSR et CSR pour éviter les régressions