Mise en cache pour le SEO

En bref — La mise en cache consiste à conserver une copie d’une page ou d’un fichier pour éviter de le reconstruire et de le renvoyer depuis zéro. Elle accélère le site pour les visiteurs comme pour les robots et leur permet de ne pas télécharger à nouveau les pages inchangées. Elle n’améliore pas directement le classement, mais la vitesse et l’efficacité d’exploration qu’elle procure ont un effet indirect.

Qu’est-ce que la mise en cache ?

À chaque ouverture d’une page, le serveur doit générer le HTML, transmettre les images et envoyer le CSS et le JavaScript. La mise en cache conserve une copie prête à l’emploi de ces ressources afin que la visite suivante puisse les réutiliser sans recommencer tout ce travail.

Trois emplacements de copie comptent pour le SEO :

1. Le cache du navigateur — les fichiers sont enregistrés sur l’appareil du visiteur ; une deuxième consultation ou une visite ultérieure se charge presque immédiatement.
2. Le cache du CDN, ou cache périphérique — des copies résident sur des serveurs répartis dans le monde ; la ressource est transmise depuis un emplacement proche de l’utilisateur ou du robot, plutôt que depuis le seul serveur d’origine.
3. Le cache propre au robot — Googlebot et Bingbot mémorisent si une page a changé depuis leur dernière visite et évitent de la télécharger à nouveau dans le cas contraire.

Pourquoi est-ce important pour le SEO ?

Deux raisons distinctes :

• La vitesse. Une livraison plus rapide améliore les Core Web Vitals, notamment le délai de réponse du serveur — TTFB — et l’apparition du contenu principal — LCP. La vitesse fait partie des signaux d’expérience sur la page de Google.
• L’efficacité de l’exploration. Lorsqu’un robot sait qu’une page n’a pas changé, il évite un téléchargement inutile. Sur un grand site, il peut consacrer ce temps aux pages nouvelles et mises à jour.

Une distinction essentielle

Le « cache de Google » et la mise en cache HTTP sont deux choses différentes. L’ancien opérateur de recherche cache:, qui permettait d’afficher une copie enregistrée par Google, a été retiré en 2024. Cela ne concerne pas le sujet de cet article. Les en-têtes Cache-Control et ETag restent actifs et importants. L’absence d’une « version en cache » dans Google ne révèle rien sur la qualité de votre configuration HTTP.

Actions recommandées

• Mettez longtemps en cache les fichiers statiques : images, CSS, JavaScript et polices.
• Utilisez des noms de fichiers versionnés ou hachés pour pouvoir les remplacer immédiatement.
• Servez les ressources depuis un CDN proche des utilisateurs.
• Empêchez un cache partagé ou obsolète de fournir la mauvaise réponse aux robots ; les onglets Avancé et Anti-patterns détaillent ce risque.

Pour les directives Cache-Control, ETag face à Last-Modified, l’effet des CDN sur le rythme d’exploration et les erreurs qui bloquent les robots, passez à l’onglet Avancé.

En bref — La mise en cache agit sur trois couches utiles au SEO : navigateur, périphérie du CDN et cache de requêtes conditionnelles propre au robot. Ce n’est pas un facteur de classement, mais elle améliore la vitesse — TTFB, LCP et, via le bfcache, les Core Web Vitals des navigations répétées — ainsi que l’efficacité de l’exploration. Googlebot préfère ETag à Last-Modified, lit max-age seulement comme indication de réexploration et précise que “other HTTP caching directives aren’t supported.” (traduction) « les autres directives de cache HTTP ne sont pas prises en charge ». Les CDN peuvent obtenir un rythme d’exploration supérieur une fois leur cache alimenté ; les vrais risques résident dans les lancements à cache froid et les configurations CDN ou WAF qui bloquent les robots.

Les trois couches de cache

Pour le SEO, la mise en cache recouvre trois mécanismes, chacun régi différemment :

1. Cache du navigateur — l’appareil du visiteur conserve des fichiers afin que les consultations répétées évitent le réseau. C’est ce que PageSpeed Insights contrôle avec « Utiliser des règles de cache efficaces pour les éléments statiques ».
2. Cache du CDN ou de périphérie — un réseau de diffusion conserve des copies sur des nœuds répartis dans le monde ; l’article approfondi sur les CDN et le SEO détaille ce mécanisme. Google décrit le CDN comme un intermédiaire entre l’origine et l’utilisateur, dont “historically their biggest focus is caching” (traduction) « l’objectif principal a historiquement été la mise en cache » : le contenu d’une URL est conservé pour éviter au serveur de le fournir à nouveau pendant un certain temps.
3. Cache du robot — Googlebot et Bingbot gardent leur propre indication de modification du contenu grâce aux requêtes conditionnelles. Ce levier agit sur le budget d’exploration ; l’article consacré aux requêtes conditionnelles détaille son fonctionnement.

