Requêtes conditionnelles : ETag, If-Modified-Since et 304 Not Modified

En bref — Une requête conditionnelle permet à Googlebot de demander au serveur « cette page a-t-elle changé depuis ma dernière visite ? » avant de la télécharger de nouveau. Si la réponse est non, le serveur renvoie un bref statut 304 Not Modified sans corps, et le robot réutilise sa copie. Les deux parties économisent du travail, surtout sur les grands sites, mais cela n’améliore pas le classement.

Qu’est-ce qu’une requête conditionnelle ?

Habituellement, Googlebot télécharge toute la page. Avec une requête conditionnelle, le robot demande au serveur de ne la lui envoyer que si elle diffère réellement de la version consultée précédemment.

Il joint pour cela une information mémorisée lors de l’exploration précédente :

• Une date — « Lors de ma dernière visite, vous indiquiez telle date de modification. Existe-t-il une version plus récente ? »
• Une empreinte — « Vous aviez attribué à cette page un identifiant, ou ETag. Est-il toujours identique ? »

Si rien n’a changé, le serveur répond 304 Not Modified. Aucun corps de page n’accompagne cette réponse : elle signifie simplement « identique à la version précédente ». Googlebot réutilise alors la copie déjà enregistrée au lieu de tout télécharger.

Si la page a changé, le serveur renvoie normalement la page complète avec un statut 200 OK, et le robot récupère la nouvelle version.

Pourquoi est-ce utile ?

Imaginez une immense boutique en ligne comptant un million de fiches produit rarement modifiées. Sans requêtes conditionnelles, Googlebot les retélécharge à chaque passage, gaspillant bande passante et ressources serveur pour des pages identiques à celles de la semaine précédente. Avec ces requêtes, la majorité reçoit une minuscule réponse « aucun changement » et le robot peut consacrer ses ressources aux pages nouvelles ou modifiées.

Le bénéfice est donc l’efficacité. Il relève du budget d’exploration, c’est-à-dire du volume d’exploration qu’un moteur accepte d’effectuer sur votre site.

La réserve à connaître

Deux précisions avant de vous enthousiasmer :

1. Cela concerne surtout les grands sites. Sur un petit site, le gain est faible et justifie rarement la configuration. Comme je l’ai déjà écrit, l’occasion de mise en cache offerte par un 304 est “not that crucial.” (traduction) « pas si déterminante ».
2. Cela n’améliore pas le classement. Une exploration plus efficace ne fait pas monter dans les résultats ; elle aide seulement les grands sites à faire explorer un peu plus vite leurs pages nouvelles ou modifiées.

Vous voulez connaître les en-têtes exacts, les formats réellement pris en charge par Google, les erreurs de configuration courantes et la différence avec le débit, la fréquence et le budget d’exploration ? Passez à l’onglet Avancé.

En bref — Les requêtes conditionnelles permettent à Googlebot de valider une copie en cache plutôt que de la retélécharger. Il envoie If-Modified-Since, comparé à Last-Modified, et/ou If-None-Match, comparé à ETag. Si rien n’a changé, le serveur renvoie 304 Not Modified sans corps et le robot réutilise sa copie — environ 1 Ko contre plus de 100 Ko pour une page complète. ETag prévaut lorsque les deux sont présents. Google le recommande, car il évite les problèmes de format de date, tout en conseillant de définir les deux. Google n’envoie pas ces en-têtes à chaque exploration : cela dépend de l’usage, et AdsBot est plus susceptible de le faire. Un serveur peut même renvoyer préventivement un 304 sans en-tête conditionnel. Un 304 ne fige pas les signaux d’indexation. Trois erreurs annulent le bénéfice : toujours répondre 200, produire des ETag volatils — horodatage, jeton par requête, variation entre nœuds — ou utiliser un Last-Modified qui ne reflète pas les changements réels. C’est un levier d’efficacité pour les grands sites, pas un facteur de classement, et il se distingue du débit, de la fréquence et du budget d’exploration.

Le mécanisme précis

Le débit d’exploration indique à quelle vitesse Googlebot récupère les pages, et la fréquence à quel rythme il revient. Les requêtes conditionnelles déterminent à quel coût chaque nouvelle visite peut recevoir une réponse. Cette validation entre robot et serveur repose sur deux paires d’en-têtes HTTP :

Déroulement étape par étape :

1. À la première exploration, le serveur renvoie la page avec 200 OK, une date Last-Modified et/ou une empreinte ETag.
2. Lors d’une visite ultérieure, Googlebot peut renvoyer If-Modified-Since, avec la dernière date observée, et/ou If-None-Match, avec l’ETag.
3. Le serveur les vérifie. Si rien de pertinent n’a changé, il répond 304 Not Modified sans corps, avec seulement le statut et les en-têtes.
4. Googlebot réutilise la version précédente. Si le contenu a changé, le serveur renvoie 200 OK avec le corps complet.

