Le JavaScript consomme-t-il vraiment votre crawl budget ?

La déclaration de Martin Splitt vise à désamorcer une croyance tenace : celle que le JavaScript serait un gouffre à crawl budget. Dans la réalité, Google met en cache les bibliothèques et frameworks populaires (React, Vue, jQuery, etc.), ce qui limite drastiquement la charge.

Le crawl budget, pour rappel, désigne le nombre de pages que Googlebot accepte de parcourir sur votre site dans un laps de temps donné. Si votre JS déclenche des appels réseau (API, lazy loading, composants asynchrones), cela peut théoriquement alourdir le travail du bot — mais l'impact réel reste marginal.

Pourquoi le JavaScript génère-t-il plus de requêtes ?

Un site client-side rendering (CSR) exécute du JavaScript pour afficher le contenu final. Cela signifie que Googlebot doit d'abord récupérer le HTML de base, puis télécharger les fichiers JS, les exécuter, et attendre que le DOM se construise. Si votre JS fait des appels API pour charger des données, ça multiplie les requêtes HTTP.

Mais attention — Google réutilise les ressources déjà crawlées. Si dix pages de votre site chargent le même bundle React hébergé sur un CDN, Google ne le télécharge qu'une fois. C'est ce mécanisme de cache qui rend l'impact « négligeable » pour la plupart des sites.

Quels sites sont vraiment concernés par cette problématique ?