L’expression « cache du navigateur » englobe plusieurs mécanismes. Le guide MDN de mise en cache HTTP distingue le cache HTTP privé, propre à chaque navigateur, indexé par requête et désormais partitionné par site de premier niveau pour limiter le suivi intersites ; le cache mémoire de la session en cours ; le bfcache décrit plus loin ; et, séparément, le Cache Storage d’un service worker, contrôlé par le JavaScript du site et non directement par Cache-Control. « Vérifier le cache du navigateur » peut donc désigner quatre diagnostics différents.

Effet sur les Core Web Vitals

Récupérer une ressource par le réseau est lent et coûteux. Le cache supprime la latence et le transfert pour tout contenu inchangé. Il améliore ainsi deux mesures liées aux signaux Web essentiels : le TTFB, puisqu’une réponse en cache évite la régénération à l’origine, et le LCP, puisque les images, CSS et polices s’affichent plus tôt.

Les directives Cache-Control importantes

Cache-Control est l’en-tête principal :

• max-age=<seconds> — durée pendant laquelle une copie reste fraîche. Pour des ressources immuables et versionnées, la documentation Lighthouse de Chrome recommande un an ou davantage, par exemple Cache-Control: max-age=31536000.
• no-cache — ne signifie pas « ne pas mettre en cache », mais « conserver, puis revalider auprès du serveur avant réutilisation ». Le flux léger 304 reste possible.
• no-store — interdit réellement de conserver une copie dans un cache HTTP. Il ne constitue pas un mécanisme général de confidentialité : selon RFC 9111, il n’efface pas de façon fiable l’historique du navigateur et ne régit pas le Cache Storage d’un service worker.
• public / private — autorise un cache partagé, tel qu’un CDN, à conserver la réponse ou limite cette conservation au navigateur de l’utilisateur final.
• immutable — évite toute revalidation tant que la réponse reste fraîche. Il ne signifie pas « jamais obsolète » : après expiration de max-age, les règles normales s’appliquent.
• must-revalidate — agit à l’autre extrémité : une fois la réponse obsolète, le cache doit la revalider auprès de l’origine au lieu de servir la copie.
• s-maxage, stale-while-revalidate, stale-if-error — contrôles plus fins, surtout pour les CDN et caches partagés : fraîcheur propre au cache partagé, réutilisation limitée d’une copie périmée pendant une récupération en arrière-plan ou lors d’une erreur d’origine. Leur prise en charge varie selon les navigateurs et les CDN. Googlebot ne respecte aucune de ces directives supplémentaires.

Invalidation par noms de fichiers versionnés

Pour combiner cache agressif et mise à jour immédiate, placez une empreinte du contenu dans le nom du fichier, par exemple style.x234dff.css. Puisque l’URL sert de clé de cache, modifier le fichier change l’URL : les caches récupèrent aussitôt la nouvelle version tandis que l’ancienne reste conservée. Le guide web.dev sur le cache HTTP et l’article d’ingénierie front-end de Bing décrivent ce modèle. Bing intègre l’empreinte du fichier à l’URL afin que “the URL acts as the cache key,” (traduction) « l’URL serve de clé de cache », ce qui préserve la cohérence et autorise de longues durées d’expiration.

Le piège du bfcache : no-store peut dégrader les CWV

Le cache de navigation arrière/avant, ou bfcache, restaure instantanément une page lorsque l’utilisateur revient en arrière. Cette restauration évite entièrement la mesure de LCP, CLS et INP, ce qui favorise les données terrain CrUX. Le guide Google du bfcache indique toutefois que Cache-Control: no-store sur le document de page a historiquement empêché les navigateurs de le conserver dans le bfcache. Pour garantir la fraîcheur du HTML sans perdre cette admissibilité, préférez no-cache ou max-age=0.

Comment un cache décide si une réponse est assez fraîche

Avant d’utiliser un validateur, le cache vérifie la fraîcheur : l’âge de la réponse dépasse-t-il la durée définie par Cache-Control ou, sans durée explicite, une durée heuristique autorisée ? L’en-tête Age indique depuis combien de temps un cache partagé conserve la réponse ; DevTools ou les journaux CDN permettent ainsi d’estimer la durée restante. Une réponse fraîche est réutilisée immédiatement sans requête. Une réponse obsolète doit être validée avant réutilisation : c’est là qu’interviennent ETag avec If-None-Match, et Last-Modified avec If-Modified-Since.