Google décrit presque mot pour mot cet échange : “Google’s crawlers that support caching will send the ETag value returned for a previous crawl of that URL in the If-None-Match header. If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (traduction) « Les robots Google qui prennent en charge le cache renvoient dans If-None-Match la valeur ETag reçue lors d’une exploration précédente. Si elle correspond à la valeur actuelle du serveur, celui-ci doit répondre HTTP 304, sans corps. »

ETag ou Last-Modified — et pourquoi Google préfère ETag

Les deux validateurs sont pris en charge. La documentation de Google l’indique clairement : “Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (traduction) « L’infrastructure d’exploration de Google prend en charge la mise en cache HTTP heuristique définie par le standard, au moyen des paires ETag/If-None-Match et Last-Modified/If-Modified-Since. »

Lorsque les deux sont présents, ETag prévaut : “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 ETag et Last-Modified figurent tous deux dans la réponse HTTP, les robots Google utilisent ETag, conformément au standard HTTP. » Ce n’est pas une particularité de Google, mais la règle de priorité du standard HTTP. Mon entrée du glossaire Ahrefs sur 304 Not Modified décrit la même règle : lorsque If-None-Match et If-Modified-Since sont employés, If-None-Match a priorité.

Pourquoi préférer ETag ? Cette chaîne opaque représente une empreinte du contenu et évite les pièges d’analyse de date de Last-Modified. Google recommande : “For Google’s crawlers specifically, we recommend using ETag instead of the Last-Modified header to indicate caching preference as ETag doesn’t have date formatting issues.” (traduction) « Pour les robots Google, nous recommandons ETag plutôt que Last-Modified pour indiquer la préférence de cache, car ETag ne présente pas de problème de format de date. » Si vous utilisez Last-Modified, la date doit suivre le standard HTTP (Weekday, DD Mon YYYY HH:MM:SS Timezone), sinon Google risque de ne pas la comprendre. Dans la pratique, Google conseille néanmoins de définir les deux lorsque c’est possible.

Un signal complémentaire existe : Cache-Control: max-age. Google ne l’exige pas, mais vous pouvez lui donner le nombre de secondes pendant lesquelles le contenu devrait rester inchangé afin d’aider ses robots à décider du prochain passage. L’asymétrie est importante : l’infrastructure d’exploration considère max-age comme un indice, sans appliquer les autres directives Cache-Control exactement comme un navigateur.

Ce que fait un 304 — et ce qu’il ne fait pas

Le gain sur le réseau est spectaculaire. Un 304 ne contient pas de corps et représente, selon l’ordre de grandeur donné par Gary Illyes, environ 1 Ko au lieu de plus de 100 Ko pour une page complète. Il coûte aussi moins à produire — aucun rendu complet ni requête de base de données — et à traiter pour Google — pas de nouvelle analyse, de rendu ni de pipeline complet sur le corps.

Soyez toutefois précis : un 304 ne fige pas les signaux de classement. Les recommandations de Google sur les codes d’état indiquent que le pipeline d’indexation “may recalculate signals for the URL,” (traduction) « peut recalculer les signaux de l’URL », même sans récupérer le corps. Un 304 évite le téléchargement et le retraitement du contenu, pas toutes les évaluations ultérieures. Il n’existe donc aucune astuce consistant à servir des 304 pour verrouiller un classement.

Google ne pose pas toujours la question — et c’est normal

Un détail échappe à beaucoup d’articles : Googlebot n’envoie pas les en-têtes conditionnels à chaque requête. La documentation sur les erreurs d’exploration précise : “Google generally supports the If-Modified-Since and If-None-Match HTTP request headers for crawling. Google’s crawlers don’t send the headers with all crawl attempts; it depends on the use case of the request (for example, AdsBot is more likely to set the If-Modified-Since and If-None-Match HTTP request headers).” (traduction) « Google prend généralement en charge If-Modified-Since et If-None-Match pour l’exploration, mais ses robots ne les envoient pas à chaque tentative ; cela dépend de l’usage, AdsBot étant par exemple plus susceptible de les définir. »

Si vos journaux montrent rarement If-None-Match dans les requêtes de Googlebot, cela ne signifie pas que la configuration est cassée. Google ne le demandait peut-être simplement pas lors de cette visite. Il précise aussi que chaque robot et système de récupération peut ou non utiliser le cache selon le produit servi.

