304 Not Modified répond à une requête GET ou HEAD conditionnelle, c’est-à-dire porteuse de If-None-Match ou If-Modified-Since, lorsque la condition montre que la copie stockée par le client est toujours à jour. Au lieu d’envoyer de nouveau la ressource, le serveur répond 304 et le client utilise sa copie en cache. On économise ainsi de la bande passante et du temps.
Une réponse 304 n’a jamais de corps ; elle se termine par la ligne vide qui suit les en-têtes. Parmi les en-têtes Cache-Control, Content-Location, Date, ETag, Expires et Vary, le serveur doit envoyer ceux qu’une réponse 200 aurait contenus, afin que les caches puissent mettre à jour la réponse stockée.
Bien que le code 304 appartienne à la plage 3xx, ce n’est pas une redirection. Il n’y a pas de Location, et le client reste sur la même URL. Un client qui reçoit un 304 sans avoir envoyé de requête conditionnelle a affaire à un serveur défectueux.
Exemple de réponse
HTTP/1.1 304 Not Modified
Date: Fri, 06 Nov 2026 10:15:32 GMT
ETag: "5f2b-1a3c"
Last-Modified: Wed, 28 Oct 2026 08:02:11 GMT
Cache-Control: public, max-age=600
Vary: Accept-EncodingSEO et vérification des redirections
Le code 304 facilite l’exploration. Les robots d’exploration de Google prennent en charge les requêtes conditionnelles, et un 304 indique à Googlebot que le contenu n’a pas changé depuis la dernière exploration. Cela économise de la capacité d’exploration et de la charge serveur, tandis que la page conserve sa place dans l’index : des en-têtes ETag ou Last-Modified fiables en valent donc la peine, surtout sur les grands sites.
Par défaut, TrueURL n’envoie pas d’en-têtes conditionnels : vous verrez donc un 200 plutôt qu’un 304. Pour tester la revalidation, ajoutez un en-tête If-None-Match contenant l’ETag de la page dans la section En-têtes de requête personnalisés.
Causes fréquentes et cas d’usage
- Un navigateur revalide une page, une image ou un script en cache avec
If-None-Match, et l’ETagcorrespond toujours. - Un robot d’exploration ou un lecteur de flux récupère de nouveau une ressource avec
If-Modified-Since, et rien n’a changé. - Les visiteurs voient un contenu périmé après un déploiement, car le serveur continue de répondre 304 : ses validateurs n’ont pas changé, par exemple un
ETagcalculé à partir de la taille et de la date de modification du fichier, que le déploiement a conservées. Assurez-vous que les validateurs changent chaque fois que le contenu change.