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

Quelle est la différence entre crawl budget et budget de rendu ?

Le crawl budget désigne le nombre de requêtes HTTP que Googlebot accepte d'effectuer sur un site pendant une période donnée. Chaque fichier demandé — HTML, CSS, images, scripts JS, appels API — consomme une fraction de ce budget.

Le rendu JavaScript, lui, intervient après le crawl : Googlebot télécharge le HTML, parse le JS, exécute le code, puis indexe le contenu final. Splitt précise qu'il n'existe aucun quota distinct pour cette phase de rendu — c'est uniquement la récupération initiale des ressources qui compte.

Pourquoi le cache limite-t-il l'impact du JavaScript ?

Google met en cache les fichiers JavaScript après la première récupération. Si votre bundle main.js ne change pas entre deux crawls, Googlebot ne le re-télécharge pas — il utilise la version en cache.

Résultat : même si votre site est une SPA React complète, l'impact sur le crawl budget reste gérable tant que vos bundles sont stables. C'est le nombre de requêtes HTTP distinctes qui compte, pas la complexité d'exécution du JS côté moteur.

Qui devrait se soucier du bundling et du code-splitting ?

Splitt réserve ces optimisations aux très gros sites avec beaucoup de JavaScript. Concrètement : e-commerce avec des milliers de SKU en client-side rendering, portails médias avec infinite scroll et chargements dynamiques massifs, marketplaces avec des dizaines de widgets tiers.

Pour un site corporate classique ou un blog technique, le bundling n'apporte aucun gain mesurable sur le crawl budget. Le tree-shaking et le code-splitting visent d'abord les performances utilisateur (Core Web Vitals), pas le SEO.

• Crawl budget = nombre de requêtes HTTP que Google accepte de faire sur votre site
• Rendu JavaScript = phase d'exécution du code, sans quota distinct
• Cache = Google réutilise les fichiers JS déjà récupérés, limitant les requêtes répétées
• Optimisations JS (bundling, tree-shaking, code-splitting) = pertinentes uniquement pour les gros sites avec beaucoup de JavaScript
• Sites classiques = inutile de sur-optimiser le JS pour le crawl budget — focalisez-vous sur la performance utilisateur

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

Oui, dans la majorité des cas. Les sites qui migraient d'un rendu serveur vers du client-side rendering constataient effectivement une hausse du crawl budget consommé — mais uniquement lors des premiers crawls, avant que Google ne mette en cache les bundles JS.

Une fois les ressources cachées, la consommation se stabilise. Les problèmes d'indexation persistants sur les SPAs viennent rarement du crawl budget — c'est souvent un soucis de rendu incomplet (erreurs JS, timeouts, contenu généré trop tard).

Quelles nuances faut-il apporter ?

La définition de « très gros site avec beaucoup de JS » reste floue. Google ne donne aucun seuil chiffré : combien de pages ? Combien de Mo de JS ? Quelle fréquence de mise à jour ?

En pratique, si vous avez moins de 50 000 URLs et des bundles stables sous 1 Mo, le crawl budget n'est probablement pas votre problème. Au-delà, surveillez les stats de crawl dans Search Console — si Googlebot ne passe pas assez souvent, là oui, bundling et code-splitting deviennent pertinents. [A vérifier] : Google ne publie aucune métrique publique permettant de diagnostiquer précisément ce seuil.

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

Les sites avec du contenu généré à la volée via des appels API externes (ex : prix en temps réel, stock dynamique) consomment du crawl budget à chaque visite — même si le HTML principal est en cache. Chaque appel API = une requête HTTP distincte.

Autre exception : les sites qui déploient des mises à jour JS quotidiennes (ex : newsrooms, dashboards temps réel). Si vos bundles changent constamment, le cache ne vous aide pas — vous paierez le coût complet à chaque crawl.

Que faut-il faire concrètement si mon site utilise beaucoup de JavaScript ?

Commencez par mesurer avant d'optimiser. Dans Search Console, allez dans Paramètres > Statistiques d'exploration : regardez le nombre de requêtes par jour et le temps de téléchargement moyen. Si Googlebot crawle moins de 10% de vos pages par semaine, vous avez un problème de crawl budget.

Ensuite, auditez vos bundles JS : utilisez Webpack Bundle Analyzer ou Lighthouse pour identifier les librairies inutiles, les duplications, les polyfills obsolètes. Le tree-shaking élimine le code mort, le code-splitting charge uniquement ce qui est nécessaire par page.

Quelles erreurs éviter ?

Ne bundlez pas aveuglément tout votre JS en un seul fichier de 3 Mo — ça tue les Core Web Vitals et Google pénalise l'expérience utilisateur. Préférez du code-splitting intelligent : un bundle commun pour les fonctions partagées, des bundles spécifiques par section.

Évitez aussi de sur-optimiser si vous n'êtes pas concerné. Un site corporate de 500 pages avec 200 Ko de JS n'a aucun besoin de bundling avancé — vous perdrez du temps pour zéro gain SEO. Focalisez-vous sur la qualité du rendu final (test via URL Inspection dans Search Console).

Comment vérifier que mon site est conforme ?

Utilisez Search Console > URL Inspection pour tester le rendu d'une page critique. Comparez le HTML source et le HTML rendu : si des éléments essentiels (titres, textes, liens) n'apparaissent que dans le rendu, vérifiez que Google les voit bien.

Surveillez aussi le temps de réponse serveur et la vitesse de chargement des ressources JS. Si vos fichiers mettent plus de 2 secondes à charger, Googlebot peut timeout — même si le crawl budget est suffisant. La performance réseau compte autant que le budget lui-même.

• Mesurer le crawl budget dans Search Console (Statistiques d'exploration)
• Auditer les bundles JS avec Webpack Bundle Analyzer ou Lighthouse
• Appliquer tree-shaking pour éliminer le code mort
• Mettre en place du code-splitting intelligent (bundles par section)
• Vérifier le rendu final via URL Inspection dans Search Console
• Optimiser le temps de réponse serveur et la vitesse de chargement des ressources