À l’inverse, une technique peu employée consiste à renvoyer 304 sans avoir reçu d’en-tête conditionnel. Google indique : “Independently of the request headers, you can send a 304 (Not Modified) HTTP status code and no response body for any Googlebot request if the content hasn’t changed since Googlebot last visited the URL. This will save your server processing time and resources, which may indirectly improve crawl efficiency.” (traduction) « Indépendamment des en-têtes de requête, vous pouvez répondre 304 sans corps à toute requête Googlebot si le contenu n’a pas changé depuis sa dernière visite. Cela économise du temps et des ressources serveur et peut indirectement améliorer l’efficacité d’exploration. » Cette optimisation avancée de CDN ou de périphérie devient dangereuse si elle est fausse : servir 304 pour un contenu modifié revient à mentir avec vos validateurs. Traitez-la comme une optimisation de bord, pas comme un raccourci pour simuler la fraîcheur.

Pourquoi cela compte pour le budget d’exploration

Le gain se cumule surtout sur le profil déjà visé par les conseils de Google : grands sites comportant beaucoup d’URL rarement modifiées — catalogues e-commerce à longue traîne, archives de presse ou d’éditeurs, documentation volumineuse. Une part importante du budget peut y être dépensée à retélécharger des pages strictement identiques. Répondez avec des 304 et libérez ce budget pour les pages nouvelles ou modifiées.

La partie moins réjouissante est que Google réclame une adoption plus large, sans annoncer qu’elle est déjà généralisée. Illyes observe que la part des récupérations Googlebot pouvant être mises en cache a diminué en dix ans, d’environ 0,026 % à 0,017 %, alors même que le Web grandissait. Ce levier reste sous-employé, comme le résume le titre presque suppliant du billet « Crawling December » : “Allow us to cache, pretty please.” (traduction) « Laissez-nous utiliser le cache, s’il vous plaît. » La plupart des sites ne sont tout simplement pas configurés pour cela.

Erreurs courantes qui annulent les requêtes conditionnelles

Définir un validateur ne suffit pas à en bénéficier. Les sites échouent discrètement de quatre manières :

1. Toujours renvoyer 200 avec un corps complet

L’erreur la plus fréquente consiste à ne rien faire : le serveur ne définit aucun validateur ou ne les vérifie jamais. Chaque exploration retélécharge donc la page complète, qu’elle ait changé ou non. Il s’agit souvent d’un CMS ou serveur sans couche de cache. C’est précisément l’état par défaut qu’Illyes encourage à quitter.

2. Des ETag qui changent à chaque requête

Ce cas est plus trompeur car il paraît correct. Si l’ETag dépend d’une donnée volatile — horodatage intégré, jeton par requête ou session, identifiant de requête, artefact contenant l’heure de compilation — chaque réponse reçoit un nouvel ETag alors que le contenu visible est identique. If-None-Match ne correspond jamais et le serveur ne peut jamais répondre 304. Produisez l’ETag à partir d’un hachage du corps réel ou d’un identifiant stable de version du contenu, jamais d’une donnée variant par requête.

3. Une variation entre nœuds de CDN ou de grappe

Variante proche : plusieurs nœuds d’origine génèrent des ETag faibles différents pour un contenu identique. Un CDN ou robot alternant entre les nœuds ne voit jamais de valeur stable et revalide sans obtenir de 304 propre. Générez les ETag de manière déterministe à partir du contenu, et non de l’état de l’instance, ou centralisez leur production dans toute l’infrastructure.

4. Un Last-Modified qui ne reflète pas les vrais changements

Si Last-Modified reçoit « maintenant » à chaque rendu ou change pour une modification mineure, telle que l’année automatique du pied de page, il déclenche des explorations complètes inutiles. S’il est ancien ou manipulé, il réduit la confiance de Google. Le même principe d’honnêteté s’applique à lastmod dans les sitemaps : ne l’utilisez que s’il reflète de manière vérifiable une modification importante. L’article sur la fréquence d’exploration détaille cette logique ; elle vaut aussi pour l’en-tête HTTP Last-Modified.

Le cas limite d’Illyes : quand un 304 pérennise une page cassée

Ce scénario contre-intuitif mérite une section. Illyes explique qu’un 304 peut “backfire spectacularly” (traduction) « se retourner de façon spectaculaire » : un bogue serveur sert une page vide et cassée avec 200 ; le robot considère l’erreur comme temporaire et programme une vérification ; la page toujours cassée répond ensuite correctement 304, donc « inchangée » ; le robot conclut alors que l’erreur constitue le contenu durable et espace ses vérifications. Son déroulé s’achève lorsque le robot apprend que l’erreur est persistante. Il ajoute : “but it’s worth keeping this somewhere deep in your mind because debugging it is an absolute nightmare.” (traduction) « mais cela mérite de rester quelque part au fond de votre esprit, car le diagnostic est un véritable cauchemar. » Cela arrive-t-il ? Oui. Souvent ? Absolument pas. La leçon est de ne pas greffer les requêtes conditionnelles sur une origine instable : elles peuvent pérenniser une erreur de génération.

