Le JavaScript explose-t-il vraiment votre budget de crawl ?

Comment Google comptabilise-t-il exactement le budget de crawl ?

Quand Googlebot visite votre site, chaque fichier demandé à votre serveur consomme du budget : la page HTML elle-même, mais aussi tous les fichiers JavaScript, CSS, images, polices, favicon. Une page React qui charge 40 fichiers JS différents génère 40 requêtes distinctes. Le budget de crawl se mesure en requêtes HTTP, pas en pages visitées.

Mueller précise que Google utilise un cache agressif pour minimiser l'impact sur votre infrastructure. Si Googlebot a déjà téléchargé votre bundle React la semaine dernière, il le réutilise plutôt que de le redemander. Mais ce cache fonctionne sur l'URL complète : même nom de fichier, même paramètres.

Pourquoi le versioning des URLs change-t-il la donne ?

Le versioning consiste à modifier l'URL d'un fichier quand son contenu change : app.js devient app.v2.js ou app.js?v=1234. Pour Google, c'est une ressource complètement nouvelle. Le cache ne sert plus, Googlebot doit tout retélécharger.

Cette technique force le navigateur et les bots à récupérer la dernière version. Mais elle a un coût : si vous versionnez agressivement après chaque petit changement, vous annulez l'avantage du cache de Google et consommez du budget inutilement. Mueller suggère de le faire uniquement après des modifications significatives.

Quelle différence entre cache Google et cache navigateur ?

Le cache de Google fonctionne côté bot, indépendamment des headers HTTP que vous envoyez. Même si vous configurez Cache-Control: no-cache dans vos headers, Google maintient son propre cache interne pour économiser des requêtes. Ce n'est pas le navigateur qui décide.

Par contre, si vous utilisez un CDN avec cache public, Google en profite aussi : il télécharge depuis le CDN, pas depuis votre serveur origin. La requête compte toujours dans le budget de crawl, mais votre infrastructure n'est pas impactée. C'est une nuance importante pour les gros sites.

• Chaque fichier (HTML, JS, CSS, image) compte comme une requête distincte dans le budget de crawl
• Le cache Google limite les téléchargements répétés des mêmes URLs, indépendamment des headers HTTP côté serveur
• Le versioning d'URL (app.v2.js, app.js?v=123) force Google à ignorer son cache et retélécharger le fichier
• Les CDN publics protègent le serveur origin mais ne réduisent pas le budget de crawl consommé
• Versionnez uniquement après des changements majeurs, pas à chaque commit

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

Oui, elle correspond à ce qu'on observe sur les gros sites : les requêtes JS et CSS apparaissent bien dans les logs de crawl avec un volume proportionnel au nombre de fichiers statiques. Un site e-commerce avec 50 JS externes par page consomme effectivement 50x plus de budget qu'un site statique léger.

Par contre, Mueller reste vague sur la question du poids du cache. Il dit "agressif", mais combien de temps Google conserve-t-il un fichier ? Une semaine ? Un mois ? [A vérifier] Cette imprécision rend difficile l'optimisation fine. Sur des sites avec déploiements quotidiens, on ne sait pas si le cache joue vraiment ou si chaque crawl télécharge presque tout.

Faut-il vraiment se préoccuper du budget de crawl JavaScript ?

Soyons honnêtes : la majorité des sites n'ont pas de problème de budget de crawl. Si vous avez 5000 pages et que Google en crawle 2000 par jour, vous n'êtes pas limité. Le budget devient critique sur les très gros sites (500k+ pages) ou ceux avec une architecture pourrie qui génère des millions d'URLs inutiles.

Là où le JS pose problème, c'est quand vous chargez 15 frameworks différents, 20 scripts analytics, et 30 polyfills pour supporter IE11 que personne n'utilise. Vous gaspillez du budget sur des fichiers qui n'apportent rien à l'indexation. Google crawle votre jQuery au lieu de découvrir vos nouvelles pages produit.

Le versioning est-il vraiment une bonne pratique ?

En dev web moderne, le versioning automatique est partout : Webpack, Vite, Next.js ajoutent des hash aux noms de fichiers à chaque build. Résultat : app.abc123.js devient app.def456.js même si tu changes une virgule dans le code. Chaque déploiement invalide le cache Google.

Pour un site avec plusieurs déploiements par jour, c'est problématique. Google doit retélécharger tous les bundles à chaque crawl. Une solution : séparer le code stable du code volatile. Vendor chunks (React, libs tierces) changent rarement, code métier change souvent. Si tu bundles tout ensemble, tu forces Google à tout recharger à chaque fois.

Que faut-il faire concrètement pour optimiser le budget de crawl JavaScript ?

Auditez vos logs de crawl pour identifier les fichiers JS/CSS les plus téléchargés par Googlebot. Si vous voyez des centaines de requêtes pour des polyfills inutiles ou des versions obsolètes de jQuery, c'est du gâchis pur. Supprimez ou différez le chargement de tout ce qui n'est pas critique pour le rendu initial.

Mettez en place un système de versioning intelligent : hash basé sur le contenu du fichier, pas sur la date. Webpack le fait par défaut avec [contenthash]. Évitez les query strings (?v=123) qui posent parfois problème avec certains CDN. Préférez app.[hash].js dans le nom de fichier.

Quelles erreurs éviter absolument ?

Ne versionnez pas à outrance. Si vous déployez 10 fois par jour et que chaque déploiement change tous vos bundles, Google ne peut plus utiliser son cache. Vous perdez l'avantage. Réservez le versioning aux mises à jour significatives, ou utilisez un système de chunks stable comme expliqué plus haut.

Autre piège : charger des dizaines de petits fichiers JS au lieu de les bundler. Oui, HTTP/2 gère mieux les requêtes multiples, mais chaque fichier compte dans le budget de crawl. Un bundle de 200 Ko en un fichier consomme moins de budget que 50 fichiers de 4 Ko chacun. Trouvez l'équilibre entre performance navigateur et efficacité crawl.

Comment vérifier que votre configuration est optimale ?

Consultez régulièrement les rapports de statistiques d'exploration dans Google Search Console. Si vous voyez des pics de requêtes après chaque déploiement, c'est signe que votre versioning invalide le cache. Comparez le nombre de requêtes sur plusieurs semaines : une augmentation soudaine indique souvent un problème de cache.

Analysez vos logs serveur pour distinguer les crawls HTML des crawls ressources. Si Googlebot passe 80% de son temps à télécharger des JS/CSS et seulement 20% à découvrir du contenu, vous avez un déséquilibre. L'idéal : la majorité du budget consommée sur les pages stratégiques, pas sur les assets.

• Auditer les logs de crawl pour identifier les fichiers JS/CSS téléchargés massivement par Googlebot
• Configurer un versioning basé sur le hash du contenu réel ([contenthash] dans Webpack/Vite)
• Séparer vendor chunks (librairies stables) et application code (code métier changeant)
• Limiter le nombre de fichiers JS/CSS distincts : privilégier le bundling intelligent
• Monitorer les rapports Search Console pour détecter les pics de crawl post-déploiement
• Vérifier que les fichiers statiques sont servis via CDN pour protéger le serveur origin