Google sur-cache-t-il vraiment les ressources de votre site ?

Que signifie exactement "sur-cacher" pour Google ?

Quand Martin Splitt évoque un cache "très agressif", il parle d'une stratégie conservatrice : Google préfère garder une version fonctionnelle d'une ressource plutôt que de risquer de la perdre. Le moteur stocke les fichiers CSS, JavaScript, images et autres assets pendant des périodes prolongées, même si ces ressources ont été modifiées ou sont temporairement inaccessibles côté serveur.

Cette approche repose sur une logique simple : les sites web modifient rarement leurs ressources critiques plusieurs fois par jour. Google optimise donc son crawl budget en ne refetchant pas systématiquement chaque fichier à chaque passage du bot. Le moteur se concentre sur le HTML des pages et réutilise les assets déjà en cache.

Pourquoi Google ne récupère-t-il pas les ressources à chaque rendu ?

Récupérer l'intégralité des ressources à chaque crawl représenterait une charge serveur colossale — pour vous comme pour Google. Le moteur indexe des milliards de pages. Si Googlebot devait télécharger à nouveau chaque CSS, chaque police, chaque script tiers à chaque visite, le web s'effondrerait sous la bande passante consommée.

Google applique donc des heuristiques de fraîcheur. Le moteur détecte quand un fichier change (via les en-têtes HTTP, les ETags, les dates de modification) et décide s'il doit le refetcher. Dans la majorité des cas, une feuille de style ou un bundle JS reste stable pendant des semaines, voire des mois. Le cache joue son rôle d'amortisseur.

Que se passe-t-il concrètement si une ressource est cassée ?

Martin Splitt affirme que Google réessaie les rendus si nécessaire. Si le moteur détecte qu'une page ne s'affiche pas correctement (layout shift brutal, contenu manquant, erreurs JS critiques), il peut relancer un rendu quelques jours plus tard. Cette politique tolère les incidents temporaires — maintenance, CDN flottant, erreur 500 ponctuelle.

Soyons honnêtes : cette tolérance a ses limites. Si votre fichier CSS principal retourne une 404 pendant trois semaines, Google finira par indexer votre page avec un rendu cassé. Le "réessai" n'est pas une garantie infinie. C'est une bouée de secours, pas une stratégie de déploiement.

• Le cache de Google conserve les ressources pendant des durées variables — généralement plusieurs semaines pour les assets stables.
• Une erreur ponctuelle (500, timeout) ne déclenche pas immédiatement un rendu cassé — Google réutilise la version en cache.
• Le moteur réessaie les rendus ratés, mais cette politique n'est pas documentée avec des délais précis.
• Les modifications de ressources ne sont pas détectées instantanément — comptez plusieurs jours avant qu'un nouveau CSS soit pris en compte.
• Le crawl budget est optimisé : Google ne refetch que les ressources qu'il juge potentiellement modifiées.

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

Oui, et c'est même l'une des déclarations les plus vérifiables empiriquement. Les SEO qui utilisent des outils comme OnCrawl ou Botify constatent régulièrement que Googlebot ne refetch pas les assets à chaque passage. Les logs serveur montrent que le bot crawle le HTML quotidiennement mais ne touche aux CSS/JS que tous les 7 à 21 jours en moyenne — parfois plus si le site est stable.

Ce comportement s'observe particulièrement sur les sites d'actualité : Google crawle les nouvelles pages plusieurs fois par jour, mais les ressources globales (header.css, bundle.js) restent en cache pendant des semaines. C'est cohérent avec une stratégie de sur-cache.

Quelles nuances faut-il apporter à ce discours rassurant ?

Le problème, c'est que cette tolérance peut masquer des erreurs critiques. Si vous déployez un nouveau CSS qui casse le rendu mobile et que Google utilise encore l'ancienne version en cache, vous ne verrez aucun impact immédiat dans la Search Console. Vous pourriez croire que tout va bien pendant deux semaines — jusqu'à ce que Google refetch enfin la ressource et indexe votre site avec un layout explosé.