Comment Bing le gère

La fonctionnalité ne concerne pas seulement Google ; la prise en charge de Bing est même plus ancienne et plus explicite. En 2008, Live Search annonçait les requêtes GET conditionnelles conformes à la RFC 2616 : il “generally will not download the page unless it has changed since the last time it crawled it,” (traduction) « ne télécharge généralement pas la page si elle n’a pas changé depuis sa dernière exploration », en envoyant If-Modified-Since avec la date du dernier téléchargement et, lorsqu’il existe, If-None-Match avec l’ETag. Aujourd’hui, Bing intègre cela à une mesure nommée efficacité d’exploration, définie par Fabrice Canel comme “how often we crawl and discover new and fresh content per page crawled.” (traduction) « la fréquence à laquelle nous explorons et découvrons du contenu nouveau et frais par page explorée ». Les nouvelles visites inutiles de contenu inchangé réduisent directement ce score. Les mêmes validateurs servent donc les deux moteurs ; Bing donne simplement un tableau de bord au concept.

Cela affecte-t-il le classement ?

Non. Appliquez la même rigueur que dans les articles sur le débit et le budget : les requêtes conditionnelles sont un levier d’efficacité d’exploration et de ressources, pas un facteur de classement. Aucune source officielle ne relie ETag, If-Modified-Since ou 304 au classement. Le bénéfice indirect est qu’un grand site souvent mis à jour peut faire explorer et indexer ses nouveautés plus vite, mais une exploration efficace ne constitue pas elle-même un signal.

Comment vérifier le fonctionnement

Les journaux du serveur font foi. Recherchez Googlebot envoyant If-None-Match ou If-Modified-Since, puis le serveur lui répondant 304. Les données réelles sont rares, ce qui rend précieuse l’ étude de journaux de Tame the Bots par Dave Smart. Sur du trafic Googlebot vérifié, seulement environ 1,3 % des requêtes ont obtenu 304, contre une majorité de 200. Les requêtes If-None-Match se regroupaient lorsqu’une URL était redemandée peu après une récupération. La conclusion rejoint les recommandations : peu fréquent sur les petits sites, mais source d’économies importantes à grande échelle. N’attendez pas un taux élevé sur un petit site ; attendez-vous à un effet sur les sites très explorés.

Requêtes conditionnelles, débit, fréquence et budget

Pour distinguer les notions de la famille du budget d’exploration :

• Débit d’exploration — vitesse de récupération par Googlebot, côté offre et limitée par la santé du serveur.
• Fréquence d’exploration — rythme auquel une URL connue est récupérée, selon sa popularité et son ancienneté.
• Budget d’exploration — enveloppe de demande et de capacité : ensemble des URL que Google peut et souhaite explorer.
• Requêtes conditionnelles — coût de réponse à chaque nouvelle visite. Elles ne modifient ni la vitesse ni la fréquence, mais rendent presque gratuite la visite d’une page inchangée et évitent de gaspiller le budget sur un contenu identique.

Résumé par l’IA

Synthèse de la version Avancé :

• Requêtes conditionnelles = « cela a-t-il changé ? » Googlebot envoie If-Modified-Since, comparé à Last-Modified, et/ou If-None-Match, comparé à ETag. Sans changement, le serveur répond 304 Not Modified sans corps et le robot réutilise sa copie.
• ETag prévaut lorsque les deux sont présents. Google recommande ETag, sans difficulté de format de date, mais conseille de définir les deux. Cache-Control: max-age peut compléter l’indice de calendrier de réexploration.
• Un 304 représente environ 1 Ko contre plus de 100 Ko et évite téléchargement et retraitement, sans figer les signaux d’indexation, que Google peut recalculer.
• Google n’envoie pas toujours les en-têtes, selon l’usage ; AdsBot est plus susceptible de le faire. Un serveur peut aussi répondre 304 préventivement sans en-tête conditionnel.
• Trois erreurs annulent le bénéfice : toujours répondre 200 avec un corps ; produire des ETag volatils — horodatages, jetons, variation entre nœuds — ; ou définir un Last-Modified qui ne suit pas les changements réels, selon la même règle d’honnêteté que lastmod.
• Cas limite : un 304 appliqué à une page vide ou cassée peut amener Googlebot à considérer l’erreur comme permanente, selon Illyes.
• Bing accepte les GET conditionnelles conformes aux RFC depuis 2008 et mesure leur « efficacité d’exploration ».
• L’adoption est faible et baisse, d’environ 0,026 % à 0,017 % de récupérations pouvant être mises en cache en dix ans. C’est un levier sous-employé pour les grands sites, et pas un facteur de classement.
• Vérifiez dans les journaux serveur le taux de 304 et la présence d’If-None-Match. Les données de Tame the Bots montrent un usage rare sur les petits sites mais pertinent à grande échelle.