Utilisation du cache par Googlebot

Dans son article de décembre 2024 Série « Crawling December » : mise en cache HTTP, Google demande explicitement d’activer la mise en cache afin que ses robots évitent de télécharger à nouveau les pages inchangées. Le constat marquant est le recul des récupérations pouvant être servies depuis le cache : environ 0,026 % il y a dix ans, contre 0,017 % aujourd’hui. La source fournit le détail de cette évolution. Les chiffres sont faibles, mais Google souhaite clairement inverser la tendance.

ETag ou Last-Modified : préférence de Google

L’infrastructure d’exploration de Google accepte les deux validateurs standards : ETag, avec If-None-Match, et Last-Modified, avec If-Modified-Since. Google “strongly recommends ETag” (traduction) « recommande vivement ETag », car sa valeur non structurée est moins exposée aux erreurs d’analyse qu’une date. Lorsque les deux en-têtes sont présents, ses robots “use the ETag value” (traduction) « utilisent la valeur ETag », conformément au standard HTTP. Google conseille néanmoins de définir les deux, car d’autres applications telles que les CMS les utilisent. Avec Last-Modified, la date doit respecter le format HTTP, par exemple Fri, 4 Sep 1998 19:15:56 GMT.

Lorsque le validateur conservé par le robot correspond toujours, le serveur renvoie 304 Not Modified sans corps de réponse. C’est précisément l’objectif : selon Google, l’absence de corps évite au serveur le calcul nécessaire à la génération du contenu et économise la bande passante du transfert. L’article sur les requêtes conditionnelles détaille ce mécanisme ; ici, retenez qu’il réduit le coût des deux côtés.

Une nuance souvent ignorée

Googlebot ne suit pas l’ensemble des directives Cache-Control comme le ferait un navigateur ou un CDN. Au-delà d’ETag et de Last-Modified, la présentation officielle des robots précise : “other HTTP caching directives aren’t supported.” (traduction) « les autres directives de cache HTTP ne sont pas prises en charge ». Seule exception partielle : Google indique que max-age peut facultativement aider les robots à déterminer le moment de la réexploration. Il s’agit d’une indication, pas d’un verrou. no-cache, s-maxage, stale-while-revalidate et les directives proches continuent de régir le navigateur et le CDN, mais ne modifient pas le cache de Googlebot. Google recommande de forcer une actualisation lors des changements importants ; la seule modification de l’année du copyright dans le pied de page n’en est pas une.

CDN et exploration

Un CDN n’apporte pas uniquement de la vitesse. L’infrastructure de Google est conçue pour autoriser un rythme d’exploration supérieur sur les sites servis par un CDN, détecté à partir de l’adresse IP qui sert les URL ; Google suppose que l’origine adossée à un CDN supporte davantage de requêtes simultanées.

Il faut cependant anticiper le cache froid. Au premier accès à une URL, le cache du CDN est « froid » : personne ne l’a encore demandée et l’origine doit la servir au moins une fois pour alimenter le cache. Google avertit qu’un lancement simultané de nombreuses URL pèse réellement sur le budget d’exploration, avec un rythme élevé pendant quelques jours. Lors d’un lancement important ou d’une migration, prévoyez que l’origine absorbe la charge complète de chaque URL avant que le CDN ne prenne le relais.

Une mauvaise configuration du CDN menace l’exploration

Les problèmes les plus dangereux ne sont pas des durées trop lentes, mais les règles CDN et WAF qui bloquent les robots. Google recommande, pour un blocage temporaire, d’envoyer un code 503 ou 429. Un délai d’attente réseau est au contraire traité comme une erreur définitive, susceptible de faire retirer les URL de l’index. Plus discret, le blocage souple prend la forme d’un interstitiel de vérification : le robot ne voit que la page de défi. Google recommande vivement de renvoyer un code 503 aux clients automatisés. Pour vérifier facilement le fonctionnement, utilisez l’inspection d’URL de Search Console : si l’image rendue montre un défi anti-robot ou une page vide, contactez votre fournisseur CDN.

J’apprécie le déplacement des redirections vers le CDN. Dans le podcast Marketing Speak, je l’ai décrit ainsi : “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (traduction) « L’une de mes techniques préférées, encore trop peu utilisée, consiste à déporter les redirections au niveau du CDN. » (Accéder à la citation)

Pièges qui nuisent à l’exploration et à l’indexation

