304 Non modifié

TL;DR — Une réponse 304 Not Modified est la manière dont le serveur indique : « vous l’avez déjà ; votre copie est toujours valide, inutile de la télécharger à nouveau ». Ce n’est pas une erreur et, bien qu’elle appartienne à la famille des « redirections » 3xx, elle n’envoie personne vers une nouvelle URL. Elle ne survient que lorsque le client (navigateur ou robot d’exploration) envoie d’abord une requête conditionnelle demandant : « cela a-t-il changé depuis la dernière fois ? ». En SEO, elle ne modifie pas votre classement, mais sur les grands sites elle aide les moteurs à utiliser leurs ressources plus efficacement.

Ce qu’est réellement une 304

Chaque réponse envoyée par votre serveur commence par un code d’état à trois chiffres. 200 OK signifie « voici la page, avec son corps ». Une 304 Not Modified signifie quelque chose de plus précis : le client a envoyé une requête conditionnelle — « donnez-moi cette page, mais seulement si elle a changé » — et le serveur a constaté qu’elle n’avait pas changé. Au lieu du 200 qu’il aurait envoyé, il répond 304, sans aucun corps. C’est la règle réelle : une 304 répond uniquement à une requête conditionnelle GET/HEAD dont la condition est fausse.

A deuxième visite est la manière habituelle dont cela se produit, et c’est une bonne façon de se le représenter : lors de la première consultation, le navigateur ou le robot obtient une réponse 200 normale avec tout le contenu, ainsi que quelques en-têtes servant « d’empreintes ». À la visite suivante, le client présente cette empreinte au serveur et demande : « est-ce toujours pareil ? » Si rien n’a changé, le serveur répond 304 sans aucun corps, et le client réutilise simplement la copie qu’il possède déjà. Mais la « deuxième visite » n’est qu’un exemple : la règle du protocole est que la requête doit être conditionnelle, quelle que soit la façon dont elle est arrivée. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

Pourquoi elle appartient à la famille des « redirections » sans en être une

304 commence par un 3, la classe que HTTP utilise pour les redirections, ce qui prête constamment à confusion. Mais une 304 n’a aucun en-tête Location et n’envoie le client vers aucune autre adresse : personne ne va nulle part. Elle indique simplement au client de revenir à sa propre copie enregistrée. La « famille des redirections » est donc une bizarrerie de numérotation, pas une description de son comportement.

Une 304 pose-t-elle problème ?

Non. Voir des 304 dans l’onglet Réseau du navigateur ou dans un rapport d’exploration indique que la mise en cache fonctionne, exactement comme prévu. De nombreux conseils du type « erreur 304, comment la corriger ? » traitent à tort ce résultat comme un problème. Il s’agit au contraire du comportement correct d’un cache bien configuré.

Une 304 aide-t-elle le SEO ?

Pas directement votre classement. Google possède déjà le contenu depuis sa dernière exploration : une 304 confirme simplement qu’il n’a pas changé, et Google continue donc d’utiliser ce qu’il a enregistré (Search peut toujours recalculer les signaux d’une URL, mais une 304 n’est ni un bonus de classement ni un bonus d’indexation). Là où elle aide réellement, c’est dans l’efficacité des ressources : si un moteur n’a pas à retélécharger des pages inchangées, il économise de la bande passante et du calcul des deux côtés. Google indique que cela peut améliorer indirectement l’efficacité de l’exploration, sans garantir que l’effort économisé sera automatiquement affecté à vos pages nouvelles ou mises à jour. Cet effet compte surtout sur les grands sites comportant beaucoup de pages qui changent rarement.

Vous voulez comprendre les mécanismes réels — ETags, If-None-Match, validateurs forts ou faibles, mise en œuvre et déclarations de Google ? Passez à l’onglet Advanced.

TL;DR — Une 304 est la réponse à une requête conditionnelle GET/HEAD dont la condition est évaluée comme fausse et qui aurait sinon produit une réponse 200 (RFC 9110 §15.4.5). Elle appartient à la classe 3xx, mais n’est pas une redirection : aucun Location, aucune nouvelle URL et, selon la règle normative, aucun corps — « it cannot contain content or trailers » (traduction) « elle ne peut contenir ni contenu ni bandes-annonces ». La condition est portée par If-None-Match (comparé à un ETag) et/ou If-Modified-Since (comparé à Last-Modified) ; si le validateur correspond toujours, le serveur renvoie 304 et le client réutilise son cache. Côté SEO : aucun effet direct sur le classement — Google possède déjà le contenu, même si Search peut recalculer les signaux d’une URL — et une économie de ressources sur les grands sites (Google indique qu’elle peut améliorer indirectement l’efficacité de l’exploration, sans promettre une réaffectation automatique du budget vers d’autres URL). L’infrastructure d’exploration de Google prend en charge les deux validateurs et recommande ETag en priorité, car il évite les problèmes de format de date. Comparez cette réponse aux 301/302/307/308 (qui déplacent l’URL) et à 204 (également sans corps, mais parce qu’il n’y a réellement rien à envoyer).

Ce que signifie 304 dans la spécification

La RFC 9110 (HTTP Semantics) §15.4.5 le définit précisément : “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (traduction) « Le code d’état 304 (Not Modified) indique qu’une requête GET ou HEAD conditionnelle a été reçue et aurait produit une réponse 200 (OK) si la condition n’avait pas été évaluée comme fausse. » C’est le déclencheur normatif : une requête conditionnelle GET/HEAD dont la condition est fausse et qui aurait sinon obtenu 200. En clair, le client demande la page uniquement si elle a changé ; le serveur constate que ce n’est pas le cas et n’envoie donc pas le corps. Une deuxième visite est l’exemple courant qui rend la requête conditionnelle, mais la spécification n’exige aucune visite antérieure : seule la requête conditionnelle compte. Evidence for this claim RFC 9110 defines 304 Not Modified as the response to a conditional GET or HEAD when the selected representation has not changed and says the response cannot contain content. Scope: HTTP semantics for 304 conditional responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.5 — 304 Not Modified