Martin Splitt dit "ce n'est normalement pas un problème" — mais [À vérifier] : quelle est la définition de "momentanément cassé" ? Une heure ? Un jour ? Une semaine ? Google ne donne aucun chiffre. Cette zone grise rend difficile toute stratégie de déploiement robuste. Si vous corrigez un bug CSS en production, vous n'avez aucune garantie sur le délai de propagation dans l'index.

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

Google sur-cache les ressources stables et accessibles. Si votre CDN retourne systématiquement des 403 ou si vos fichiers JS sont bloqués par le robots.txt, le cache ne sert à rien : Google n'a rien à mettre en cache. De même, les ressources générées dynamiquement avec des query strings aléatoires (ex: style.css?v=1234567890) peuvent court-circuiter le cache si elles changent à chaque crawl.

Les sites en migration ou refonte sont également dans une zone à risque. Si vous changez massivement vos URLs de ressources (nouveau CDN, nouveau hash de build), Google doit tout refetcher — et ça prend du temps. Pendant cette période, vous pouvez avoir un mix incohérent entre anciennes et nouvelles ressources, ce qui produit des rendus bancals.

Que faut-il faire concrètement pour tirer parti de ce sur-cache ?

D'abord, assurez-vous que vos ressources critiques sont accessibles en permanence. Google peut tolérer une erreur temporaire, mais si votre CSS principal retourne des 500 pendant 48 heures, vous jouez avec le feu. Utilisez un CDN robuste avec failover automatique et monitorer les uptime de vos assets avec des outils comme Pingdom ou UptimeRobot.

Ensuite, exploitez les en-têtes HTTP de cache intelligemment. Un Cache-Control bien configuré (ex: max-age=2592000 pour un mois) indique à Google que la ressource est stable. Le moteur peut alors ajuster sa fréquence de refetch. À l'inverse, un no-cache sur chaque fichier force Google à vérifier la fraîcheur à chaque crawl — ce qui consomme du crawl budget inutilement.

Quelles erreurs éviter absolument ?

Ne déployez jamais une refonte CSS/JS majeure sans versionning explicite. Si vous écrasez style.css avec un contenu radicalement différent, Google peut mettre des semaines à s'en apercevoir. Préférez un système de fingerprinting (style.abc123.css) qui force le refetch immédiat. Webpack, Vite, Parcel et consorts font ça nativement.

Évitez aussi de bloquer des ressources dans le robots.txt "pour économiser du crawl budget". Google ne peut pas sur-cacher ce qu'il n'a jamais pu fetcher. Si un CSS est bloqué puis débloqué, le moteur part de zéro — et votre rendu peut rester cassé pendant plusieurs cycles de crawl. C'est un piège classique en migration.

Comment vérifier que mon site bénéficie bien de ce cache ?

Analysez vos logs serveur. Comparez la fréquence de crawl du HTML (User-agent: Googlebot) versus celle des assets (même User-agent, mais sur les URLs de ressources). Si le bot crawle vos pages 3 fois par jour mais vos CSS/JS 1 fois par semaine, c'est bon signe : le cache fait son job. Un écart faible signale un problème de cache ou des ressources trop volatiles.

Utilisez aussi la Search Console pour surveiller les erreurs de rendu. Si Google détecte des problèmes de layout ou de contenu manquant, c'est peut-être qu'une ressource en cache est obsolète ou que le "réessai" n'a pas fonctionné. Croisez avec vos déploiements : un spike d'erreurs deux semaines après une release CSS indique souvent un décalage de cache.

• Configurez des en-têtes Cache-Control cohérents (max-age de 1 à 3 mois pour les assets stables).
• Utilisez un système de fingerprinting ou versioning pour les CSS/JS critiques (ex: bundle.abc123.js).
• Ne bloquez jamais les ressources de rendu dans le robots.txt — Google doit pouvoir les fetcher au moins une fois.
• Monitorez l'uptime de votre CDN et de vos assets : un 500 ponctuel passe, mais pas 48 heures de downtime.
• Analysez vos logs serveur tous les mois pour vérifier la fréquence de refetch des ressources par Googlebot.
• Croisez les erreurs de rendu dans la Search Console avec vos dates de déploiement pour détecter les décalages de cache.