De nombreux articles omettent ce point : un cache n’accélère pas seulement les réponses. Une mauvaise copie peut fournir les mauvais octets au robot et compromettre l’exploration ou l’indexation.

Cas réel : un cache partagé sert un robots.txt bloquant. Une situation de blocage intermittent de Googlebot provenait d’un cache CDN partagé entre un environnement de test et le site actif. Dans Indexed, though blocked by robots.txt, j’écrivais : “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (traduction) « Une cause possible tient au partage d’un même cache entre la préproduction et le site actif ; lorsque la copie de test prévaut, robots.txt risque alors de contenir une règle interdisant l’exploration. » La correction consistait à séparer les caches ou à exclure les fichiers .txt du cache de test. La mauvaise configuration a directement provoqué un échec d’exploration.

Autres pièges de la même famille :

• Copie CDN obsolète servie aux robots. Si le nœud périphérique conserve une ancienne version longtemps après publication, les robots continuent de la voir. Purgez à la publication ou adaptez la durée à la fréquence réelle des changements.
• Fragmentation par Vary ou User-Agent. La clé d’un cache partagé est généralement l’URL ; Vary y ajoute des en-têtes de requête tels que User-Agent ou Accept-Language afin de séparer les variantes. Omettre une dimension réellement variable peut servir à un demandeur la réponse d’un autre, par exemple mobile contre ordinateur ou robot contre humain. Ajouter trop d’en-têtes produit tant de clés presque identiques que le taux de succès chute. Les navigateurs modernes partitionnent aussi leur propre cache par site de premier niveau pour la confidentialité : une ressource mise en cache lorsqu’elle est intégrée à un site n’est généralement pas réutilisée sur un autre. Ce mécanisme diffère de Vary.

Ma règle générale sur la durée vient du travail sur le LCP. Dans mon guide Ahrefs, je l’écrivais ainsi : “Your cache time should be as long as you are comfortable with” (traduction) « La durée du cache devrait être aussi longue que vous le jugez acceptable » (accéder à la source), et “An ideal setup is to cache for a really long period of time but purge the cache when you make a change to a page.” (traduction) « La configuration idéale consiste à conserver longtemps les réponses, puis à purger le cache lors d’une modification de page ». Cache long, purge immédiate : cette combinaison préserve vitesse et fraîcheur.

La mise en cache est-elle un facteur de classement ?

Non, pas directement. Aucun signal de classement ne récompense la présence d’ETag ou une bonne règle Cache-Control. Le cache améliore plutôt deux éléments qui comptent pour la visibilité : la vitesse et les Core Web Vitals, qui participent à l’expérience sur la page, ainsi que l’efficacité d’exploration, qui détermine la rapidité de découverte et d’actualisation du contenu. Configurez-le pour rendre le site rapide et facile à explorer, pas pour obtenir un gain direct de positions.

Résumé IA

Synthèse de la version avancée :

• Trois couches utiles au SEO : cache du navigateur, cache du CDN ou de périphérie et cache de requêtes conditionnelles propre au robot. Chacune obéit à des règles légèrement différentes.
• Aucun facteur de classement direct, mais deux bénéfices importants : vitesse — TTFB, LCP et mesures des navigations répétées via le bfcache — et efficacité de l’exploration.
• Principes de Cache-Control : max-age définit la fraîcheur, avec un an ou davantage pour les ressources immuables et versionnées ; no-cache signifie « conserver puis revalider » ; no-store interdit le stockage ; public/private régissent les caches partagés.
• Invalidation : intégrez une empreinte du contenu au nom du fichier afin de mettre longtemps en cache tout en publiant immédiatement une nouvelle URL. Google et Bing utilisent ce modèle.
• Piège du bfcache : Cache-Control: no-store sur le document HTML peut rendre une page inadmissible au cache arrière/avant et dégrader discrètement les mesures CrUX. Préférez no-cache ou max-age=0.
• Googlebot respecte ETag et Last-Modified seulement, préfère ETag et lit max-age comme indication de réexploration. Google précise que “other HTTP caching directives aren’t supported.” (traduction) « les autres directives de cache HTTP ne sont pas prises en charge ». Un validateur concordant produit 304 Not Modified sans corps et économise calcul et bande passante.
• Les CDN permettent un rythme d’exploration supérieur, une fois le cache alimenté. Un lancement à cache froid atteint encore l’origine une fois par URL ; anticipez-le pour les grands lancements et migrations.
• Le plus grand risque n’est pas une durée lente, mais une mauvaise configuration CDN ou WAF qui bloque les robots — renvoyez 503/429 lors d’un blocage temporaire — ou un cache partagé et obsolète qui sert le mauvais contenu, tel qu’un robots.txt bloquant.

