Le budget de crawl compte-t-il vraiment les ressources JavaScript et XHR ?

Le budget de crawl couvre-t-il réellement chaque requête réseau d'une page ?

Oui. Google ne se contente pas de récupérer le HTML initial. Quand Googlebot rend une page, il charge et exécute les scripts JavaScript, puis déclenche les requêtes XHR/Fetch nécessaires pour construire le DOM final. Chacune de ces opérations consomme une fraction du budget alloué au site.

C'est un changement de paradigme pour beaucoup de SEO habitués à raisonner en « nombre d'URLs crawlées ». Avec des architectures modernes (React, Vue, Angular), une seule URL peut déclencher 40-80 requêtes réseau — fichiers JS, CSS, polyfills, APIs tierces, fonts, analytics. Chaque requête compte. Si votre site fait 100k pages et que chaque page déclenche 60 requêtes, vous demandez à Googlebot de traiter 6 millions de ressources.

Qu'entend Google par « rendu de la page » exactement ?

Le rendu, c'est la phase où Googlebot exécute le JavaScript pour obtenir le DOM final indexable. Contrairement au crawl HTML simple (récupérer le source brut), le rendu mobilise un navigateur headless (Chromium) qui interprète les scripts, applique les transformations DOM, et déclenche les appels réseau.

Cette étape est coûteuse en ressources CPU et réseau. Google doit maintenir des fermes de serveurs avec Chromium pour rendre des millions de pages. D'où l'idée d'un budget : Google ne peut pas tout rendre en temps réel, surtout pour les sites qui génèrent des tonnes de requêtes asynchrones. Si ton site charge 15 fichiers JS externes à chaque visite, Googlebot doit les télécharger, les parser, les exécuter — et tout ça compte dans le temps qu'il accepte de passer sur ton domaine.

Pourquoi cette déclaration change-t-elle la donne pour les sites JavaScript-heavy ?

Parce que jusqu'ici, beaucoup de devs et SEO pensaient que seules les URLs « vraies » (celles qui renvoient un HTML distinct) pesaient dans le budget. Or, un site SPA moderne peut avoir 10 URLs mais 500 ressources critiques pour le rendu. Si Google crawle ces 10 pages et doit charger 500 ressources au total, tu consommes bien plus que 10 slots.

Soyons honnêtes : personne ne sait si Google alloue un budget distinct pour les ressources (JS, XHR) ou si tout est compté dans un pot commun. Mais l'impact pratique est clair — les sites qui chargent des centaines de requêtes par page risquent de saturer leur budget avant même d'avoir fait crawler toutes leurs URLs stratégiques. Et c'est là que ça coince.

• Le budget de crawl ne se mesure plus en pages, mais en requêtes réseau totales (HTML + JS + XHR + assets critiques).
• Les sites SPA ou CSR (Client-Side Rendering) consomment beaucoup plus de budget que les sites SSR (Server-Side Rendering) à nombre d'URLs égal.
• Google doit allouer du temps CPU pour exécuter JavaScript — ce qui explique pourquoi le rendu peut être retardé de plusieurs heures ou jours après le crawl initial.
• Les requêtes XHR déclenchées au runtime (par exemple, une API produit qui charge des variantes) comptent aussi — même si elles ne génèrent pas d'URL distincte.
• Optimiser le budget de crawl signifie désormais réduire le nombre total de requêtes réseau par page, pas seulement le nombre de pages.

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

Oui, globalement. Les SEO qui gèrent de gros sites e-commerce ou des portails de contenu ont observé depuis des années que les sites JS-heavy crawlent moins vite à budget égal. Les logs Googlebot montrent qu'il passe plus de temps par page sur un site React mal optimisé que sur un site SSR classique. La déclaration de Google vient confirmer ce qu'on suspectait : chaque requête réseau pèse.

Mais — et c'est là que ça devient trouble — Google ne donne aucun chiffre. On ne sait pas si une requête XHR « coûte » autant qu'une page HTML, ni si les fichiers JS externes hébergés sur CDN (ex: analytics, fonts) sont comptés de la même manière. [A vérifier] : Google alloue-t-il un pool distinct pour les ressources tierces ? Mystère total. En pratique, beaucoup de sites constatent que bloquer les scripts analytics ou les pixels tiers via robots.txt améliore la vitesse de crawl — ce qui suggère que oui, ces requêtes comptent aussi.

Quelles sont les zones grises que Google ne clarifie pas ?

Premier point : qu'est-ce qui est vraiment « critique » pour le rendu ? Google dit qu'il crawle les ressources nécessaires au rendu, mais comment détermine-t-il ce qui est nécessaire ? Si ton site charge 50 scripts, mais que seuls 10 sont bloquants pour le premier paint, est-ce que les 40 autres comptent quand même ? La réponse n'est pas claire. En théorie, Googlebot devrait ignorer les scripts non critiques — en pratique, il les charge souvent quand même.

Deuxième point : le timing du rendu. Google a confirmé que le crawl et le rendu sont deux phases distinctes. Le HTML est crawlé immédiatement, le rendu peut intervenir plusieurs jours après. Donc ton budget de crawl est-il consommé au moment du crawl HTML, ou au moment du rendu ? Si c'est au moment du rendu, ça signifie qu'un site peut être crawlé rapidement mais rendu lentement — ce qui retarde l'indexation effective. [A vérifier] : aucune donnée officielle là-dessus.