La spécification emploie même le mot « redirecting » dans cette section — “the server is therefore redirecting the client to make use of that stored representation as if it were the content of a 200 (OK) response” (traduction) « le serveur redirige donc le client vers cette représentation stockée afin qu’il l’utilise comme si elle était le contenu d’une réponse 200 (OK) » — mais il faut le lire attentivement : le client est renvoyé vers son propre cache, pas vers une autre URL. Il n’y a aucun en-tête Location ni nouvelle adresse. Cette phrase explique l’essentiel de la confusion autour de la question « une 304 est-elle une redirection ? » : pas au sens HTTP.

Deux autres points normatifs sont importants :

• Aucun corps, jamais. La RFC 9110 dit : “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (traduction) « Une réponse 304 se termine à la fin de la section des en-têtes ; elle ne peut contenir ni contenu ni bandes-annonces. » Une 304 qui contient un corps viole la spécification et certains clients peuvent la traiter incorrectement. C’est une règle ferme, pas une préférence de style.
• Les mêmes métadonnées qu’une 200. Le serveur “MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request: Content-Location, Date, ETag, and Vary,” (traduction) « DOIT générer tous les champs d’en-tête suivants qui auraient été envoyés dans une réponse 200 (OK) à la même requête : Content-Location, Date, ETag et Vary », ainsi que Cache-Control et Expires lorsque cela s’applique. Une 304 reprend donc les en-têtes de la 200, sans la charge utile.

Comment fonctionne réellement une 304 : les requêtes conditionnelles

Un serveur n’envoie jamais une 304 sans raison. C’est toujours la réponse à une requête conditionnelle : le client la rend conditionnelle en lui joignant un validateur enregistré lors d’une réponse précédente. Il existe deux validateurs.

ETag et If-None-Match

Un ETag (entity tag) est un jeton opaque que le serveur joint à une réponse 200 : imaginez une empreinte de version pour la représentation exacte de l’URL. À la requête suivante vers cette URL, le client renvoie la valeur enregistrée dans un en-tête If-None-Match. Le serveur compare les deux valeurs : si l’ETag actuel correspond toujours, rien n’a changé et il renvoie 304 ; s’il diffère, il renvoie une nouvelle 200 avec le contenu mis à jour et un nouvel ETag.

Last-Modified et If-Modified-Since

L’alternative fondée sur la date : le serveur envoie un horodatage Last-Modified avec la 200. Ensuite, le client le renvoie dans un en-tête If-Modified-Since, et le serveur compare les dates. Si la ressource n’a pas changé depuis cet horodatage, il renvoie une 304. Cette méthode est plus simple mais moins précise (elle ne peut pas être plus fine que l’horodatage) et sensible au format exact de la date HTTP, source fréquente de bugs. Lorsque les deux validateurs sont présents, If-None-Match (l’ETag) prend le pas sur If-Modified-Since.

ETags forts et faibles

Un ETag peut être fort ou faible, et cette différence compte. Selon le guide MDN sur les requêtes conditionnelles, “strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (traduction) « La validation forte consiste à garantir que la ressource est identique, octet par octet, à celle à laquelle on la compare. » Un ETag faible porte le préfixe W/ (par exemple, ETag: W/"abc123") et affirme seulement une équivalence sémantique. L’exemple de MDN précise qu’“a page that would differ from another only by a different date in its footer, or different advertising, would be considered identical to the other with weak validation.” (traduction) « Une page qui ne différerait d’une autre que par une date différente dans son pied de page ou par une publicité différente serait considérée comme identique avec une validation faible. » Les ETags forts (sans préfixe) sont nécessaires pour les requêtes de plage qui exigent une correspondance octet par octet ; les ETags faibles conviennent lorsque la compression, les espaces ou des différences insignifiantes ne doivent pas forcer un nouveau téléchargement. Le piège pratique : si votre ETag change à chaque recompression gzip/Brotli ou varie selon les serveurs derrière un répartiteur, vous déclenchez des réexplorations inutiles. Choisissez le type voulu et gardez sa valeur stable pour un contenu réellement inchangé.

L’échange complet, étape par étape

1. Première requête → le serveur renvoie 200 OK avec le contenu, ainsi que ETag et/ou Last-Modified.
2. Le client enregistre le contenu et ces validateurs.
3. Requête suivante → le client envoie If-None-Match et/ou If-Modified-Since avec les valeurs enregistrées.
4. Le serveur décide : contenu inchangé → 304 Not Modified, sans corps, et le client réutilise son cache ; contenu modifié → 200 OK avec le nouveau corps et de nouveaux validateurs. Evidence for this claim RFC 9111 defines validation as checking whether a stored response remains current, typically with a conditional request that can receive 304 Not Modified. Scope: HTTP cache validation; it does not create a Search ranking benefit. Confidence: high · Verified: 2026-07-14 IETF: RFC 9111 §4.3 — Validation

Si vous souhaitez approfondir la mise en cache et les validateurs comme levier d’efficacité d’exploration — l’ensemble de l’histoire des requêtes conditionnelles et son lien avec le budget d’exploration — consultez l’article compagnon. Celui-ci reste centré sur le code d’état.

304 et SEO : aucun effet sur le classement, un vrai gain d’efficacité d’exploration

Voici toute l’histoire SEO, plus limitée que ne le laisse entendre beaucoup de textes génériques. Une 304 n’a aucun effet direct sur le classement, et les propres indications de Google sur l’effet des codes d’état sur l’exploration et l’indexation en bornent aussi la portée : Search peut recalculer les signaux d’une URL, mais une 304 ne modifie pas autrement son indexation. Google possède déjà le contenu de l’exploration précédente ; une 304 confirme simplement que rien n’a changé. Il n’existe donc aucun bonus de classement à renvoyer des 304.

