Pourquoi Googlebot crawle-t-il trop vos CSS et JS ?

Qu'est-ce qui déclenche un crawl excessif de CSS/JS ?

Googlebot traite les ressources CSS et JavaScript de manière distincte du HTML pour construire le rendu complet d'une page. Contrairement au HTML qui change fréquemment, ces fichiers restent généralement stables entre les mises à jour.

Le problème survient quand le système de cache de Google ne retient pas correctement ces ressources. Au lieu de les récupérer une fois puis de les réutiliser pour plusieurs pages, Googlebot les redemande à chaque session de crawl. Pour un site avec 10 000 pages partageant 3 fichiers CSS et 5 fichiers JS, cela multiplie inutilement les requêtes par milliers.

Comment identifier un crawl anormal sur ces fichiers ?

La Search Console affiche le volume de crawl par type de ressource dans le rapport de statistiques d'exploration. Un signal d'alerte : vos fichiers CSS/JS représentent plus de 30-40% du volume total de requêtes alors qu'ils constituent moins de 1% de vos URLs.

Regardez aussi les logs serveur. Si vous constatez que Googlebot Desktop et Mobile téléchargent les mêmes fichiers CSS toutes les 2-3 heures sans changement de version, c'est typiquement un défaut de cache côté Google.

Pourquoi Google ne résout-il pas ça automatiquement ?

La déclaration de Mueller est révélatrice : Google demande aux webmasters de signaler le problème plutôt que de le détecter et corriger automatiquement. Cela suggère que leur infrastructure de cache distribuée rencontre des situations où elle perd la trace des ressources déjà crawlées.

Les headers HTTP de cache (Cache-Control, ETag, Last-Modified) devraient théoriquement suffire. Mais Google opère sur un réseau mondial de crawlers qui ne partagent pas toujours parfaitement leur état. Un datacenter à Tokyo peut recrawler ce qu'un datacenter en Californie vient déjà de récupérer.

• Le cache de Google n'est pas infaillible malgré leurs moyens techniques
• Les ressources statiques (CSS/JS) devraient être crawlées 10-20x moins souvent que le HTML
• Un signal d'alerte clair : augmentation brutale des hits Googlebot sur des fichiers inchangés
• La solution officielle passe par un signalement manuel dans la Search Console, pas par un ajustement technique de votre côté

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

Oui, et c'est même une confirmation précieuse. Les SEO surveillant leurs logs ont régulièrement constaté ce comportement depuis des années. Google crawle parfois des fichiers CSS identiques 50 à 100 fois par jour sur des sites de taille moyenne, sans raison technique apparente.

La nouveauté ici, c'est l'aveu officiel que le problème vient du côté de Google, pas d'une mauvaise configuration du site. Pendant des années, la réponse standard était de vérifier nos headers de cache ou notre CDN. Aujourd'hui, Mueller reconnaît explicitement un dysfonctionnement interne.

Quelles limites cette déclaration présente-t-elle ?

Deux angles morts majeurs. D'abord, aucun seuil quantitatif n'est donné. À partir de combien de requêtes quotidiennes sur un même fichier CSS faut-il considérer que c'est excessif ? 10 ? 100 ? 1000 ? Sans métrique, difficile de savoir si votre situation justifie un signalement. [À vérifier] : Google ne précise pas non plus le délai de résolution après signalement.

Ensuite, la méthode de remontée reste floue. Mueller mentionne "signaler via la Search Console", mais où exactement ? Le formulaire de feedback général ? Le rapport d'erreurs d'exploration ? Cette absence de procédure claire complique l'application concrète du conseil.

Dans quels cas ce conseil ne s'applique-t-il pas ?

Si vos fichiers CSS/JS changent réellement souvent (plusieurs fois par jour avec des hash de version différents), le crawl fréquent est normal et souhaitable. Google doit suivre vos mises à jour pour rendre correctement vos pages.

Autre exception : les sites avec du CSS/JS inline dans le HTML. Là, chaque page constitue sa propre "ressource" CSS, donc le volume de crawl sera mécaniquement élevé. Le conseil de Mueller s'adresse aux architectures classiques avec des fichiers externes partagés entre de nombreuses pages.

Comment vérifier si votre site est concerné ?

Première étape : analysez vos logs serveur sur les 30 derniers jours. Filtrez les requêtes Googlebot et comptez combien de fois chaque fichier CSS/JS a été téléchargé. Comparez ce chiffre au nombre de pages HTML crawlées.

Ratio sain : 1 téléchargement CSS/JS pour 50-200 pages HTML visitées (selon la fréquence de mise à jour de votre site). Ratio anormal : 1 téléchargement pour moins de 10 pages. Dans la Search Console, le rapport Statistiques sur l'exploration affiche la répartition par type de fichier, mais sans le détail fichier par fichier que seuls vos logs fournissent.

Que faire concrètement si vous détectez un crawl excessif ?

Avant de signaler à Google, vérifiez votre configuration technique. Headers Cache-Control sur vos CSS/JS : visez "max-age=31536000" avec un système de versioning (style.css?v=1.2.3). Headers ETag présents et cohérents. Si tout est correct de votre côté et que le crawl reste anormal pendant 2+ semaines, préparez un signalement structuré.

Documentez : captures d'écran du rapport Search Console, extraits de logs montrant la fréquence, liste des fichiers concernés avec leurs URLs complètes. Soumettez via le formulaire de feedback de la Search Console (icône en haut à droite de l'interface) en étant précis et factuel. Évitez les généralités du type "Googlebot crawle trop", donnez des chiffres.

Quelles erreurs éviter dans la gestion de ce problème ?

Ne réduisez pas artificiellement la fréquence de crawl dans la Search Console pour compenser. Cet outil ralentit tout le crawl, y compris vos nouvelles pages HTML qui ont besoin d'être découvertes rapidement. Vous traiteriez le symptôme en créant un problème d'indexation plus grave.

Ne bloquez jamais CSS/JS dans robots.txt comme "solution". Google l'a répété cent fois : cela empêche le rendu correct et peut dégrader votre positionnement. Le crawl excessif est un bug de leur infrastructure de cache, pas une raison légitime de bloquer l'accès aux ressources de rendu.

• Analyser les logs serveur sur 30 jours pour quantifier le ratio crawl CSS/JS vs HTML
• Vérifier que vos headers de cache sont optimaux (Cache-Control, ETag, versioning)
• Documenter le problème avec captures d'écran et données chiffrées avant signalement
• Utiliser le formulaire de feedback Search Console, pas les forums publics
• Ne jamais bloquer CSS/JS dans robots.txt pour "économiser" du crawl
• Monitorer l'évolution post-signalement pendant 4-6 semaines