Troisième point : les erreurs réseau et timeout. Si Googlebot tente de charger un fichier JS qui timeout ou renvoie une 500, est-ce que cette requête compte quand même dans le budget ? Logiquement oui, puisque Googlebot a passé du temps à attendre. Mais encore une fois, Google ne le dit pas explicitement. Ce qui est sûr, c'est que les sites avec des dépendances externes fragiles (APIs tierces instables) risquent de gaspiller leur budget sur des requêtes qui échouent.

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

Il y a des situations où le budget de crawl n'est tout simplement pas un problème. Si tu gères un site de 50 pages, même avec 100 requêtes par page, Google crawlera tout en quelques minutes. Le budget devient critique seulement pour les gros sites (>10k URLs) ou les sites à forte vélocité (nouveaux contenus publiés quotidiennement).

Autre cas : les sites avec un SSR solide. Si ton HTML contient déjà tout le contenu indexable et que JavaScript est juste là pour améliorer l'UX (progressive enhancement), alors le rendu JS devient optionnel pour Google. Il peut indexer ton contenu dès le crawl HTML, sans passer par la phase de rendu coûteuse. C'est pour ça que le SSR reste l'approche la plus safe pour les sites SEO-critiques — moins de requêtes, moins de risques, crawl plus rapide.

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

Première étape : auditer le nombre total de requêtes par page. Utilise Chrome DevTools (onglet Network), Lance un Lighthouse, ou analyse tes logs serveur. Compte combien de fichiers JS, CSS, XHR, fonts, images sont chargés par page. Si tu dépasses 40-50 requêtes par page, tu as un problème de performance ET de crawl budget. Commence par identifier les scripts non critiques (analytics, chatbots, pixels marketing) et charge-les en différé ou via un consent manager.

Deuxième étape : regrouper et minifier les assets. Au lieu de servir 15 fichiers JS distincts, bundle-les en 2-3 fichiers critiques. Utilise code-splitting pour charger seulement le JS nécessaire à chaque page. Les frameworks modernes (Webpack, Vite, Next.js) facilitent ça. Moins de requêtes = moins de charge sur Googlebot = plus de pages crawlées par visite. Simple mais efficace.

Troisième étape : passer au SSR ou au pré-rendering quand c'est possible. Si ton site génère du contenu dynamique côté client (via XHR), demande-toi si ce contenu peut être généré côté serveur. Un catalogue produit rendu en SSR sera crawlé 10x plus vite qu'un catalogue chargé via API côté client. Oui, c'est plus complexe à mettre en œuvre — mais pour un site e-commerce de 50k URLs, c'est la différence entre un crawl complet en 1 semaine ou 1 mois.

Quelles erreurs éviter absolument ?

Erreur n°1 : bloquer les fichiers JS via robots.txt. Beaucoup de SEO pensent encore que bloquer JavaScript économise du budget. C'est faux — et même contre-productif. Si tu bloques les JS critiques, Googlebot ne peut pas rendre la page correctement, donc il indexe une version cassée ou vide. Google le dit depuis des années : ne bloquez jamais les ressources nécessaires au rendu. Par contre, bloquer les scripts tiers non critiques (analytics, pubs) peut aider — mais fais-le avec discernement.

Erreur n°2 : multiplier les appels API inutiles. Si chaque page charge une API pour afficher des « produits similaires » ou des « articles recommandés », et que ces données ne sont pas critiques pour le SEO, charge-les en lazy ou côté client après l'indexation. Googlebot n'a pas besoin de crawler 20 requêtes XHR pour indexer une fiche produit — il a besoin du titre, de la description, du prix, de la dispo. Le reste, c'est du bonus UX, pas du contenu indexable.

Erreur n°3 : ignorer les requêtes en erreur. Si tes logs montrent que Googlebot tente de charger des fichiers JS qui renvoient 404 ou 500, corrige-les immédiatement. Chaque tentative échouée consomme du budget pour rien. Nettoie tes références à d'anciens scripts, vérifie que tous tes assets critiques sont accessibles, et monitore les erreurs réseau dans la Search Console.

Comment vérifier que mon site ne gaspille pas son budget de crawl ?

Utilise la Search Console section « Statistiques d'exploration ». Regarde le nombre de requêtes par jour, le temps de téléchargement moyen, et la taille des réponses. Si le temps de téléchargement moyen augmente, c'est que Googlebot passe plus de temps par page — souvent à cause de ressources JS lourdes. Compare ce chiffre avec le nombre d'URLs crawlées : si tu as 100k URLs mais que Google ne crawle que 500 pages/jour, tu as un problème de budget.

Analyse aussi les logs serveur bruts. Cherche les patterns : combien de requêtes Googlebot fait-il par visite ? Sur quelles URLs ? Combien de temps entre deux visites ? Si tu vois que Googlebot crawle tes pages produits une fois par mois alors que tu ajoutes 100 produits par semaine, c'est un signal que ton budget est saturé. Dans ce cas, priorise les sections stratégiques via le sitemap, bloque les URLs inutiles (filtres, pages paginées infinies), et optimise le temps de réponse.

• Réduire le nombre de requêtes réseau par page à moins de 30-40 (HTML + JS + XHR + assets critiques).
• Bundler et minifier les fichiers JavaScript pour limiter les requêtes HTTP distinctes.
• Implémenter du SSR ou du pré-rendering pour les pages stratégiques (catalogues, fiches produits).
• Charger les scripts tiers non critiques (analytics, chat, pixels) en différé ou via consent manager.
• Monitorer les logs Googlebot pour détecter les requêtes en erreur (404, 500, timeout) et les corriger.
• Utiliser la Search Console pour suivre l'évolution du temps de téléchargement moyen et ajuster en conséquence.