Ce qu’une 304 vous apporte, ce sont des économies de ressources susceptibles d’améliorer indirectement l’efficacité de l’exploration. Dans son article de décembre 2024 sur la mise en cache HTTP, Gary Illyes l’explique ainsi : “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. 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) « Pour un site vaste dont les URL changent rarement, autoriser la mise en cache locale peut rendre l’exploration plus efficace. Selon la norme HTTP, l’infrastructure d’exploration de Google s’appuie notamment sur ETag/If-None-Match et Last-Modified/If-Modified-Since. »

Sur le mécanisme précis de la 304, le même article explique pourquoi l’absence de corps est essentielle : si l’ETag envoyé par le robot “matches the current value the server generated, your server should return an HTTP 304 (Not modified) status code with no HTTP body,” (traduction) « correspond à la valeur actuelle générée par le serveur, celui-ci doit renvoyer une réponse HTTP 304 (Not modified) sans corps HTTP ». Cette absence de corps compte parce que “your server doesn’t have to spend compute resources on actually generating content” (traduction) « votre serveur n’a pas à dépenser de ressources de calcul pour générer réellement le contenu » et “doesn’t have to transfer the HTTP body” (traduction) « n’a pas à transférer le corps HTTP ». Vous économisez donc du calcul et de la bande passante des deux côtés. Google décrit le bénéfice en termes conditionnels : ces économies peuvent améliorer indirectement l’efficacité de l’exploration. Ce n’est pas la promesse que l’effort épargné sera automatiquement réaffecté à vos URL nouvelles ou mises à jour ; considérez-le comme un mécanisme d’économie de ressources dont le ruissellement est plausible, mais non garanti.

Pourquoi cela compte davantage sur les grands sites

Si vous avez quelques centaines de pages, l’effet reste largement théorique : Google explorera confortablement l’ensemble du site. Le bénéfice augmente avec la taille : un site comptant des centaines de milliers ou des millions d’URL, dont beaucoup changent rarement, gagne réellement à ce que les robots évitent de retélécharger les ressources inchangées. C’est le public visé par l’article de Google, et c’est le cadrage honnête à conserver : ne présentez pas la 304 comme une tactique indispensable aux petits sites.

ETag ou Last-Modified, et ce qui compte comme une « modification »

Google recommande ETag comme validateur principal : « We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value). » (traduction) « Nous recommandons vivement ETag, car il est moins sujet aux erreurs et aux fautes (sa valeur n’est pas structurée, contrairement à celle de Last-Modified). » Configurer les deux est possible et encouragé. Si vous utilisez Last-Modified, la date « must be formatted according to the HTTP standard » (traduction) « doit respecter le format de la norme HTTP » ; Google recommande le format « Weekday, DD Mon YYYY HH:MM:SS Timezone, » (traduction) « Jour, JJ Mmm AAAA HH:MM:SS Fuseau », par exemple « Fri, 4 Sep 1998 19:15:56 GMT » (traduction), sinon elle peut être ignorée silencieusement. Google suggère également de définir le champ max-age de Cache-Control pour aider les robots à décider quand explorer de nouveau.

Ce qui mérite d’invalider le cache relève de votre décision, mais Google conseille de réserver cette opération aux changements substantiels : “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 vous recommandons d’exiger un rafraîchissement du cache lors des changements importants de votre contenu ; si vous avez seulement modifié la date de copyright au bas de la page, ce changement n’est probablement pas important. »

Ce que Googlebot et Bingbot en font réellement

Toutes les requêtes de robots ne sont pas conditionnelles. La documentation de Google indique que la prise en charge de la mise en cache varie selon les robots et les récupérateurs Google, en fonction du produit desservi : Googlebot la prend en charge lors de nouvelles explorations d’URL pour Search, tandis que certains autres récupérateurs ne l’utilisent que dans certaines conditions. Même avec des en-têtes correctement configurés, ne vous attendez donc pas à ce que 100 % des requêtes portent If-None-Match ou If-Modified-Since. Pour Bing, les requêtes conditionnelles ne sont pas propres à Google. Le robot de Bing prend en charge les GET conditionnels (avec If-Modified-Since et, lorsqu’il est disponible, If-None-Match, puis l’acceptation d’une 304 lorsque le contenu est inchangé) depuis au moins un article Live Search de 2008. Bing n’a toutefois pas publié d’équivalent moderne de l’article de Google de 2024. Considérez donc ce mécanisme comme un comportement HTTP générique qui s’applique aux deux moteurs.

Comment mettre en œuvre la prise en charge de 304

1. Envoyer les validateurs avec la 200. Configurez votre serveur, votre CDN ou votre application pour joindre un ETag (recommandé) et/ou un en-tête Last-Modified au format correct aux réponses 200 normales. De nombreux serveurs et frameworks génèrent automatiquement les ETags pour les fichiers statiques ; les réponses dynamiques nécessitent généralement une activation explicite.
2. Respecter les en-têtes conditionnels à la requête suivante. Lorsqu’une requête contient If-None-Match/If-Modified-Since, comparez-les au validateur actuel et renvoyez 304 (sans corps) lorsqu’il correspond toujours, ou une nouvelle 200 dans le cas contraire. Les serveurs de fichiers statiques le font souvent pour vous ; les routes applicatives et les edge workers ne le font pas nécessairement sans configuration.
3. Décider ce que signifie « modifié » et conserver l’ETag stable pour un contenu réellement inchangé. Ne laissez pas une recompression ou une variation entre serveurs le faire changer inutilement.
4. Surveiller les erreurs classiques :
   • Toujours 200 — aucun validateur n’est émis, donc aucune requête ne devient conditionnelle et vous perdez le gain d’efficacité.
   • ETags instables — une valeur change alors que le contenu ne change pas (répartiteur de charge, recompression), ce qui force des retéléchargements constants.
   • 304 périmées — le cas dangereux : le serveur continue de renvoyer 304 (ou le même ETag) après une vraie modification du contenu ; robots et caches ne récupèrent alors jamais la mise à jour. C’est un bug à rechercher dans l’analyse des journaux, pas un défaut inhérent à la 304.