Documentation officielle

Documentation de source principale des moteurs de recherche et de leurs équipes techniques.

Google

• Série « Crawling December » : mise en cache HTTP — article de Gary Illyes de décembre 2024 sur ETag et Last-Modified, le mécanisme 304, le recul des récupérations pouvant être mises en cache et l’indication de réexploration max-age.
• Présentation des robots Google — section HTTP Caching — référence actuelle sur la priorité d’ETag et l’absence de prise en charge des autres directives.
• Série « Crawling December » : CDN et exploration — explications de Splitt et Illyes sur le cache CDN, le rythme d’exploration supérieur, les lancements à cache froid et les blocages durs ou souples.
• Utiliser des règles de cache efficaces pour les éléments statiques — audit Lighthouse/PageSpeed et recommandation d’un an ou davantage pour les ressources immuables.
• Éviter les requêtes réseau inutiles avec le cache HTTP — référence des directives et modèle d’invalidation par nom de fichier haché.
• Cache arrière/avant — bfcache — raison pour laquelle no-store sur le document HTML peut supprimer l’admissibilité.
• Index de la série Crawling December — série 2024 complète sur Googlebot, le cache HTTP, la navigation à facettes et les CDN.

Bing / Microsoft

• Performances front-end rapides pour Microsoft Bing — empreinte du contenu dans les URL pour la cohérence du cache et longues expirations, ainsi que rôle du CDN dans la livraison des ressources statiques.
• Série bingbot : maximiser l’efficacité de l’exploration — logique de fraîcheur qui réduit l’exploration lorsque le contenu n’a pas changé.
• Consignes Bing pour les webmasters — point d’entrée des recommandations Bing sur les CDN et les performances.

Citations de la source

Déclarations publiques de Google et extraits de mes propres articles. Chaque lien profond mène au passage cité.

Google — série « Crawling December » sur le cache HTTP

• “While Google’s crawling infrastructure supports heuristic caching mechanisms, in fact always had, the number of requests that can be returned from local caches has decreased: 10 years ago about 0.026% of the total fetches were cacheable, which is already not that impressive; today that number is 0.017%.” (traduction) « Bien que l’infrastructure d’exploration de Google prenne en charge depuis toujours des mécanismes heuristiques, la part des requêtes servies depuis les caches locaux a diminué : environ 0,026 % il y a dix ans, contre 0,017 % aujourd’hui. » Accéder à la citation
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value). And, if you have the option, set them both: the internet will thank you. Maybe.” (traduction) « Nous recommandons vivement ETag, moins exposé aux erreurs puisque sa valeur n’est pas structurée contrairement à Last-Modified. Si possible, définissez les deux : Internet vous en remerciera. Peut-être. » Accéder à la citation
• “Our recommendation is that you require a cache refresh on significant changes to your content; if you only updated the copyright date at the bottom of your page, that’s probably not significant.” (traduction) « Nous recommandons d’imposer une actualisation du cache lors de changements importants du contenu ; modifier seulement la date de copyright au bas de la page n’est probablement pas important. » Accéder à la citation

Google — présentation des robots, section HTTP Caching

• “If both ETag and Last-Modified response header fields are present in the HTTP response, Google’s crawlers use the ETag value as required by the HTTP standard.” (traduction) « Si les en-têtes ETag et Last-Modified sont tous deux présents dans la réponse HTTP, les robots de Google utilisent la valeur ETag comme l’exige le standard HTTP. » Accéder à la citation
• “Other HTTP caching directives aren’t supported.” (traduction) « Les autres directives de cache HTTP ne sont pas prises en charge. » Accéder à la citation

Google — série « Crawling December » sur les CDN et l’exploration

• “Historically, CDNs’ biggest focus is caching, meaning that once a user requested a URL from your site, CDNs will store the contents of that URL in their caches for a time so your server doesn’t have to serve that file again for a while.” (traduction) « Historiquement, la priorité des CDN est la mise en cache : après la demande d’une URL, ils en conservent le contenu pendant un certain temps afin que le serveur n’ait pas à le fournir de nouveau. » Accéder à la citation

Patrick Stox — mise en cache et CDN

