Google ignore-t-il vraiment les en-têtes Cache-Control pour le crawl ?

Pourquoi Google ignore-t-il les en-têtes Cache-Control ?

La déclaration de Martin Splitt bouscule une croyance ancrée : que les directives Cache-Control suffiraient à contrôler quand Googlebot doit re-télécharger une ressource. Le problème ? Une majorité de sites configurent des durées de cache trop longues sur leurs assets (CSS, JS, images).

Concrètement, quand un développeur pousse une mise à jour d'un fichier app.js mais que le header indique max-age=31536000 (un an), Googlebot respecterait théoriquement cette directive et garderait l'ancienne version en cache. Résultat : le bot crawle une version obsolète du site, rate du contenu généré par JavaScript, ou interprète mal le rendu.

Google a visiblement constaté ce pattern à grande échelle. Plutôt que de se battre contre des configurations défaillantes, l'équipe a décidé d'ignorer purement et simplement ces headers dans la plupart des cas. C'est un aveu indirect : on ne peut pas faire confiance aux webmasters pour gérer correctement leur politique de cache.

Qu'est-ce que le versioning par hash et pourquoi c'est la solution ?

Le versioning par hash (ou fingerprinting) consiste à inclure un identifiant unique dans le nom du fichier : app.abc123.js où abc123 est un hash du contenu. Chaque modification du fichier génère un nouveau hash, donc une nouvelle URL.

Cette approche résout le problème à la racine. Puisque l'URL change à chaque déploiement, il n'y a plus d'ambiguïté : Googlebot voit une nouvelle ressource et la télécharge. Pas besoin de vérifier un header Cache-Control — l'URL elle-même devient le signal de fraîcheur.

Les frameworks modernes (Webpack, Vite, Next.js, etc.) implémentent ce mécanisme par défaut. Mais beaucoup de sites legacy ou CMS custom ne l'ont jamais mis en place, continuant à servir des fichiers avec des noms statiques et des headers de cache mal calibrés.

Quel est l'impact sur le rendering JavaScript et l'indexation ?

Si Googlebot crawle une version périmée de vos scripts, il peut manquer du contenu critique généré côté client. Un module qui charge dynamiquement des blocs de texte, un lazy-loading d'images, un menu de navigation rendu en React — tout cela peut ne jamais être vu par le bot.

Le risque est particulièrement élevé sur les sites JavaScript-heavy (SPAs, applications React/Vue/Angular). Si le fichier bundle principal reste en cache pendant des semaines alors que vous avez déployé une refonte, Googlebot indexe l'ancienne version. Les changements de contenu, les optimisations de performance, les corrections de bugs SEO — tout passe à la trappe.

C'est aussi valable pour les Core Web Vitals. Une mise à jour qui améliore le LCP ou réduit le JS inutilisé ne sera mesurée par Google que si le bot charge effectivement la nouvelle version. Un cache mal géré peut retarder la prise en compte de vos optimisations de plusieurs semaines.

• Google ignore Cache-Control pour éviter de crawler des versions obsolètes de ressources
• Le versioning par hash (app.abc123.js) est la méthode recommandée pour forcer le re-téléchargement
• Sans versioning, le bot peut indexer une version périmée de votre site pendant des semaines
• Impact critique sur les sites JavaScript-heavy où le contenu dépend de bundles à jour
• Les Core Web Vitals peuvent stagner si Google ne détecte pas vos améliorations de performance

Cette approche est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui et non. Sur les sites qui utilisent déjà du versioning automatique (généralement les apps modernes), on n'a jamais vraiment eu de souci de cache côté Googlebot. Le problème se pose surtout sur les sites legacy, les CMS custom, ou les projets où l'équipe dev ne maîtrise pas les bonnes pratiques.

Plusieurs tests empiriques montrent que Googlebot peut effectivement crawler une version obsolète d'un fichier JS pendant plusieurs jours après un déploiement si l'URL n'a pas changé. Le Mobile-Friendly Test ou l'outil d'inspection d'URL affichent parfois un rendu différent du site live — un symptôme classique de ce problème de cache.

Ce qui est moins clair : Google dit ignorer "généralement" les headers, mais ne précise pas les exceptions. Y a-t-il des cas où Cache-Control est respecté ? Sur quels critères ? [A vérifier] — l'équipe ne donne pas de seuil ni de règle précise.

Le versioning par hash est-il vraiment la seule solution ?

C'est la solution la plus fiable, mais pas la seule. On peut aussi jouer sur les query strings (app.js?v=123), même si c'est moins élégant et que certains proxies/CDN les ignorent pour le cache. Une autre approche : forcer un re-crawl via l'API Indexing (mais limitée à certains types de contenu).