304 vs. autre status codes

304 par rapport à 301 / 302 / 307 / 308

Ce sont les véritables redirections. Une 301/308 (permanente) ou une 302/307 (temporaire) transporte un en-tête Location et déplace le client vers une URL différente — les 301/308 transmettent également un signal de canonicalisation. Une 304 n’a pas de Location, ne déplace personne et ne transmet aucun signal de classement. Même famille 3xx par le numéro, mais fonction complètement différente. Le détail de chaque redirection figure dans ses propres articles (voir l’article sur la redirection 301 et le sous-centre des redirections).

304 vs. 204 aucun contenu

Les deux réponses n’ont pas de corps, mais pour des raisons totalement différentes. Une 204 No Content est un succès 2xx dont le corps est volontairement vide parce que le serveur n’a réellement rien à envoyer — par exemple après un DELETE/PUT d’API réussi ou pour une balise d’analyse. Une 304 n’envoie pas non plus de corps, mais non parce qu’il n’y aurait rien à envoyer : elle signifie « vous l’avez déjà et elle reste valide ». Ne les confondez pas : une 204 sur une URL de page peut être traitée comme un soft 404 faute de contenu indexable, tandis qu’une 304 confirme la validité du contenu que Google possède déjà. L’article sur 204 No Content couvre entièrement ce code.

Mythes courants à propos de 304

1. « 304 est une redirection. » Aucun en-tête Location, personne ne va nulle part. Le client réutilise sa propre copie en cache. L’expression “redirecting the client to make use of that stored representation” (traduction) « rediriger le client pour qu’il utilise cette représentation stockée » de la RFC 9110 signifie un retour vers le cache, pas vers une autre URL.
2. « 304 est une erreur à corriger. » C’est le résultat correct et attendu d’une configuration fonctionnelle des requêtes conditionnelles. Voir des 304 dans un crawl ou dans DevTools indique que la mise en cache fonctionne.
3. « 304 améliore le classement. » Elle n’a aucun effet direct sur le classement et Google borne aussi l’effet d’indexation : Search peut recalculer les signaux d’une URL, mais une 304 ne modifie pas autrement l’indexation. Le bénéfice vient des économies de ressources qui peuvent améliorer indirectement l’efficacité de l’exploration sur les grands sites ; ce n’est ni un signal de classement ni une garantie de réaffectation.
4. “If my server returns 304, Google will use stale content forever.” (traduction) « Si mon serveur renvoie 304, Google utilisera du contenu périmé pour toujours. » La 304 ne s’applique que tant que le validateur correspond. Dès que le contenu change réellement, un serveur correctement mis en œuvre renvoie une nouvelle 200 avec de nouveaux validateurs. Le vrai risque est un serveur mal configuré qui continue de renvoyer 304 après une modification.

5. « ETag et Last-Modified sont interchangeables. » Ce sont tous deux des validateurs, mais Last-Modified dépend du format de date et de la précision de l’horodatage, tandis que ETag est opaque et précis. Google recommande ETag en priorité et les deux si possible.

Questions fréquentes

Une réponse HTTP 304 est-elle une erreur ? Non : c’est le signe que la mise en cache fonctionne. Elle signifie que la copie en cache du client est toujours valide.

Une 304 est-elle une redirection ? Non. Elle appartient à la classe 3xx par sa numérotation, mais ne contient aucun en-tête Location et ne déplace pas le client vers une nouvelle URL.

Une 304 aide-t-elle le SEO ou le classement ? Elle n’a aucun effet direct sur le classement et aucun effet sur l’indexation au-delà d’un éventuel recalcul des signaux d’une URL par Google. Elle économise de la bande passante et du calcul en permettant aux robots d’éviter les pages inchangées ; Google indique que cela peut améliorer indirectement l’efficacité de l’exploration sur les grands sites.

Quelle est la différence entre ETag et Last-Modified ? ETag est une empreinte de version opaque comparée via If-None-Match ; Last-Modified est un horodatage comparé via If-Modified-Since. Google recommande ETag, moins sujet aux erreurs.

Qu’est-ce qui distingue un ETag faible d’un ETag fort ? Un ETag fort affirme que le contenu est identique octet par octet ; un ETag faible (préfixé par W/) affirme une équivalence sémantique et tolère des différences insignifiantes, comme la compression ou la date modifiée d’un pied de page.

Pourquoi vois-je des 304 dans mes journaux ou rapports d’exploration ? Parce que les clients envoient des requêtes conditionnelles et que votre serveur confirme correctement que le contenu n’a pas changé. C’est attendu et souhaitable.

Comment faire renvoyer correctement une 304 à mon serveur ? Envoyez ETag/ Last-Modified avec la 200, puis respectez If-None-Match/If-Modified-Since à la requête suivante en renvoyant 304 sans corps lorsque le validateur correspond toujours.

Quelle est la différence entre 304 et 204 ? Les deux sont sans corps : 204 parce qu’il n’y a rien à envoyer, 304 parce que le client possède déjà une copie toujours valide.

Googlebot envoie-t-il des en-têtes conditionnels à chaque requête ? Non : la prise en charge de la mise en cache varie selon le robot, donc toutes les requêtes ne sont pas conditionnelles, même avec des en-têtes correctement configurés.