• “Your cache time should be as long as you are comfortable with.” (traduction) « La durée du cache devrait être aussi longue que vous le jugez acceptable. » — extrait de mon guide Ahrefs sur le Largest Contentful Paint. Accéder à la citation
• “One possible cause would be a shared cache between a test environment and a live environment. When the cache from the test environment is active, the robots.txt file may include a blocking directive.” (traduction) « Une cause possible serait un cache partagé entre l’environnement de test et l’environnement actif. Lorsque la copie de test est utilisée, robots.txt peut contenir une directive de blocage. » — cas réel d’échec d’exploration. Accéder à la citation
• “One of my personal favorites that I don’t think it’s used enough, it’s actually just off loading your redirects to the CDN level.” (traduction) « L’une de mes techniques préférées, encore trop peu utilisée, consiste à déporter les redirections au niveau du CDN. » — podcast Marketing Speak. Accéder à la citation

Aide-mémoire SEO de la mise en cache

Décodage des directives Cache-Control

Ce que Googlebot respecte réellement

• ✅ ETag + If-None-Match, validateur préféré de Google.
• ✅ Last-Modified + If-Modified-Since, avec une date au format HTTP : Fri, 4 Sep 1998 19:15:56 GMT.
• ✅ max-age, uniquement comme indication de calendrier de réexploration.
• ❌ Tout le reste : “other HTTP caching directives aren’t supported” (traduction) « les autres directives de cache HTTP ne sont pas prises en charge ».

Repères rapides

• Google préfère ETag ; si les deux existent, ETag l’emporte. Définissez tout de même les deux pour les CMS.
• Un validateur concordant produit 304 Not Modified sans corps, ce qui économise calcul et bande passante.
• Chrome et Lighthouse recommandent de conserver les ressources immuables un an ou davantage.
• Les CDN bénéficient d’un rythme d’exploration supérieur, mais seulement lorsque le cache est alimenté.
• Blocage temporaire : renvoyez 503/429, jamais une réponse 200 silencieusement erronée ni un interstitiel anti-robot.
• no-store sur le document HTML peut exclure le bfcache ; préférez no-cache ou max-age=0.
• Le « cache Google » et l’opérateur cache: ont été retirés en 2024 et n’ont aucun lien avec la mise en cache HTTP.

Mythes et erreurs

Pour chacun, voici l’erreur et l’action préférable.

Mythe : « Mettre ma page en cache améliorera mon classement. » Pourquoi c’est faux : la configuration du cache n’est pas un signal de classement. L’équipe Search Relations de Google l’a clairement indiqué. À faire : configurez le cache pour ses vrais bénéfices — vitesse, Core Web Vitals et efficacité d’exploration — qui influencent indirectement la visibilité. N’attendez aucun gain direct.

Mythe : « Le cache de Google et la mise en cache HTTP sont identiques. » Pourquoi c’est faux : l’opérateur cache: et le lecteur de copie enregistrée étaient une fonction de capture destinée aux utilisateurs, entièrement retirée en 2024. Le cache HTTP, Cache-Control et ETag, relève d’une autre infrastructure. À faire : ignorez l’absence de « version en cache ». Évaluez la configuration par les en-têtes ainsi que le comportement de performance et d’exploration.

Mythe : « no-cache signifie ne pas mettre en cache. » Pourquoi c’est faux : no-cache signifie « conserver, puis revalider auprès du serveur avant utilisation ». Le flux 304 reste possible. no-store empêche réellement le stockage. À faire : utilisez no-cache pour combiner fraîcheur et revalidation ; réservez no-store aux réponses sensibles qui ne doivent jamais être conservées.

Mythe : « Une longue durée oblige Google à voir indéfiniment un contenu obsolète. » Pourquoi c’est faux : lors d’une nouvelle exploration, Google valide par ETag ou Last-Modified indépendamment de max-age, qui reste une indication et non un verrou. À faire : conservez longtemps les réponses, mais déclenchez une réelle invalidation — nouvel ETag, nouveau Last-Modified ou nouvelle URL — lors d’un changement important, conformément à la recommandation de Google.

Mythe : « Un CDN résout automatiquement les problèmes de budget d’exploration. » Pourquoi c’est faux : le CDN aide seulement après alimentation du cache ; l’origine sert chaque URL au moins une fois. Une mauvaise configuration peut en plus bloquer les robots. À faire : prévoyez la charge de l’origine pour les grands lancements et migrations, contrôlez les robots avec l’inspection d’URL et renvoyez 503/429 pour les blocages temporaires.

Mythe : « Toute directive Cache-Control modifie l’exploration de Googlebot. » Pourquoi c’est faux : au-delà d’ETag, de Last-Modified et de l’indication facultative max-age, Google indique que “other HTTP caching directives aren’t supported.” (traduction) « les autres directives de cache HTTP ne sont pas prises en charge ». À faire : utilisez stale-while-revalidate, s-maxage, no-cache et les autres directives pour le navigateur et le CDN, mais appuyez-vous sur ETag et Last-Modified pour le cache de Googlebot.