Documentation officielle

Sources primaires sur les requêtes conditionnelles et la mise en cache des robots.

Google

• À savoir sur l’exploration Web de Google — contrat HTTP actuel : ETag/If-None-Match, Last-Modified/If-Modified-Since, priorité d’ETag et indice Cache-Control: max-age. Ce contenu a été déplacé depuis l’ancien chemin /search/docs/..., sans changement de recommandation.
• Crawling December : mise en cache HTTP — billet de Gary Illyes de décembre 2024 à l’origine de la mise à jour documentaire, « Laissez-nous utiliser le cache, s’il vous plaît ».
• Résoudre les erreurs d’exploration dans Google Search — mécanique If-Modified-Since/304, exemple AdsBot et autorisation de répondre 304 sans en-tête conditionnel.
• Codes d’état HTTP, erreurs réseau et DNS — traitement d’un 304 par Google ; les signaux peuvent être recalculés sans effet négatif sur l’indexation.
• Optimiser le budget d’exploration — notion parente et sites réellement concernés.
• Créer et envoyer un sitemap — principe d’honnêteté de lastmod, analogue à celui de Last-Modified.

Bing et Microsoft

• Annonce des améliorations du robot Live Search — annonce de 2008 des GET conditionnelles conformes à la RFC 2616, avec If-Modified-Since, If-None-Match et ETag.
• Série bingbot : maximiser l’efficacité d’exploration — mesure de l’efficacité et coût des nouvelles explorations inutiles.
• Bing Webmaster Tools — contrôle de l’exploration — levier de débit, à distinguer de l’efficacité de chaque visite.

Citations des sources

Déclarations officielles de Google et Bing. Chaque lien profond mène au passage cité.

Google — prise en charge exacte

• “Google’s crawling infrastructure supports heuristic HTTP caching as defined by the HTTP caching standard, specifically through the ETag response- and If-None-Match request header, and the Last-Modified response- and If-Modified-Since request header.” (traduction) « L’infrastructure d’exploration Google prend en charge le cache HTTP heuristique défini par le standard au moyen des paires ETag/If-None-Match et Last-Modified/If-Modified-Since. » — Google, À savoir sur l’exploration Web de Google. Accéder à la citation
• “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 ETag et Last-Modified figurent dans la réponse, les robots Google utilisent ETag conformément au standard HTTP. » Accéder à la citation
• “For Google’s crawlers specifically, we recommend using ETag instead of the Last-Modified header to indicate caching preference as ETag doesn’t have date formatting issues.” (traduction) « Pour les robots Google, nous recommandons ETag plutôt que Last-Modified, car ETag n’a pas de problème de format de date. » Accéder à la citation
• “Google’s crawlers that support caching will send the ETag value returned for a previous crawl of that URL in the If-None-Match header. If the ETag value sent by the crawler matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body.” (traduction) « Les robots Google compatibles avec le cache renvoient dans If-None-Match l’ETag reçu lors d’une exploration précédente. S’il correspond à la valeur actuelle, le serveur doit répondre HTTP 304 sans corps. » Accéder à la citation

Google — envoi des en-têtes et réponse 304 préventive

• “Google generally supports the If-Modified-Since and If-None-Match HTTP request headers for crawling. Google’s crawlers don’t send the headers with all crawl attempts; it depends on the use case of the request (for example, AdsBot is more likely to set the If-Modified-Since and If-None-Match HTTP request headers).” (traduction) « Google prend généralement en charge If-Modified-Since et If-None-Match, sans les envoyer à chaque exploration ; cela dépend de l’usage, AdsBot étant plus susceptible de les définir. » — Google, Résoudre les erreurs d’exploration dans Google Search. Accéder à la citation
• “If our crawlers send the If-Modified-Since header, the header’s value is the date and time the content was last crawled. Based on that value, the server may choose to return a 304 (Not Modified) HTTP status code with no response body, in which case Google will reuse the content version it crawled the last time.” (traduction) « Lorsque nos robots envoient If-Modified-Since, sa valeur correspond à la date et l’heure de la dernière exploration. Le serveur peut répondre 304 sans corps, et Google réutilisera la version précédente. » Accéder à la citation
• “Independently of the request headers, you can send a 304 (Not Modified) HTTP status code and no response body for any Googlebot request if the content hasn’t changed since Googlebot last visited the URL. This will save your server processing time and resources, which may indirectly improve crawl efficiency.” (traduction) « Indépendamment des en-têtes, vous pouvez répondre 304 sans corps à toute requête Googlebot si le contenu n’a pas changé depuis sa dernière visite. Cela économise les ressources serveur et peut indirectement améliorer l’efficacité d’exploration. » Accéder à la citation