Une réponse 304 peut-elle contenir un corps ? Non. Selon la RFC 9110, “it cannot contain content or trailers.” (traduction) « elle ne peut contenir ni contenu ni bandes-annonces ». Une 304 avec un corps viole la spécification.

Résumé par IA

Aperçu condensé de la version avancée :

• Une 304 Non modifié répond à une requête conditionnelle GET/HEAD dont la condition est évaluée comme fausse et qui aurait sinon produit une 200 (RFC 9110 §15.4.5). Elle appartient à la classe 3xx, mais n’est pas une redirection : aucun en-tête Location, aucune nouvelle URL et, selon la règle normative, aucun corps — “it cannot contain content or trailers” (traduction) « elle ne peut contenir ni contenu ni bandes-annonces ». La deuxième visite est un exemple courant de requête conditionnelle, pas une règle du protocole.
• C’est la réponse à une requête conditionnelle. Un GET/HEAD porte If-None-Match (comparé à un ETag) et/ou If-Modified-Since (comparé à Last-Modified). Si le validateur correspond toujours, le serveur renvoie 304 et le client réutilise sa copie en cache.
• Le mot « redirection » de la spécification est métaphorique : le client est renvoyé vers son propre cache, pas vers une autre URL. C’est ce qui alimente l’essentiel de la confusion sur le statut de redirection de la 304.
• ETag et Last-Modified : ETag est un jeton de version opaque, comparé via If-None-Match ; Last-Modified est une date, comparée via If-Modified-Since, avec un format HTTP exact. If-None-Match prend le pas lorsque les deux sont présents. ETag fort = identité octet par octet ; ETag faible (W/) = équivalence sémantique.
• Aucun effet direct sur le classement et aucun effet d’indexation au-delà d’un éventuel recalcul des signaux d’une URL par Google. Google possède déjà le contenu et la 304 confirme simplement qu’il n’a pas changé. Comme l’explique Gary Illyes, la mise en cache « may help your site be crawled more efficiently » (traduction) « peut aider votre site à être exploré plus efficacement » : le bénéfice est une économie de ressources susceptible d’améliorer indirectement l’efficacité de l’exploration des grands sites, pas une réaffectation garantie du budget ni un signal de classement.
• Google recommande ETag en priorité (“less prone to errors and mistakes” (traduction) « moins sujet aux erreurs et aux fautes ») ; configurer les deux est possible. Last-Modified doit respecter le format “Weekday, DD Mon YYYY HH:MM:SS Timezone” (traduction) « Jour, JJ Mmm AAAA HH:MM:SS Fuseau ». N’invalidez le cache que pour des changements importants, pas pour une date de copyright en pied de page.
• La mise en cache varie selon les robots : tous les crawls de Googlebot ne sont pas conditionnels. Bing prend en charge les GET conditionnels depuis un article Live Search de 2008 ; c’est un comportement HTTP générique.
• Ne pas confondre avec les 301/302/307/308 (vraies redirections qui déplacent l’URL) ni avec 204 No Content (également sans corps, mais parce qu’il n’y a réellement rien à envoyer).
• Le vrai risque ne vient pas de la 304 elle-même, mais d’un serveur mal configuré qui renvoie 304 après une modification réelle du contenu. Recherchez-le dans les journaux. Une 304 valide peut aussi sembler être une erreur à certaines bibliothèques clientes ou couches de cache de plateforme, même lorsque rien ne va mal.

Documentation officielle

Références primaires sur la nature de la 304 et son utilisation par les moteurs de recherche.

Spécification HTTP et référence navigateur

• RFC 9110 §15.4.5 — 304 Non modifié — définition faisant autorité : requête conditionnelle, absence de corps et en-têtes requis.
• MDN — 304 Non modifié — explication accessible, déclenchement par If-None-Match/If-Modified-Since et liste des en-têtes qu’une 304 doit transporter.
• MDN — Requêtes HTTP conditionnelles — explication de la validation forte et faible.
• MDN — ETag — en-tête ETag, avec la syntaxe faible (W/) et forte.

Google Search Central

• Exploration de décembre : mise en cache HTTP — article de Gary Illyes du 9 décembre 2024 : rôle d’ETag/If-None-Match et de Last-Modified/If-Modified-Since dans les 304 et raisons pour lesquelles ils peuvent améliorer l’efficacité de l’exploration.
• Vue d’ensemble des robots Google (User Agent) — robots Google prenant en charge la mise en cache et recommandation d’ETag plutôt que Last-Modified.
• Comment les codes d’état HTTP affectent les robots de Google — ligne actuelle de Google sur la 304, avec la précision que Search peut recalculer les signaux d’une URL même si la 304 n’a sinon aucun effet d’indexation.
• Résoudre les erreurs d’exploration de Google Search — source de la formulation prudente de Google : les économies de ressources des requêtes conditionnelles peuvent « may indirectly » (traduction) « améliorer indirectement » l’efficacité de l’exploration, et Google n’envoie pas d’en-têtes conditionnels à chaque tentative.

Bing

• Annonce des améliorations des robots de Live Search — ancien article Bing/Live Search confirmant la prise en charge des GET conditionnels (If-Modified-Since/If-None-Match → 304) depuis 2008.

Citations issues de la source

Déclarations consignées. Chaque lien pointe directement vers le passage cité sur la page source où il est attesté.

La spécification HTTP

• “The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false.” (traduction) « Le code d’état 304 (Not Modified) indique qu’une requête GET ou HEAD conditionnelle a été reçue et aurait produit une réponse 200 (OK) si la condition n’avait pas été évaluée comme fausse. » — RFC 9110, HTTP Semantics, §15.4.5. Lire la section
• “A 304 response is terminated by the end of the header section; it cannot contain content or trailers.” (traduction) « Une réponse 304 se termine à la fin de la section des en-têtes ; elle ne peut contenir ni contenu ni bandes-annonces. » — RFC 9110, §15.4.5 (règle normative : aucun corps). Lire la section