Configurations avant et après

1. Ressource statique sans politique de cache → avertissement PageSpeed supprimé

• Avant : style.css est servi sans Cache-Control ; Lighthouse signale « Utiliser des règles de cache efficaces pour les éléments statiques » et les visites répétées téléchargent de nouveau le fichier.
• Après : renommez-le style.a1b2c3.css et servez Cache-Control: public, max-age=31536000, immutable. Les visites suivantes évitent le téléchargement ; toute modification produit un nouveau nom et invalide immédiatement l’ancienne référence.

2. Document HTML voulu « frais » → bfcache perdu

• Avant : Cache-Control: no-store force la fraîcheur du HTML, mais rend la page inadmissible au bfcache. Les retours arrière mesurent de nouveau LCP, CLS et INP et dégradent les données terrain CrUX.
• Après : utilisez no-cache ou max-age=0. La revalidation maintient la fraîcheur, tandis que la page reste admissible au bfcache et que les navigations répétées se restaurent immédiatement.

3. Cache partagé entre préproduction et production → blocage intermittent de Googlebot

• Avant : les environnements de test et actif partagent un cache CDN. Lorsque la version de test est utilisée, le robots.txt conservé contient une directive de blocage que Googlebot voit par intermittence.
• Après : séparez les caches ou excluez les fichiers .txt du cache de test pour que le robots.txt actif ne provienne jamais de la préproduction. Ce cas réel est décrit dans Indexed, though blocked by robots.txt.

4. Grand lancement derrière un CDN → pic d’exploration inattendu

• Avant : 50 000 nouvelles URL sont publiées simultanément en supposant que le CDN absorbera la charge. Chaque URL manque le cache froid ; l’origine la sert donc au moins une fois et le rythme d’exploration reste élevé plusieurs jours.
• Après : alimentez le cache avant le lancement ou déployez par étapes. Prévoyez que l’origine absorbe toute la charge de chaque URL avant la protection du CDN.

Checklist de configuration du cache HTTP

• Les ressources statiques — images, CSS, JavaScript et polices — ont un long max-age, au moins un an pour les fichiers immuables et versionnés.
• Les noms de fichiers sont versionnés ou hachés afin de permettre une longue conservation et une invalidation immédiate.
• ETag, validateur préféré de Google, est défini ; Last-Modified l’est aussi avec une date HTTP correctement formatée.
• Le serveur renvoie 304 Not Modified sans corps lorsque le validateur correspond toujours.
• Les documents HTML qui doivent rester frais utilisent no-cache/max-age=0, et non no-store, afin de préserver le bfcache.
• Un changement important déclenche une vraie invalidation — nouvel ETag, Last-Modified ou URL — et pas seulement une date de pied de page.
• Un CDN précède l’origine, avec public/s-maxage lorsque les réponses peuvent être partagées.
• Le cache est purgé à la publication pour éviter de servir du contenu obsolète aux robots.
• Préproduction et production ne partagent pas le cache de robots.txt ni des autres fichiers de contrôle.
• Les blocages temporaires renvoient 503/429, et non une page d’erreur silencieuse en 200 ou un interstitiel anti-robot.
• L’inspection d’URL de Search Console affiche la vraie page, ni défi ni page vide, ce qui confirme que le CDN ou WAF ne bloque pas Googlebot.

Les fichiers mis à jour restent obsolètes après déploiement

Symptôme : les visiteurs reçoivent encore un ancien fichier CSS, JavaScript ou image. Cause probable : un cache de longue durée conserve la même URL alors que les octets ont changé. Correction : publiez les ressources immuables sous des noms portant l’empreinte du contenu et mettez à jour la référence HTML ; ne purgez l’ancien objet périphérique que si l’URL a été réutilisée. Confirmez le chargement de la nouvelle URL.

Googlebot télécharge à nouveau des pages inchangées

Symptôme : les journaux montrent des réponses 200 complètes et répétées pour un HTML inchangé. Cause probable : validateurs ETag/Last-Modified absents ou instables. Correction : émettez un validateur stable et fidèle au contenu, puis testez une requête conditionnelle. Une revalidation correcte renvoie 304 lorsque la représentation n’a pas changé.

Des utilisateurs reçoivent la mauvaise variante

Symptôme : le contenu propre à une langue, un appareil, une connexion ou une personnalisation fuit entre utilisateurs. Cause probable : la clé du cache partagé n’inclut pas la dimension variable, ou une réponse privée a été déclarée publique. Correction : corrigez la clé et Vary, marquez correctement les réponses privées, purgez les objets contaminés et retestez plusieurs variantes.