Le vrai problème, c'est que beaucoup de sites n'ont aucun système de versioning en place. Migrer vers du hash automatique demande de revoir la chaîne de build : intégrer un bundler moderne, modifier les templates pour injecter les URLs hashées, configurer le CDN pour servir les bonnes versions. Sur un site legacy de 10 ans, ça peut être un chantier colossal.

Et puis il y a un angle mort : les ressources tierces. Vous ne contrôlez pas le versioning d'un script Google Tag Manager, d'un player vidéo embarqué, d'un widget de chat. Si ces ressources sont mal cachées, Googlebot peut aussi crawler une version obsolète — et là, vous n'avez aucun levier.

Quelles sont les limites de cette recommandation ?

Splitt ne parle que du crawl, mais qu'en est-il du rendering côté client pour les utilisateurs réels ? Si vous mettez max-age=0 pour forcer Google à re-télécharger, vous dégradez les performances pour vos visiteurs. Le versioning par hash permet de résoudre cette tension : cache long + invalidation instantanée via changement d'URL.

Autre limite : cette déclaration ne mentionne pas les images. On parle de JS et CSS, mais qu'en est-il des assets graphiques ? Beaucoup de sites servent des images sans versioning, avec des URLs statiques. Si Google ignore aussi Cache-Control sur ces fichiers, ça pourrait expliquer certains retards dans la prise en compte de nouvelles images dans Google Images.

Que faut-il faire concrètement pour implémenter le versioning par hash ?

Premier réflexe : auditer votre chaîne de build. Si vous utilisez Webpack, Vite, Parcel, Rollup ou Next.js, le versioning par hash est probablement déjà actif par défaut en mode production. Vérifiez dans le code source de vos pages si les URLs de vos assets contiennent bien un hash (ex : app.3f2a1b.js).

Si ce n'est pas le cas, activez l'option dans votre config de bundler. Sous Webpack, c'est output.filename: '[name].[contenthash].js'. Sous Vite, c'est natif. Assurez-vous aussi que votre HTML (ou vos templates PHP/JSX/etc.) injecte dynamiquement ces URLs hashées — sinon vous allez servir des chemins obsolètes.

Pour les sites sans bundler moderne (WordPress custom, CMS propriétaire, HTML statique), il faudra scripter la génération de hash. Un script Node.js peut calculer le MD5 de chaque fichier et renommer les assets au moment du déploiement. C'est plus artisanal mais ça fonctionne.

Comment vérifier que Googlebot crawle bien les bonnes versions ?

Utilisez l'outil d'inspection d'URL dans la Search Console. Demandez un test en direct, puis examinez les ressources chargées dans l'onglet "Plus d'infos > Ressources téléchargées". Comparez les URLs et les timestamps avec ce qui est déployé en production.

Un autre signal : les logs serveur. Filtrez les requêtes de Googlebot et vérifiez quelles URLs de JS/CSS sont appelées. Si vous voyez des chemins sans hash ou des versions datant de plusieurs semaines, c'est un red flag. Le bot utilise peut-être son cache interne malgré vos déploiements.

Enfin, testez avec le Mobile-Friendly Test ou le Rich Results Test. Ces outils affichent le rendu tel que Googlebot le voit. Si le contenu généré par JavaScript est absent ou obsolète, c'est probablement un problème de cache sur vos bundles.

Quelles erreurs éviter lors de la migration vers le versioning ?

Erreur classique : oublier de mettre à jour les chemins dans le HTML. Vous générez app.abc123.js mais votre template continue d'appeler app.js — résultat 404. Les bundlers modernes gèrent ça automatiquement via des plugins d'injection HTML, mais sur un setup custom il faut le faire manuellement.

Autre piège : le cache CDN. Si votre CDN (Cloudflare, Fastly, etc.) cache agressivement les pages HTML elles-mêmes, les utilisateurs peuvent recevoir un HTML obsolète qui référence des assets hashés déjà supprimés du serveur. Assurez-vous que le cache HTML est invalidé à chaque déploiement, ou utilisez un TTL court.

Enfin, attention aux Service Workers. Si vous avez implémenté un SW pour le mode offline, il doit être capable de gérer les nouvelles URLs hashées. Sinon, les utilisateurs récurrents resteront bloqués sur l'ancienne version en cache, même si le serveur sert la nouvelle.

• Activer le versioning par hash dans votre bundler (Webpack, Vite, Rollup, etc.)
• Vérifier que les templates HTML injectent dynamiquement les URLs hashées
• Tester avec l'outil d'inspection d'URL de la Search Console après chaque déploiement
• Analyser les logs serveur pour détecter si Googlebot charge des versions obsolètes
• Invalider le cache CDN sur les pages HTML à chaque mise à jour
• Mettre à jour la logique des Service Workers pour gérer les nouvelles URLs