MDN Web Docs

• “The HTTP 304 Not Modified redirection response status code indicates that there is no need to retransmit the requested resources.” (traduction) « Le code d’état de réponse de redirection HTTP 304 Not Modified indique qu’il n’est pas nécessaire de retransmettre les ressources demandées. » Aller à la citation
• “Strong validation consists of guaranteeing that the resource is, byte to byte, identical to the one it is compared to.” (traduction) « La validation forte consiste à garantir que la ressource est identique, octet par octet, à celle à laquelle on la compare. » — MDN, « HTTP conditional requests ». Lire le guide

Gary Illyes, Google — « Crawling December: HTTP caching » (9 décembre 2024)

• “Especially if you have a large site with rarely-changing content under individual URLs, allowing caching locally may help your site be crawled more efficiently. 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) « En particulier, si votre site est vaste et que le contenu de chaque URL change rarement, la mise en cache locale peut aider à l’explorer plus efficacement. L’infrastructure d’exploration de Google prend en charge la mise en cache HTTP heuristique définie par la norme HTTP, notamment via l’en-tête de réponse ETag et l’en-tête de requête If-None-Match, ainsi que via l’en-tête de réponse Last-Modified et l’en-tête de requête If-Modified-Since. » Lire l’article
• “We strongly recommend using ETag because it’s less prone to errors and mistakes (the value is not structured unlike the Last-Modified value).” (traduction) « Nous recommandons vivement ETag, car sa valeur est moins sujette aux erreurs que celle de Last-Modified. » Lire l’article
• “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) « Si la valeur ETag envoyée par le robot correspond à la valeur actuelle du serveur, renvoyez une 304 sans corps HTTP. » Lire l’article
• “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) « Exigez un rafraîchissement du cache lors des changements importants ; modifier uniquement la date de copyright en bas de page ne l’est probablement pas. » Lire l’article

Patrick Stox — Ahrefs

• “304 Not Modified – Says the page hasn’t been modified. Typically used for caching.” (traduction) « 304 Non modifié — indique que la page n’a pas été modifiée. Généralement utilisé pour la mise en cache. » — extrait de mon guide Codes d’état HTTP et leur impact SEO (cet article approfondit ce point). Aller à la citation

304 en contexte : les codes sans corps et 3xx avec lesquels on la confond

304 et ses faux amis

Le piège : 304 et 204 sont tous deux sans corps, et 304/301/302/307/308 sont tous des 3xx — mais la 304 est l’exception sur les deux axes. C’est le seul 3xx qui ne déplace personne et le seul code sans corps qui signifie « vous l’avez déjà » plutôt que « il n’y a rien à envoyer ».

Les deux validateurs

Lorsque les deux sont présents, If-None-Match prend le pas sur If-Modified-Since.

Faits essentiels

• 304 n’a aucun corps, jamais : la RFC 9110 en fait une règle normative.
• 304 est un code 3xx, mais pas une redirection (aucun Location, aucune nouvelle URL).
• Aucun effet direct sur le classement, ni effet d’indexation au-delà d’un éventuel recalcul des signaux d’une URL : le bénéfice est une économie de ressources susceptible d’améliorer indirectement l’efficacité de l’exploration des grands sites.
• Google recommande ETag en priorité ; configurer à la fois ETag et Last-Modified convient.
• Last-Modified doit respecter « Weekday, DD Mon YYYY HH:MM:SS Timezone » (traduction) « Jour, JJ Mmm AAAA HH:MM:SS Fuseau », sinon il peut être ignoré.
• Invalidez le cache pour des changements importants, pas pour une année de copyright au pied de page.
• Toutes les requêtes de robots ne sont pas conditionnelles : la prise en charge du cache varie selon le robot.
• Bing prend en charge les GET conditionnels → 304 depuis 2008 ; c’est un comportement HTTP générique.
• Le vrai risque est une 304 périmée (le serveur renvoie 304 après une modification) : recherchez-la dans l’analyse des journaux.

L’échange d’une requête conditionnelle en HTTP brut

Exemples concrets de chaînes requête/réponse montrant comment une 304 est produite. (Les valeurs d’en-tête sont données à titre d’illustration.)

ETag / If-None-Match — première récupération (200)

GET /blog/my-article/ HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

<full page body here>

Le client enregistre le corps et la valeur ETag.

ETag / If-None-Match — récupération suivante, contenu inchangé (304)

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 304 Not Modified
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

Aucun corps. L’ETag correspondait ; le serveur a donc économisé le calcul de génération de la page et la bande passante nécessaire à son envoi. Le client réutilise sa copie en cache.

Last-Modified / If-Modified-Since — équivalent fondé sur la date

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT

HTTP/1.1 304 Not Modified
Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT

Notez le format HTTP-date exact — « Weekday, DD Mon YYYY HH:MM:SS Timezone » (traduction) « Jour, JJ Mmm AAAA HH:MM:SS Fuseau » — que Google recommande pour éviter les problèmes d’analyse.

Lorsque le contenu a changé — une nouvelle 200, pas une 304

GET /blog/my-article/ HTTP/1.1
Host: example.com
If-None-Match: "a1b2c3d4"

HTTP/1.1 200 OK
Content-Type: text/html
ETag: "e5f6g7h8"          ← new value: content changed

<updated page body here>

L’ETag enregistré ne correspond plus ; le serveur envoie donc le nouveau contenu et un nouveau validateur. Le cache est mis à jour. C’est précisément pourquoi une 304 correctement mise en œuvre ne peut pas « piéger » un robot avec un contenu périmé : dès que le contenu change, le validateur change et la requête suivante reçoit une vraie 200.

ETag faible et ETag fort