Splitt mentionne deux cas de figure : les très gros sites (dizaines de millions d'URLs) et les serveurs très lents. Dans le premier cas, même un micro-impact par page se multiplie par des millions — et ça finit par peser. Dans le second, si votre serveur met 2 secondes à répondre, Googlebot ralentit son crawl pour ne pas le surcharger.

Pour un site e-commerce de 50 000 produits ou un blog de quelques milliers d'articles, le JS n'est pas un frein. Google crawle suffisamment vite pour absorber les requêtes additionnelles. Le vrai enjeu, c'est la vitesse de rendu et la qualité du code, pas le crawl budget.

Quels sont les points essentiels à retenir ?

• La mise en cache des ressources communes (frameworks, CDN) compense largement le coût du JS.
• Le crawl budget devient un problème réel uniquement pour les sites de plusieurs dizaines de millions d'URLs ou les infrastructures lentes.
• Le server-side rendering (SSR) ou le pré-rendu restent pertinents pour des raisons de vitesse et d'UX, pas forcément de crawl budget.
• Un site JS bien optimisé (code splitting, lazy loading maîtrisé, CDN) ne souffre d'aucun handicap crawl.
• La vraie question n'est pas « combien de pages Google crawle », mais « combien de temps met-il à indexer le contenu rendu ».

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

Oui — et non. Sur des sites middle-market (10k à 500k URLs), on observe rarement un problème de crawl budget lié au JS. Les pages JS bien construites s'indexent aussi vite que du HTML statique, parfois même mieux si le SSR est en place. Google crawle, rend, indexe. Pas de drama.

Mais sur des plateformes massives (marketplaces, agrégateurs, sites d'annonces), on voit parfois des délais d'indexation plus longs sur les pages JS mal optimisées. Le souci, c'est que Google ne dit jamais où se situe exactement le seuil « dizaines de millions d'URLs ». 5 millions ? 20 millions ? 50 millions ? [A vérifier] — aucune donnée officielle.

Quelles nuances faut-il apporter à cette affirmation ?

La mise en cache des ressources communes, c'est vrai — mais ça suppose que vous utilisiez des versions stables et publiques de ces librairies. Si vous hébergez un build React custom en interne, que vous changez les hash à chaque déploiement, ou que vous servez des bundles gigantesques non splittés, Google doit re-télécharger à chaque fois.

Autre point : le JS peut bloquer le rendering si mal architecturé. Googlebot attend un certain temps (quelques secondes) que le DOM se stabilise. Si votre JS fait des appels API lents, ou s'il y a des erreurs JS qui cassent le rendu, ça peut retarder l'indexation — mais là encore, ce n'est pas tant un problème de crawl budget que de rendering budget, concept que Google évoque rarement.

Enfin, « serveurs très lents » est une formule vague. Un TTFB de 500ms est-il « lent » ? 1 seconde ? 2 secondes ? Google adapte son rythme de crawl au comportement du serveur, mais aussi à la « valeur » perçue du site. Un site autoritaire avec un TTFB de 800ms sera crawlé plus agressivement qu'un site lambda avec 300ms. [A vérifier] — il n'y a pas de seuil officiel.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre site génère des URLs dynamiques à la volée via JS (filtres, facettes, paramètres d'URL non canonisés), vous pouvez créer artificiellement des millions d'URLs que Google va tenter de crawler. Dans ce cas, le JS amplifie le problème de crawl budget — mais c'est un problème d'architecture, pas du JS lui-même.

Pareil pour les Single Page Apps (SPA) qui chargent tout le contenu en AJAX sans mettre à jour l'URL ou sans utiliser le dynamic rendering. Googlebot peut crawler la page d'accueil, mais si le contenu n'est accessible qu'après interaction utilisateur, ça pose un souci d'indexabilité — crawl budget ou pas.

Que faut-il faire concrètement si votre site utilise du JS ?

D'abord, arrêtez de paniquer pour le crawl budget si vous avez moins de 10 millions d'URLs. Concentrez-vous plutôt sur la vitesse de rendu et la qualité du code. Un site JS rapide et bien architecturé n'a aucun handicap face à Google. Testez vos pages dans la Search Console, onglet « Inspection d'URL », section « HTML rendu » — si le contenu s'affiche, vous êtes bon.

Ensuite, optimisez votre infrastructure. Un TTFB inférieur à 200ms, un CDN pour les assets statiques, du code splitting pour limiter la taille des bundles initiaux. Ces optimisations ont un impact bien plus fort que de se demander si le JS « consomme » du crawl budget. Google crawle vite — ce qui le ralentit, c'est un serveur qui traîne.

Quelles erreurs éviter avec le JavaScript côté SEO ?

Ne chargez pas tout le contenu via des appels API sans alternative SSR ou pré-rendu. Si votre site est un SPA pur (React, Vue, Angular) sans server-side rendering, Googlebot doit attendre que le JS s'exécute. Ça rallonge l'indexation — pas forcément à cause du crawl budget, mais parce que le rendering est plus lent.

Évitez aussi de multiplier les requêtes réseau bloquantes. Si votre JS fait 15 appels API séquentiels pour construire une page, Googlebot peut timeout ou indexer une version partielle. Privilégiez les appels en parallèle, le cache côté client, et les stratégies de fallback (afficher un contenu minimal en attendant le JS).

Enfin, ne vous fiez pas aux outils tiers qui affirment « Google ne voit pas votre contenu JS ». Testez par vous-même dans la Search Console. Les crawlers tiers (Screaming Frog, OnCrawl) n'exécutent pas toujours le JS de la même manière que Google — ou alors ils le font en mode « snapshot », ce qui ne reflète pas le comportement réel de Googlebot.

Comment vérifier que votre site JS est correctement crawlable ?

Utilisez l'outil « Inspection d'URL » de la Search Console. Collez une URL de contenu critique, cliquez sur « Tester l'URL en direct », puis regardez le « HTML rendu ». Si vos titres, textes, images sont présents, c'est bon. Si le HTML rendu est vide ou partiel, vous avez un souci de rendering — pas de crawl budget.

Complétez avec un crawl Screaming Frog en mode JavaScript (paramètres > Spider > Rendering > JavaScript). Comparez le crawl JS activé vs désactivé. Si vous voyez des écarts majeurs (pages vides sans JS, contenu manquant), c'est que votre architecture pose problème. Mais là encore, ce n'est pas le crawl budget qui est en cause — c'est la capacité de Google à exécuter votre code.

• Testez vos pages clés dans la Search Console, onglet « HTML rendu ».
• Vérifiez que les ressources JS critiques sont bien servies (pas de 404, pas de robots.txt bloquant).
• Optimisez le TTFB (< 200ms idéalement) et activez un CDN pour les assets.
• Utilisez du code splitting pour réduire la taille des bundles initiaux.
• Si vous avez un SPA, envisagez le SSR ou le pré-rendu (Prerender.io, Rendertron) pour les pages critiques.
• Surveillez les erreurs JS dans la console navigateur — une erreur qui casse le rendu peut bloquer l'indexation.