Le cache CDN ne signale jamais de succès

Symptôme : des requêtes répétées pourtant admissibles atteignent toujours l’origine. Cause probable : no-store/private, cookies, clé trop fragmentée ou règle de contournement en périphérie. Correction : examinez les en-têtes de réponse et d’état du cache CDN, modifiez uniquement les règles sûres pour cette classe de contenu, puis demandez deux fois la même clé afin de confirmer un succès.

Classer selon le risque de représentation, pas seulement l’extension

Classez chaque réponse avant d’attribuer une politique :

1. Ressource publique immuable : CSS, JavaScript, polices ou images portant une empreinte peuvent avoir une longue durée, puisque tout changement d’octets produit une nouvelle URL.
2. Document public évolutif : le HTML peut être conservé brièvement ou revalidé avec ETag/Last-Modified ; fraîcheur et correction rapide comptent davantage qu’une durée maximale.
3. Réponse propre à l’utilisateur : le cache partagé est dangereux tant que la personnalisation n’est pas retirée de la représentation ou correctement séparée dans la clé.
4. Réponse sensible : appliquez la politique stricte exigée par les données et acceptez le coût de performance plutôt que d’exposer le contenu.

La bonne question n’est pas « Combien de temps puis-je mettre ce type en cache ? », mais « Quel serait le problème si cette représentation précise était réutilisée pour ce demandeur après ce changement ? »

Fraîcheur, exactitude, efficacité

Une politique doit satisfaire trois critères : fraîcheur, lorsque les changements apparaissent au moment promis ; exactitude, lorsque le bon demandeur reçoit la bonne variante ; et efficacité, lorsque les octets inchangés ne sont ni régénérés ni transférés inutilement. Un taux de succès élevé n’est pas une réussite s’il sert la mauvaise réponse.

Outils d’inspection du cache HTTP

• Panneau Network des DevTools du navigateur — inspectez Cache-Control, ETag, Last-Modified, Age, Vary et l’origine de la réponse : mémoire, disque ou réseau.
• curl — envoyez des requêtes HEAD et conditionnelles sans ambiguïté liée au cache du navigateur ; comparez le validateur initial avec If-None-Match ou If-Modified-Since.
• PageSpeed Insights / Lighthouse — trouvez les ressources statiques dont les règles sont inefficaces ; l’article renvoie aux consignes officielles de Lighthouse.
• Analyses et journaux du CDN — inspectez succès, échec, contournement, clés, requêtes à l’origine et purges sur la couche qui sert réellement la réponse.
• Journaux du serveur — vérifiez que Googlebot reçoit des revalidations 304 plutôt que des corps complets pour les pages inchangées.

Prouver qu’une modification fonctionne

Test de requête conditionnelle

Procédure de vérification : récupérez la réponse, relevez son ETag, puis interrogez de nouveau la ressource avec If-None-Match. Résultat attendu : une représentation inchangée renvoie 304 sans aucun corps. Diagnostic en cas d’échec : le validateur est absent, instable ou ignoré. Période d’observation : résultat immédiat. Condition d’annulation : une ressource modifiée reçoit à tort 304, ou le validateur est identique pour plusieurs variantes.

Test de ressource versionnée

Procédure de vérification : publiez les octets modifiés sous une nouvelle URL portant leur empreinte, puis rechargez une page qui la référence. Résultat attendu : la nouvelle adresse fournit la ressource actualisée tandis que l’ancienne peut rester conservée. Diagnostic en cas d’échec : le HTML pointe encore vers l’ancien fichier ou la construction n’a pas changé l’empreinte. Période d’observation : immédiatement après la propagation dans le HTML et le CDN. Condition d’annulation : styles cassés ou erreurs de script liés à la nouvelle ressource.

Test des variantes dans un cache partagé

Procédure de vérification : demandez chaque variante significative par le CDN, répétez chaque requête et comparez le corps, la clé ou l’état du cache ainsi que Vary. Résultat attendu : chaque demandeur reçoit la représentation qui lui correspond et seules les variantes sûres sont réutilisées. Diagnostic en cas d’échec : une dimension manque dans la clé ou une réponse privée est partagée. Période d’observation : contrôle immédiat, puis examen des journaux de production. Condition d’annulation : un utilisateur reçoit la réponse personnalisée ou linguistique destinée à quelqu’un d’autre.

Testez vos connaissances : mise en cache pour le SEO

Cinq questions rapides sur le cache HTTP, les CDN et l’exploration. Choisissez une réponse, puis vérifiez-la.

Journal des modifications