Cache HTTP, ETag et 304 : ce que Googlebot en fait (SEO + GEO)

Chaque fois que Googlebot revient sur une page que tu n'as pas touchée depuis trois mois, ton serveur la régénère, la compresse et la renvoie en entier. Google, lui, la télécharge, la parse, et constate qu'elle n'a pas bougé. Le protocole HTTP prévoit une sortie de secours depuis les années 90 : le cache conditionnel, qui permet de répondre 304 Not Modified sans corps de réponse.

Sur le papier, c'est gratuit. En pratique, presque personne ne l'exploite : dans son billet de décembre 2024, Google indique que seulement 0,017 % de ses fetches peuvent être servis depuis un cache, contre 0,026 % il y a dix ans. Voici comment fonctionne ce mécanisme, ce que Google supporte vraiment, comment le vérifier sur ton site et quels pièges éviter.

Le cache HTTP conditionnel en 30 secondes

Le principe tient en deux échanges.

1. Premier passage : le serveur répond 200 avec la page et un identifiant de version dans l'en-tête, par exemple ETag: "v42-a1b2c3", ou une date dans Last-Modified.
2. Passages suivants : le client renvoie cet identifiant dans If-None-Match (pour l'ETag) ou If-Modified-Since (pour la date). Si rien n'a changé, le serveur répond 304 Not Modified, avec les en-têtes mais sans corps.

Un 304 n'est ni une erreur ni une redirection. C'est le serveur qui dit : « ta copie est bonne, garde-la ».

Ce que Google supporte exactement

La documentation des crawlers Google est assez précise, et plus restrictive qu'on ne le croit :

• Google supporte le cache HTTP heuristique via ETag / If-None-Match et Last-Modified / If-Modified-Since.
• Si les deux en-têtes sont présents, Google utilise la valeur de l'ETag, comme l'exige le standard HTTP.
• Last-Modified doit respecter le format de date HTTP, par exemple Fri, 4 Sep 1998 19:15:56 GMT.
• Cache-Control: max-age est optionnel, mais aide le crawler à estimer quand revenir.
• Les autres directives de cache ne sont pas supportées. Inutile de compter sur no-cache, s-maxage ou stale-while-revalidate pour influencer Googlebot.
• Le support dépend du crawler : Googlebot gère le cache lors du re-crawl pour la recherche, alors que Storebot-Google ne le fait que dans certains cas.

Retiens surtout ceci : ce cache ne fonctionne que si ton serveur envoie des validateurs fiables. Google ne les invente pas.

Pourquoi ça compte pour ton crawl

Un 304 évite à ton serveur de générer la page et de transférer le corps. Google le formule ainsi : le serveur économise du calcul et de la bande passante, et du côté du crawler le contenu est récupéré depuis son cache interne.

L'effet sur l'indexation reste modeste. Un 304 signale que le contenu est identique au dernier crawl, et c'est tout : ce n'est pas un signal de classement. Le gain est ailleurs :

• Moins de charge serveur sur les pages dynamiques (rendu SSR, requêtes base de données).
• Moins de bande passante, donc des coûts en baisse si tu paies au transfert.
• Une meilleure marge pour le crawl sur les gros sites, sujet que nous détaillons dans notre guide du crawl budget.

Sur un site de 200 pages, le gain est négligeable. Il devient réel à partir de quelques milliers d'URL, ou dès que ton rendu est coûteux.

ETag ou Last-Modified : lequel choisir

Google recommande l'ETag, parce qu'il évite les problèmes de format de date. C'est aussi ton meilleur choix quand la date de modification n'est pas fiable (contenu assemblé depuis plusieurs sources, déploiements qui réécrivent tous les fichiers).

Règle simple :

• Ton contenu vient de fichiers statiques ou d'un CDN : laisse l'ETag automatique, il fait très bien le travail.
• Ton contenu vient d'une base de données : dérive l'ETag d'un hash du contenu rendu, ou d'un numéro de version de l'entité (par exemple id + updated_at).
• Tu envoies les deux : pas de souci, Google utilisera l'ETag. Assure-toi seulement que les deux changent au même moment.

Ne mets jamais la date du jour dans Last-Modified pour « faire frais ». Un validateur qui change à chaque requête ne déclenche jamais de 304, et il envoie un faux signal de fraîcheur. Pour la vraie fraîcheur éditoriale, on renvoie plutôt vers notre article sur la mise à jour de contenu.

Diagnostiquer ton site en trois commandes

Pas besoin d'outil payant. Le test tient dans un terminal.

1. Vois quels validateurs ton serveur envoie :

curl -sI https://ton-site.fr/blog/un-article | grep -iE "etag|last-modified|cache-control|HTTP/"

2. Rejoue la requête comme le ferait un crawler, en renvoyant l'ETag reçu :

curl -sI -H 'If-None-Match: "valeur-recue-a-letape-1"' https://ton-site.fr/blog/un-article | head -1

Tu dois obtenir HTTP/2 304. Si tu obtiens 200, ton serveur ignore la requête conditionnelle.

3. Vérifie la stabilité : lance la commande 1 deux fois de suite. Si l'ETag est différent d'une requête à l'autre sans que le contenu ait changé, tu as un problème (voir la section suivante).

Côté observation réelle, ouvre le rapport Statistiques sur l'exploration de Search Console : la répartition par code de réponse montre la part de « Non modifié (304) » parmi les requêtes de Googlebot. Si elle est proche de zéro sur un site dont la majorité des pages ne bouge pas, tu laisses du gain sur la table.

Les cinq pièges classiques

1. ETag différent selon le serveur. Derrière un load balancer, deux machines qui calculent l'ETag à partir de l'inode ou de la date de fichier renvoient deux valeurs pour le même contenu. Le crawler ne verra jamais de correspondance.
2. ETag qui change à chaque déploiement. Un ETag basé sur la date de build invalide tout le cache à chaque mise en production, même pour les pages inchangées.
3. Validateur qui bouge à chaque requête. Un timestamp ou un jeton de session dans le hash, et le 304 ne se déclenche jamais.
4. Le 304 menteur. Si ton serveur ou ton CDN répond 304 alors que le contenu a changé, le crawler garde l'ancienne version. C'est le seul piège vraiment dangereux : tes mises à jour restent invisibles.
5. Tout désactiver par peur. Couper les ETag partout règle le risque précédent, mais garantit que chaque recrawl coûte une réponse complète.

Configurer : Nginx, Apache, Next.js et CDN

Les valeurs par défaut sont souvent correctes. Vérifie avant de modifier.

Nginx génère un ETag pour les fichiers statiques par défaut. Tu peux le forcer :

etag on;

Apache calcule l'ETag selon FileETag. Sur une ferme de serveurs, retire l'inode pour éviter la divergence entre machines :

FileETag MTime Size

Next.js génère des ETag pour les pages par défaut, via l'option generateEtags de next.config.js. Ne la passe à false que si tu sais pourquoi.

CDN : la plupart des CDN revalident auprès de ton origine avec les mêmes en-têtes conditionnels. Teste le comportement de bout en bout avec les commandes ci-dessus, en ciblant l'URL publique et non l'origine.

Ajoute enfin un Cache-Control: max-age raisonnable sur les contenus qui changent rarement, pour aider Google à espacer ses passages. Pour un article de blog, quelques heures à quelques jours suffisent : reste prudent sur les pages qui changent souvent.

Mini-cas illustratif

Cet exemple est un calcul théorique, pas une mesure sur un client. Imaginons un site de 3 000 pages HTML de 80 Ko en moyenne, recrawlées 10 fois par mois par Googlebot, dont 90 % n'ont pas changé entre deux passages.

• Sans cache conditionnel : 3 000 × 10 × 80 Ko = 2,4 Go transférés par mois.
• Avec un 304 sur les pages inchangées (environ 0,5 Ko d'en-têtes) : 10 % de réponses complètes (240 Mo) plus 90 % de réponses 304 (environ 13 Mo), soit environ 253 Mo.

Le calcul montre l'ordre de grandeur : une réduction de près de 90 % du transfert pour ce trafic. Le gain réel dépend de ta fréquence de crawl et de la part de pages stables, que tu peux lire dans tes logs.

Et pour le GEO ?

Aucune documentation publique ne garantit que GPTBot, ClaudeBot ou PerplexityBot envoient des requêtes conditionnelles. Ne pars donc pas du principe qu'ils le font.

Ce que tu peux faire, c'est le mesurer. Dans tes logs serveur, compte les réponses 304 par user-agent : si un bot IA n'en génère jamais, il retélécharge tout à chaque passage, et tes validateurs ne lui servent à rien. Notre article sur l'analyse des logs serveur détaille la méthode. De toute façon, un serveur qui répond vite et sans surcoût aux bots reste plus facile à crawler, y compris pour les moteurs IA.

Checklist avant de fermer l'onglet

1. curl -sI renvoie un ETag ou un Last-Modified sur tes pages HTML.
2. La requête conditionnelle rejouée renvoie 304.
3. L'ETag est identique d'une requête à l'autre sur un contenu inchangé.
4. Deux serveurs de ta ferme renvoient le même ETag pour la même page.
5. Un contenu modifié change bien l'ETag (test après une édition).
6. La part de 304 dans les Statistiques sur l'exploration est cohérente avec la stabilité de ton site.

Pour savoir où en est ton site sur l'ensemble du SEO technique et GEO, obtiens ton score /100 gratuitement, et regarde le rapport complet en PDF pour la liste priorisée des correctifs.

FAQ

Un 304 nuit-il au SEO ?

Non. Google indique que le 304 signale un contenu identique au dernier crawl, sans autre effet sur l'indexation. Le risque est un 304 renvoyé à tort sur un contenu modifié.

Google préfère-t-il ETag ou Last-Modified ?

Google recommande l'ETag et l'utilise en priorité quand les deux en-têtes sont présents. Si tu utilises Last-Modified, respecte le format de date HTTP.

Cache-Control : no-cache empêche-t-il Googlebot de crawler ?

Les autres directives que max-age ne sont pas supportées par les crawlers Google, donc elles n'influencent pas leur comportement. Pour bloquer le crawl ou l'indexation, utilise robots.txt ou une balise robots.

Pourquoi mon serveur renvoie 200 à la requête conditionnelle ?

Cause fréquente : ETag absent ou instable, proxy qui retire l'en-tête, ou validateur qui change à chaque requête. Refais les trois commandes du diagnostic pour isoler le maillon.

Les bots IA utilisent-ils le cache conditionnel ?

Ce n'est pas documenté publiquement. Mesure-le dans tes logs en comptant les réponses 304 par user-agent.

À retenir

• Google supporte ETag / If-None-Match et Last-Modified / If-Modified-Since, et privilégie l'ETag si les deux existent.
• Les autres directives de cache que max-age ne sont pas prises en compte par les crawlers Google.
• Seulement 0,017 % des fetches de Google sont cacheables aujourd'hui : la marge de progression est énorme.
• Teste en trois commandes curl : validateurs présents, 304 sur requête conditionnelle, ETag stable.
• Le seul vrai danger est le 304 renvoyé sur un contenu qui a changé.
• Pour les bots IA, ne suppose rien : compte les 304 dans tes logs.