ETag: "a1b2c3d4"      ← strong: asserts byte-for-byte identity
ETag: W/"a1b2c3d4"    ← weak: asserts semantic equivalence (the W/ prefix)

Règle pratique : si vous gérez un grand site avec beaucoup d’URL qui changent rarement, envoyer un ETag stable (et respecter If-None-Match) avec vos 200 permet aux robots de confirmer « toujours identique » avec une 304 rapide et sans corps. Vous économisez de la bande passante et du calcul, ce qui, selon Google, peut améliorer indirectement l’efficacité d’exploration du reste du site. Si l’ETag change à chaque recompression ou d’un serveur à l’autre derrière un répartiteur, vous perdez ce bénéfice.

Erreurs de 304 qui cassent la mise en cache conditionnelle

Modifier l’ETag alors que la représentation n’a pas changé

Un ETag lié à une instance de serveur, à une passe de compression ou à l’horodatage de la requête annule l’intérêt du validateur : un contenu inchangé continue de renvoyer une 200 complète. Générez un validateur stable à partir de la représentation, ou utilisez délibérément un ETag faible lorsque les différences au niveau des octets ne sont pas significatives.

Renvoyer 304 après une modification du contenu

Un validateur périmé peut dissimuler une vraie mise à jour aux clients et aux robots. Invalidez l’ETag ou avancez Last-Modified à chaque modification de la représentation, puis vérifiez que l’ancienne requête conditionnelle reçoit une nouvelle 200 avec son corps.

Envoyer 304 sans requête conditionnelle correspondante

Un serveur ne doit pas supposer qu’un client possède une copie en cache. Renvoyez 304 seulement après avoir évalué If-None-Match ou If-Modified-Since ; une première requête ordinaire nécessite une réponse complète.

Traiter 304 comme une redirection ou une page vide

Une 304 n’a aucun en-tête Location ni corps de réponse. Ne la faites pas passer par la logique des redirections et ne remplacez pas une ressource réellement vide par une 304 ; utilisez le statut qui décrit la réponse réelle.

Problèmes courants liés aux 304

Le serveur renvoie toujours 200

Symptôme : des requêtes répétées téléchargent le corps complet même lorsque rien n’a changé. Cause probable : la réponse initiale ne contient aucun validateur, ou l’application ignore les en-têtes de requête conditionnelle. Correctif : envoyez ETag et/ou un Last-Modified valide, puis implémentez la vérification de correspondance If-None-Match ou If-Modified-Since. Confirmez qu’une requête inchangée renvoie une 304 sans corps.

Des serveurs d’origine différents produisent des ETags différents

Symptôme : la même URL inchangée alterne entre 200 et 304 derrière un répartiteur de charge. Cause probable : chaque nœud génère son propre validateur. Correctif : calculez l’ETag à partir d’un état de contenu partagé, pas du nœud qui sert la réponse, et répétez la même requête conditionnelle contre plusieurs réponses.

Un contenu mis à jour renvoie toujours 304

Symptôme : un navigateur ou un robot conserve une ancienne représentation après un déploiement. Cause probable : le validateur n’a pas été invalidé avec le contenu. Correctif : corrigez la clé de cache ou la logique de déploiement, purgez le cache concerné si nécessaire et vérifiez que l’ancien ETag reçoit désormais une 200 avec un nouveau validateur.

Last-Modified semble ignoré

Symptôme : If-Modified-Since ne produit jamais de 304. Cause probable : une date HTTP invalide, une précision d’horodatage insuffisante ou un ETag prioritaire. Correctif : inspectez les en-têtes bruts, corrigez le format de date et testez chaque validateur séparément.

Une 304 ressemble à une erreur dans le code de l’application

Symptôme : un script ou une application lève une exception, ou journalise une « erreur », pour une requête qui a réellement reçu une 304. Cause probable : certaines bibliothèques clientes HTTP traitent tout statut différent de 200 — y compris une 304 valide — comme une condition proche d’une exception, sauf si vous les configurez explicitement pour suivre les redirections ou accepter les réponses Not Modified. C’est une bizarrerie de bibliothèque cliente, pas un problème de protocole ou de serveur. Correctif : vérifiez la gestion spécifique de la 304 par la bibliothèque (et pas seulement sa gestion des erreurs 4xx/5xx), puis confirmez que la réponse HTTP brute est correcte et sans corps avant d’accuser le serveur.

Une couche de cache de plateforme (par exemple IIS output caching) brouille le diagnostic

Symptôme : l’application d’origine semble correcte, mais le comportement des 304 reste étrange. Cause probable : une couche de cache propre à la plateforme d’hébergement — IIS output caching en est un exemple documenté — se trouve entre l’application et le client et peut générer ou intercepter elle-même des réponses 304. Correctif : considérez-la comme une couche possible parmi d’autres (application d’origine, CDN, répartiteur de charge, cache de plateforme), pas comme le suspect par défaut. Isolez-la avec un test contrôlé qui modifie le validateur sur chaque couche, une à la fois, avant de conclure laquelle est responsable.

Prompt : auditer une trace de requête conditionnelle

Collez les en-têtes de requête et de réponse d’une récupération initiale et d’une récupération répétée.

Act as an HTTP caching reviewer. I will paste two request/response header traces for
the same URL: an initial fetch and a conditional repeat. Identify the validator used,
check whether If-None-Match or If-Modified-Since was evaluated correctly, verify that
a 304 has no body or Location header, and flag unstable or stale-validator risks.
Return: observed flow, pass/fail checks, likely cause of each failure, and the exact
next request I should run. Do not infer headers that are not present.

[PASTE BOTH TRACES]

Prompt : examiner une implémentation ETag

Collez la configuration pertinente de l’application, du CDN ou du serveur.