Gary Illyes, Google (LinkedIn — risque de pérennisation par 304)

• “HTTP 304 (not modified) is super useful to signal crawlers that the content they’re accessing hasn’t changed since it was last crawled, but it can also backfire spectacularly.” (traduction) « HTTP 304 est très utile pour indiquer aux robots que le contenu n’a pas changé depuis la dernière exploration, mais il peut aussi se retourner de façon spectaculaire. » Lire le billet
• À propos de la fréquence du piège page vide puis 304 : “Does this ever happen? Yes. Often? Absolutely not. But it’s worth keeping this somewhere deep in your mind because debugging it is an absolute nightmare.” (traduction) « Cela arrive-t-il ? Oui. Souvent ? Absolument pas. Mais gardez-le quelque part au fond de l’esprit, car le diagnostic est un cauchemar absolu. » Lire le billet

Bing — Live Search, Fabrice Canel (annonce des GET conditionnelles en 2008)

• “Live Search supports conditional get as defined by RFC 2616 (Section 14.25), and generally will not download the page unless it has changed since the last time it crawled it.” (traduction) « Live Search prend en charge les GET conditionnelles définies par la RFC 2616 et ne télécharge généralement pas la page si elle n’a pas changé depuis sa dernière exploration. » Accéder à la citation

Faut-il mettre en œuvre les requêtes conditionnelles ?

Tous les sites n’en ont pas besoin. Évaluez d’abord si le gain mérite une modification de la configuration serveur.

Procédure : mettre en œuvre correctement les requêtes conditionnelles

Voici une méthode reproductible pour ajouter ou réparer leur prise en charge sur un grand site. Respectez cet ordre : mesurer, mettre en œuvre, vérifier.

1. Confirmez que le problème existe réellement. Extrayez des journaux le trafic Googlebot vérifié. Si la plupart des requêtes vers des URL inchangées répondent 200 avec un corps complet et que peu ou pas d’en-têtes If-None-Match ou If-Modified-Since apparaissent, une amélioration est possible. Si les pages inchangées obtiennent déjà des 304, arrêtez-vous : le gain restant peut être faible.

2. Générez un ETag stable fondé sur le contenu. Calculez l’ETag à partir d’un hachage du corps réel ou d’un identifiant stable de version. Ne le dérivez pas d’un horodatage, d’un jeton par requête ou session, d’un identifiant de requête ni d’une donnée propre à un nœud. Demandez deux fois la même URL inchangée et confirmez que l’ETag est identique, y compris sur tous les nœuds CDN et d’origine.

3. Définissez un Last-Modified honnête. Attribuez à Last-Modified la date et l’heure de la dernière modification importante, pas l’heure du rendu ni une valeur modifiée par la seule année du pied de page. Utilisez le format HTTP (Weekday, DD Mon YYYY HH:MM:SS Timezone). Si possible, définissez à la fois ETag et Last-Modified ; Google donnera la priorité à ETag.

4. Renvoyez 304 correctement. Quand If-None-Match correspond à l’ETag actuel — ou que If-Modified-Since n’est pas antérieur à Last-Modified — et que rien n’a changé, répondez 304 Not Modified sans corps, avec seulement le statut et les en-têtes. La plupart des serveurs et frameworks le font automatiquement ; vérifiez qu’un proxy ou CDN placé devant l’origine ne retire pas ce comportement.

5. Facultatif : ajoutez un indice Cache-Control max-age. Définissez Cache-Control: max-age=<seconds> au nombre de secondes pendant lesquelles le contenu devrait rester inchangé. Il complète le calendrier de réexploration sans le garantir.

6. Vérifiez dans les journaux, puis laissez fonctionner. Consultez de nouveau les journaux après quelques semaines. Les requêtes If-None-Match de Googlebot doivent recevoir 304 sur les pages inchangées et 200 uniquement après un vrai changement. N’attendez pas un taux élevé sur un petit site, mais un effet à grande échelle.

Garde-fou : ne renvoyez jamais 304 pour une page réellement modifiée et n’ajoutez jamais ces requêtes à une origine instable. Un 304 servi sur une page vide ou cassée peut amener Googlebot à considérer l’erreur comme permanente.

Mythes et erreurs à éviter

Confusions récurrentes qui gaspillent des efforts ou cassent discrètement le système :

• « Googlebot envoie toujours If-Modified-Since ou If-None-Match ; leur absence dans mes journaux prouve que le serveur est cassé. » Faux. Google précise qu’il ne les envoie pas à chaque exploration. L’usage compte, et AdsBot est cité comme plus susceptible de le faire. Les données de Tame the Bots montraient moins de 2 % de réponses 304 sur le site étudié.

