Réponse courte
Le code HTTP 304 Not Modified indique qu’une ressource demandée n’a pas été modifiée depuis la dernière requête. Il permet au navigateur ou au robot d’utiliser sa version en cache, sans que le serveur renvoie le contenu. Ce n’est pas une erreur : c’est la preuve que la validation conditionnelle fonctionne.
# requête conditionnelle de Googlebot
GET /guide/ HTTP/1.1
If-None-Match: "a1b2c3"
If-Modified-Since: Mon, 19 Oct 2026 08:00:00 GMT
# réponse : rien n’a changé, aucun corps
HTTP/1.1 304 Not Modified
ETag: "a1b2c3"
Cache-Control: max-age=3600Les deux valideurs qui rendent le 304 possible
Sans valideur, pas de 304 : le serveur n’a rien pour comparer, et renvoie la ressource complète à chaque visite.
ETag ↔ If-None-Match
Une empreinte du contenu
Le serveur attribue une empreinte à la ressource. Le client la renvoie : si elle est identique, 304. Le plus précis des deux, à condition que l’empreinte reste stable entre les serveurs.
Last-Modified ↔ If-Modified-Since
Une date de modification
Le serveur annonce la date de dernière modification. Le client demande « modifié depuis ? ». Plus simple, mais trompeur si la date bouge à chaque génération de la page.
200 ou 304 : rejouez une visite de Googlebot
Choisissez ce que le serveur expose et ce qui a changé depuis le dernier passage : le simulateur montre la réponse attendue et ce qu’elle coûte, sur une page puis sur un passage complet du site.
Fonctionnement technique du statut 304
01 · 200
Première requête
Le serveur renvoie la ressource et ses valideurs : ETag, Last-Modified.
02 · GET
Requête conditionnelle
Le client renvoie If-None-Match et If-Modified-Since.
03 · =?
Validation
Le serveur compare les valideurs avec la version actuelle.
04 · 304
Réponse
Rien n’a changé : 304 sans corps, le client garde sa copie.
Pourquoi un 200 un jour et un 304 le lendemain ? Il suffit qu’un octet change (date affichée, jeton, bloc dynamique) pour que la validation échoue. Un CDN placé devant l’origine peut aussi répondre lui-même, avec ses propres règles de cache.
Quand le 304 devient un problème
- 01Configuration serveur absente
- Aucun ETag ni Last-Modified envoyé.
- Cache-Control incohérent avec le type de ressource.
- Comportement non testé avec curl et les outils réseau.
- 02Cache trop agressif
- Pages stratégiques, promos ou stocks servis en 304 alors qu’ils ont changé.
- Incohérence entre cache navigateur et cache CDN.
- 03Valideurs instables
- ETag différent selon le serveur d’un même cluster.
- Last-Modified recalculé à chaque génération de la page.
Impact SEO du code 304
- Budget d’exploration
- Le 304 permet à Googlebot de valider une ressource rapidement sans la retélécharger : ce qui est libéré sert aux pages stratégiques. Sur les sites volumineux, c’est un levier d’optimisation.
- Performance et UX
- Moins de données transférées, pages plus rapides, meilleur LCP, moins de charge serveur.
- Googlebot
- Le 304 n’est pas un « faux 200 » : il ne retire ni ne modifie rien dans l’index. Il dit seulement que la version connue est toujours la bonne.
Sur votre site
Votre cache est-il vraiment optimisé ?
Cache navigateur, CDN, ETag, Last-Modified, performance, budget d’exploration : je vérifie que vos 304 sont servis là où ils économisent, et jamais là où ils figent du contenu.
Contrôler ses réponses 304
- 01Tester avec curl. Récupérer l’ETag, puis rejouer la requête avec If-None-Match : la réponse doit être 304.
curl -I -H 'If-None-Match: "a1b2c3"' https://www.exemple.fr/page/ - 02L’onglet Réseau des DevTools. Recharger la page : les ressources inchangées doivent apparaître en 304 ou servies depuis le cache.
- 03Les journaux serveur. La part de 304 dans les requêtes de Googlebot, par type de ressource.
- 04La Search Console. Statistiques sur l’exploration : répartition des réponses et temps de réponse moyen.
Bonnes pratiques
À faire
- Activer ETag ou Last-Modified sur les pages HTML et les ressources statiques.
- Garder des ETag identiques sur tous les serveurs d’un même cluster.
- Adapter Cache-Control au type de ressource : long pour les statiques versionnées, court pour le HTML.
- Vider le cache CDN lors des mises à jour importantes.
- Tester le comportement avec curl après chaque changement de configuration.
À ne pas faire
- Servir un 304 sur un contenu qui a réellement changé.
- Recalculer Last-Modified à chaque génération de page.
- Laisser le CDN et l’origine appliquer des règles contradictoires.
- Désactiver les valideurs « pour être sûr ».
- Confondre 304 et redirection : il ne déplace rien.
Codes associés à connaître
Questions fréquentes sur le code 304
Le code 304 est-il une erreur pour Google ?
Non. Le 304 indique que la ressource n’a pas changé : c’est un fonctionnement normal du cache, qui économise du temps et de la bande passante.
Quelle différence entre 200 et 304 pour le SEO ?
Le 200 renvoie la ressource complète, le 304 confirme que la copie en cache est toujours valide. Les deux sont normaux : le 304 réduit simplement le coût de l’exploration.
Pourquoi j’ai parfois 200 et parfois 304 sur le même fichier ?
Cela dépend des valideurs, du cache du client et des intermédiaires. Un changement minime dans la page, ou un CDN qui répond à la place de l’origine, suffit à basculer de l’un à l’autre.
Comment vérifier si mon cache est bien configuré ?
Avec curl en rejouant l’ETag dans If-None-Match, et dans l’onglet Réseau des outils de développement. Une ressource inchangée doit répondre 304.
Quand le 304 peut-il devenir problématique ?
Quand il est servi alors que le contenu a changé : prix, stock, promo, page stratégique mise à jour. Le visiteur et Googlebot voient alors une version périmée.
Sources
- 1RFC 9110 : 304 Not Modified
- 2RFC 9111 : la mise en cache HTTP
- 3Search Central : la mise en cache HTTP et l’exploration
- 4MDN : le statut 304