Review this ETag/Last-Modified implementation for conditional GET correctness. Trace
the 200 -> conditional request -> 304 path, explain what causes the validator to
change, and test mentally for multiple origin nodes, compression variants, and real
content updates. Separate protocol violations from efficiency issues. Give a minimal
fix and a curl-based validation plan. Do not invent platform behavior.

[PASTE CONFIGURATION OR CODE]

Shell : rejouer un ETag comme requête conditionnelle

Exécutez ceci dans un terminal macOS/Linux. Copiez l’ETag à l’identique, guillemets compris.

URL='https://example.com/page'
curl -sS -D - -o /dev/null "$URL"
curl -sS -D - -o /dev/null -H 'If-None-Match: "PASTE_ETAG_HERE"' "$URL"

La première réponse doit exposer le validateur. La deuxième doit renvoyer 304 lorsque la représentation est inchangée et 200 lorsque l’ETag fourni est périmé.

PowerShell : tester Last-Modified

Exécutez ceci dans PowerShell après avoir remplacé l’URL et l’horodatage.

$url = 'https://example.com/page'
$headers = @{ 'If-Modified-Since' = 'Tue, 14 Jul 2026 12:00:00 GMT' }
Invoke-WebRequest -Uri $url -Headers $headers -SkipHttpErrorCheck

Console DevTools : lister les validateurs des ressources de la page

Exécutez ceci dans la console du navigateur. Le script signale les entrées de performance des ressources ; utilisez le panneau Réseau pour inspecter les vrais en-têtes ETag, Last-Modified et de statut.

console.table(performance.getEntriesByType('resource').map(r => ({name: r.name, transferSize: r.transferSize, encodedBodySize: r.encodedBodySize})));

Outils pour inspecter le comportement des 304

• HTTP Header Checker: inspectez ETag, Last-Modified, Cache-Control, Vary et les empreintes CDN/edge dans la réponse normale avant de rejouer un validateur.
• Panneau Réseau des DevTools du navigateur : désactivez « Disable cache », rechargez et comparez les en-têtes de requête et de réponse. Les DevTools rendent aussi visibles HSTS et le cache local ; distinguez donc le comportement du navigateur de ce qu’a envoyé l’origine.
• curl : envoyez un en-tête If-None-Match ou If-Modified-Since exact sans que l’état du cache du navigateur interfère.
• Journaux d’accès : mesurez quelles requêtes de robots étaient conditionnelles et si elles ont abouti à 304 ou à une 200 complète.

Vérifier le fonctionnement des réponses conditionnelles après une modification

Test d’une représentation inchangée

Test à exécuter : récupérez l’URL, copiez son ETag, puis recommencez avec curl -I -H 'If-None-Match: "VALUE"' URL. Résultat attendu : 304, le validateur correspondant et aucun corps ni Location. Interprétation d’un échec : le serveur a ignoré la condition ou généré un validateur instable. Fenêtre de surveillance : immédiate. Déclencheur de retour arrière : la modification du cache fait perdre aux requêtes ordinaires leur réponse 200 complète.

Test d’une représentation modifiée

Test à exécuter : déployez une vraie modification de contenu, puis rejouez l’ancien ETag. Résultat attendu : 200 avec le corps mis à jour et un nouveau validateur. Interprétation d’un échec : l’invalidation du cache est périmée. Fenêtre de surveillance : immédiatement après que le déploiement a atteint chaque origine. Déclencheur de retour arrière : une origine renvoie encore 304 pour l’ancien validateur une fois le déploiement terminé.

Test de stabilité multi-origines

Test à exécuter : répétez suffisamment de fois les mêmes requêtes normales et conditionnelles pour atteindre le pool de serveurs, en enregistrant l’ETag et le statut. Résultat attendu : les représentations inchangées utilisent des validateurs compatibles et produisent systématiquement 304. Interprétation d’un échec : les validateurs varient selon le nœud ou l’encodage sans stratégie Vary correspondante. Fenêtre de surveillance : immédiate, sur l’ensemble du pool déployé. Déclencheur de retour arrière : la nouvelle logique sert du contenu périmé ou mélange les représentations entre clients.

Mesurer la santé du cache conditionnel

Taux de réussite de la revalidation conditionnelle

Métrique : requêtes conditionnelles aboutissant à 304 par rapport aux 200 complètes. Ce qu’elle vous dit : si les ressources inchangées évitent les transferts inutiles. Comment l’extraire : regroupez les requêtes des journaux d’accès qui portent If-None-Match ou If-Modified-Since par statut de réponse et classe d’URL. Référence / plage réaliste : établissez une base par type de contenu ; les pages qui changent souvent ne doivent pas être forcées vers le taux des ressources statiques. Cadence : chaque semaine pendant le déploiement, puis chaque mois.

Octets évités lors des récupérations inchangées

Métrique : nombre estimé d’octets du corps de réponse non transférés pour les réponses 304 valides. Ce qu’elle vous dit : la part bande passante du gain d’efficacité d’exploration. Comment l’extraire : rapprochez le nombre de 304 des journaux de la taille de réponse complète la plus récente pour la même classe d’URL. Référence / plage réaliste : comparez avec la base du site avant la modification ; aucune cible universelle ne convient à tous les mélanges de contenu. Cadence : chaque mois.

Échecs liés aux validateurs périmés

Métrique : URL modifiées qui acceptent encore un ancien validateur. Ce qu’elle vous dit : si le gain d’efficacité se fait au détriment de l’actualité. Comment l’extraire : exécutez après le déploiement un petit échantillon qui rejoue les ETags antérieurs au déploiement. Référence / plage réaliste : toute réponse périmée confirmée nécessite une investigation. Cadence : à chaque déploiement qui modifie la mise en cache ou la génération des validateurs.

Testez vos connaissances : 304 Not Modified

Cinq questions rapides sur la signification et le fonctionnement d’une 304. Choisissez une réponse pour chacune, puis vérifiez.

Journal des modifications