• « Un 304 empêche Google de réévaluer mes classements ou signaux. » Faux. Le pipeline d’indexation peut toujours recalculer les signaux de l’URL ; seuls le téléchargement et le retraitement du contenu sont évités.

• « Définir un ETag garantit des 304. » Faux si l’ETag est volatil. Une empreinte fondée sur un horodatage, un jeton par requête ou l’état du nœud change à chaque réponse. If-None-Match ne correspond jamais, et le problème est difficile à voir car la configuration paraît correcte.

• « La présence de Last-Modified suffit, n’importe quelle date convient. » Faux. Une date qui ne suit pas les changements réels — « maintenant » à chaque rendu ou variation du pied de page — déclenche des explorations inutiles ou réduit la confiance de Google, comme pour lastmod dans un sitemap.

• « 304 ne peut être qu’une réponse à une requête GET conditionnelle. » Faux. Google autorise un serveur à répondre préventivement 304 sans corps à toute requête Googlebot lorsqu’il sait indépendamment que le contenu n’a pas changé.

• « Les requêtes conditionnelles amélioreront mon classement. » Aucune source officielle ne l’établit. Le bénéfice documenté concerne l’efficacité du serveur et de l’exploration. Il peut accélérer la découverte de nouveautés sur un grand site, mais ne constitue pas un facteur de classement.

• « Cela ne concerne que les très grandes entreprises. » C’est surtout vrai pour l’urgence, car Google vise les grands sites au contenu stable. Le mécanisme et ses erreurs concernent tous les sites ; sur un petit site, la configuration mérite rarement l’effort.

Vérifier les validateurs de cache d’une URL avec curl

Observez les validateurs envoyés par le serveur et vérifiez qu’il répond 304 lorsque vous les lui renvoyez.

1) Afficher les en-têtes de réponse — recherchez ETag et Last-Modified

curl -sI https://example.com/some-page | grep -iE 'etag|last-modified|cache-control'
# ETag: "a1b2c3d4e5"
# Last-Modified: Thu, 22 Jan 2026 01:28:49 GMT
# Cache-Control: max-age=94043

2) Envoyer une requête conditionnelle avec l’ETag — la réponse attendue est 304

curl -sI https://example.com/some-page \
  -H 'If-None-Match: "a1b2c3d4e5"'
# HTTP/2 304        ← correct: server confirms nothing changed, sends no body
# HTTP/2 200        ← if you get this on an unchanged page, your validators aren't working

3) Envoyer une requête conditionnelle avec la date

curl -sI https://example.com/some-page \
  -H 'If-Modified-Since: Thu, 22 Jan 2026 01:28:49 GMT'
# HTTP/2 304

Détecter un ETag volatil

Si la même URL inchangée renvoie un ETag différent lors de deux requêtes successives, l’empreinte est volatile — fondée sur un horodatage ou jeton — et If-None-Match ne correspondra jamais :

# Request twice; the two ETag values should be IDENTICAL for an unchanged page
for i in 1 2; do curl -sI https://example.com/some-page | grep -i '^etag:'; done
# ETag: "a1b2c3d4e5"
# ETag: "a1b2c3d4e5"   ← good (stable)
# ETag: "9f8e7d6c5b"   ← BAD if different: your ETag changes every request

Contrôler les 304 dans les journaux d’accès

Vérifiez l’activité réelle des requêtes conditionnelles de Googlebot. Adaptez la position des champs à votre format ; cet exemple suppose un champ de statut proche du format combined log :

# Count status codes returned to Googlebot
grep -i 'googlebot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
#   4211 200
#     53 304        ← these are the conditional-request wins
#     12 301

# See which URLs are getting 304s
grep -i 'googlebot' access.log | awk '$9==304 {print $7}' | sort | uniq -c | sort -rn | head

Vérifiez que la requête provient réellement de Googlebot par résolution DNS inverse puis directe avant de faire confiance à l’agent utilisateur : les faux Googlebot sont courants.

Vérification rapide dans la console DevTools

Collez ce code dans la console Chrome DevTools pour lire les validateurs reçus par le navigateur sur la page active :

// Reads the ETag / Last-Modified the server sent for THIS page
fetch(location.href, { method: 'HEAD' }).then(r => {
  console.log('ETag:', r.headers.get('etag'));
  console.log('Last-Modified:', r.headers.get('last-modified'));
  console.log('Cache-Control:', r.headers.get('cache-control'));
});

Cadre : validateur → requête → réponse

