304 Not Modified : requêtes conditionnelles et efficacité du crawl

304 Not Modified est la façon dont le serveur dit « vous avez déjà la dernière version ». Il n’apparaît qu’en réponse à une requête conditionnelle et n’a pas de corps, ce qui économise de la bande passante aux navigateurs, aux CDN et aux robots.

Comment fonctionnent les requêtes conditionnelles

La RFC 9110, section 15.4.5 définit le 304 comme la réponse à un GET ou HEAD conditionnel qui aurait renvoyé 200 OK si la condition ne s’était pas évaluée à faux. Le client construit cette condition à partir de validateurs que le serveur lui a envoyés auparavant :

• ETag : le client envoie ensuite If-None-Match avec cette valeur.
• Last-Modified : le client envoie ensuite If-Modified-Since avec cette date.

Si le validateur correspond toujours, le serveur renvoie un 304 avec les seuls en-têtes. Il doit y inclure ceux qu’un 200 aurait portés parmi ETag, Date, Vary, Content-Location, Cache-Control et Expires. Quand une requête contient les deux conditions, If-None-Match l’emporte et If-Modified-Since est ignoré.

Pourquoi le 304 compte pour le SEO

La documentation de Google sur les codes de statut HTTP précise qu’un 304 indique au processus d’indexation que le contenu est le même qu’au dernier crawl. Google peut recalculer les signaux de l’URL, mais ce code n’a sinon aucun effet sur l’indexation. Autrement dit, il est sans risque, et il est efficace. Les robots de Google prennent en charge la validation par ETag comme par Last-Modified, et Google a recommandé ETag comme le moins sujet aux erreurs des deux.

L’avantage est l’efficacité du crawl. Un 304 ne coûte presque rien à votre serveur, si bien que Googlebot peut vérifier davantage d’URL avec les mêmes ressources. Sur les grands sites comptant beaucoup de pages inchangées, cela permet de découvrir plus vite les pages qui ont changé.

Où le 304 se dérègle

• Validateurs périmés. Si l’ETag est calculé à partir d’une donnée qui ne change pas quand le contenu change, comme la version d’un modèle de page, le serveur continue de répondre 304 après la mise à jour de la page, et les caches gardent l’ancienne copie.
• Last-Modified non mis à jour quand des commentaires, des prix ou des liens associés modifient le HTML.
• 304 envoyé à des requêtes non conditionnelles. Une couche de cache défaillante qui envoie un 304 à un client qui n’a rien demandé de conditionnel le laisse sans rien à afficher.
• ETag modifiés par la compression. Certains serveurs modifient ou affaiblissent les ETag lorsqu’ils compressent les réponses, si bien que le If-None-Match suivant ne correspond jamais.
• ETag différents d’un serveur à l’autre derrière un répartiteur de charge, de sorte que des requêtes successives correspondent rarement.

Comment l’activer et le tester

Apache et Nginx ajoutent généralement les validateurs aux fichiers statiques de façon automatique (etag on; est la valeur par défaut de Nginx). Le HTML dynamique en manque souvent ; un cache de pages, un CDN ou le middleware de réponses conditionnelles de votre framework peut les ajouter. Une version simplifiée en PHP :

$etag = '"' . md5($html) . '"';
header('ETag: ' . $etag);
if (trim($_SERVER['HTTP_IF_NONE_MATCH'] ?? '') === $etag) {
    http_response_code(304);
    exit;
}
echo $html;

Commencez par vérifier avec le vérificateur d’en-têtes HTTP que la page envoie un en-tête ETag ou Last-Modified. Rejouez ensuite le validateur avec curl et attendez-vous à un 304 :

curl -I https://www.example.com/guide/ \
  -H 'If-None-Match: "6a1f-5e2c"'

HTTP/2 304
etag: "6a1f-5e2c"
cache-control: public, max-age=600
date: Fri, 30 Oct 2026 08:00:00 GMT

Le test de vitesse de page examine lui aussi vos en-têtes de cache.

Questions fréquentes