Pourquoi Googlebot ignore-t-il vos hints de préchargement des ressources ?

Que met exactement Google en cache ?

Googlebot met en cache les ressources statiques (CSS, JavaScript, images, polices) nécessaires au rendu des pages qu'il explore. Concrètement, quand le bot visite une page de votre site, il stocke ces éléments dans son infrastructure.

Lors des visites suivantes, il réutilise ces ressources mises en cache au lieu de les télécharger à nouveau depuis vos serveurs. Cette mécanique s'applique aux ressources identifiées comme stables — celles dont l'URL et le contenu ne changent pas à chaque requête.

Pourquoi cette approche rend les hints de préchargement inutiles pour Google ?

Les resource hints (preload, prefetch, dns-prefetch, preconnect) sont conçus pour optimiser le chargement dans le navigateur d'un utilisateur réel. Ils indiquent au navigateur quoi anticiper pour accélérer l'affichage.

Mais Googlebot ne fonctionne pas comme un navigateur classique qui découvre une page pour la première fois. Il a déjà visité vos pages, il a déjà récupéré vos ressources. Les lui signaler via des hints n'apporte rien — il les a déjà en stock.

Quelles sont les implications concrètes pour la charge serveur ?

Cette stratégie de cache côté Google réduit drastiquement le volume de requêtes HTTP que vos serveurs doivent traiter lors des passages du bot. C'est particulièrement visible sur les sites à fort volume de pages ou avec des ressources lourdes.

En revanche, cela signifie aussi que Google peut ne pas détecter immédiatement un changement de CSS ou de JS si la ressource est encore en cache chez lui. Un point à garder en tête lors des déploiements.

• Googlebot cache les ressources statiques pour éviter de les re-télécharger à chaque crawl
• Les hints de préchargement (preload, prefetch) ne servent à rien pour le bot — il a déjà les ressources
• Cette stratégie réduit la charge serveur et économise de la bande passante côté hébergeur
• Attention : un changement de ressource peut mettre du temps à être pris en compte si Google utilise sa version en cache

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

Oui, et elle explique plusieurs comportements constatés depuis des années. Les logs serveur montrent que Googlebot ne re-télécharge pas systématiquement toutes les ressources statiques à chaque visite. Il se concentre sur le HTML, les nouvelles ressources ou celles qui ont changé.

Cela dit, Google reste flou sur la durée de rétention du cache et les conditions exactes de rafraîchissement. Est-ce lié à un TTL ? À la fréquence de crawl ? Aux signaux de changement (Last-Modified, ETag) ? [À vérifier] — aucune donnée officielle précise sur ces mécanismes.

Quelles nuances faut-il apporter à cette déclaration ?

Gary Illyes parle de « certains hints » qui ne sont pas pertinents. Il ne dit pas que tous les hints sont inutiles. Le dns-prefetch ou le preconnect peuvent encore avoir un sens si Googlebot doit établir des connexions vers des domaines tiers qu'il n'a jamais rencontrés.

Par ailleurs, ces hints restent cruciaux pour l'expérience utilisateur et les Core Web Vitals. Ne les supprimez pas sous prétexte qu'ils ne servent pas à Google — ils servent à vos visiteurs réels, et c'est ce qui compte pour le ranking.

Dans quels cas cette logique de cache pose-t-elle problème ?

Lors d'un refonte ou d'un changement majeur de CSS/JS, le cache de Google peut retarder la prise en compte des modifications. Si le bot utilise une ancienne version de votre feuille de style, le rendu qu'il analyse ne correspond pas à la réalité.

Solution : forcer le rafraîchissement via un changement d'URL de la ressource (cache busting avec query string ou hash). Mais là encore, Google ne précise pas si un simple ?v=2 suffit ou s'il faut un hash complet du fichier. [À vérifier] selon votre contexte.

Que faut-il faire concrètement avec cette information ?

D'abord, arrêtez d'optimiser vos hints de préchargement spécifiquement pour Googlebot. Concentrez-vous sur l'utilisateur réel : c'est lui qui profite du preload, du prefetch, du dns-prefetch.

Ensuite, assurez-vous que vos ressources statiques sont correctement versionnées. Utilisez un système de cache busting (hash de fichier dans l'URL) pour forcer le rafraîchissement quand vous modifiez un CSS ou un JS critique pour le rendu.

Quelles erreurs éviter absolument ?

Ne supprimez pas vos resource hints sous prétexte qu'ils n'impactent pas Googlebot. Ils restent essentiels pour les Core Web Vitals et l'expérience utilisateur, qui sont des facteurs de ranking confirmés.

Évitez aussi de sur-optimiser pour un hypothétique « crawl budget » lié aux ressources. Google gère ça de son côté avec son cache. Votre enjeu : garantir que les ressources critiques pour le rendu sont accessibles et à jour.

Comment vérifier que votre site est bien géré par Google ?

• Inspectez vos pages clés dans la Search Console (outil d'inspection d'URL) et vérifiez le rendu mobile/desktop
• Comparez le rendu affiché par Google avec le rendu réel dans un navigateur — repérez les décalages
• Après un déploiement majeur de CSS/JS, demandez une réindexation via la Search Console pour accélérer la prise en compte
• Utilisez des URLs versionnées (cache busting) pour vos ressources critiques plutôt que de compter sur les headers HTTP seuls
• Surveillez vos logs serveur pour identifier les ressources que Googlebot récupère vraiment à chaque visite