1. Validateur : la première réponse 200 fournit ETag, Last-Modified ou les deux.
2. Requête : une récupération ultérieure renvoie cette valeur dans If-None-Match ou If-Modified-Since.
3. Réponse : un contenu inchangé reçoit 304 sans corps ; un contenu modifié reçoit 200 avec le nouveau corps et son validateur.
4. Contrôle de stabilité : les validateurs changent avec la représentation, pas parce que la requête atteint un autre serveur ou contient un horodatage.

Aide-mémoire des en-têtes conditionnels

Outils de vérification des validateurs

• Le vérificateur d’en-têtes HTTP affiche ETag, Last-Modified, les en-têtes de cache et leurs changements après chaque redirection.
• Le panneau Network des DevTools du navigateur montre les validateurs initiaux et les en-têtes conditionnels d’une requête répétée.
• curl fournit le test reproductible le plus clair : capturez un validateur, renvoyez-le et confirmez que la réponse inchangée est 304.
• L’analyse des journaux d’accès montre si les requêtes conditionnelles des robots reçoivent réellement des 304 à grande échelle.

Mesures de santé des requêtes conditionnelles

Taux de validations conditionnelles réussies

Mesure : proportion des requêtes conditionnelles admissibles répondant 304. Interprétation : capacité des validateurs à éviter le transfert d’un corps inchangé. Collecte : regroupez dans les journaux les requêtes portant If-None-Match ou If-Modified-Since selon le statut de réponse. Référence réaliste : établissez une base par modèle et rythme de modification ; les pages souvent mises à jour diffèrent naturellement des archives stables. Cadence : mensuelle et après tout changement de cache ou CDN.

Octets évités grâce aux réponses 304

Mesure : estimation des octets de corps non transférés. Interprétation : bénéfice en bande passante plutôt que simple nombre de réponses. Collecte : comparez chaque URL répondant 304 avec la taille de son dernier corps 200 dans les journaux ou un export d’exploration. Référence réaliste : comparez à la période précédente du site ; aucun objectif universel n’est honnête. Cadence : mensuelle.

Instabilité des validateurs

Mesure : URL inchangées dont l’ETag ou Last-Modified varie entre les contrôles. Interprétation : détection d’une variation par requête ou par nœud qui empêche la revalidation. Collecte : répétez des requêtes d’en-têtes identiques sur un échantillon fixe. Référence réaliste : les validateurs restent stables tant que la représentation ne change pas. Cadence : après les déploiements et modifications de CDN ou d’équilibreur de charge.

Ressources utiles

Mes articles liés

• Qu’est-ce que 304 Not Modified ? — glossaire SEO Ahrefs : déroulement complet, priorité de If-None-Match et raison pour laquelle l’occasion 304 est “not that crucial” (traduction) « pas si déterminante » sur les petits sites, mais une “great opportunity” (traduction) « excellente occasion » sur les grands.
• Quand faut-il se préoccuper du budget d’exploration ? — notion parente, demande, capacité et sites concernés avant d’aborder les requêtes conditionnelles.
• Qu’est-ce que Googlebot et comment fonctionne-t-il ? — décisions de Googlebot sur les pages et la vitesse d’exploration, avec le contexte du planificateur.
• Guide du débutant pour le SEO technique — place de l’efficacité d’exploration dans l’ensemble.

Mes conférences

• Fonctionnement de la recherche — présentation SlideShare de l’exploration, du rendu, de l’indexation et du classement, avec les facteurs de demande. Mon avertissement habituel s’applique : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) « Voici ma compréhension des systèmes ; elle ne sera pas complète ni exacte à 100 %. »

Sources du secteur

• Crawling December : mise en cache HTTP — billet de Gary Illyes demandant l’activation du cache et source de la statistique de baisse d’adoption.
• Googlebot utilise-t-il les en-têtes ETag ? — rare étude de journaux réels par Dave Smart, de Tame the Bots ; de nombreux articles concurrents ne font que paraphraser la spécification.
• Google précise le traitement des en-têtes Cache-Control par ses robots — couverture de Barry Schwartz dans Search Engine Land, avec reproduction exacte des principales citations sur ETag et Last-Modified.
• Les recommandations actualisées de Google conseillent les ETag — préférence pour ETag et nuance selon laquelle chaque robot peut ou non utiliser le cache.
• Annonce des améliorations du robot Live Search — annonce Bing de 2008, conforme à la RFC 2616, avec exemple de requête et réponse.
• Série bingbot : maximiser l’efficacité d’exploration — cadrage de Bing où les nouvelles explorations inutiles réduisent directement la mesure.
• MDN : requêtes conditionnelles HTTP — référence neutre de niveau spécification sur les validateurs et le mécanisme 304.

Testez vos connaissances : requêtes conditionnelles

Cinq questions rapides sur ETag, If-Modified-Since et 304 Not Modified. Choisissez une réponse, puis vérifiez-la.

Journal des modifications