Le code 304 Not Modified est-il vraiment un piège pour votre indexation ?

Pourquoi le code 304 pose-t-il problème sur une requête normale ?

Une requête conditionnelle signale au serveur : "Je possède déjà une version de cette ressource datée du X, envoie-moi le contenu seulement si tu as une version plus récente." Cette logique repose sur les en-têtes HTTP If-Modified-Since ou If-None-Match. Quand le serveur répond 304, il dit : "Ta version est à jour, pas besoin de retélécharger."

Sur une requête normale — sans en-tête conditionnel — le serveur ne peut pas supposer que le client possède déjà le contenu. Retourner un 304 dans ce cas équivaut à dire "Rien n'a changé" alors que le crawler n'a jamais eu accès à la version de référence. Résultat : Googlebot ne reçoit aucun HTML, ne peut pas analyser le contenu, et la page reste non indexée ou disparaît de l'index si elle y était déjà.

Les sitemaps XML font-ils exception à cette règle ?

Oui — et c'est l'un des points les plus pragmatiques de cette déclaration. Pour les sitemaps XML, Google accepte trois comportements quand aucune mise à jour n'a eu lieu : renvoyer un 304 (sur requête conditionnelle valide), retourner un 404, ou servir un fichier vide. Toutes ces réponses indiquent à Googlebot qu'il n'y a rien de neuf à crawler.

Cette souplesse s'explique par la nature du sitemap : c'est un fichier de coordination, pas une page de contenu. Google ne cherche pas à indexer le sitemap lui-même, mais à identifier les URLs à explorer. Si le sitemap n'a pas changé, inutile de le retransmettre — un signal suffit.

Comment distinguer une requête conditionnelle d'une requête normale ?

Côté serveur, la présence des en-têtes If-Modified-Since ou If-None-Match dans la requête HTTP constitue le seul critère fiable. Le premier compare une date, le second un identifiant unique de version (ETag). Si l'un de ces en-têtes est absent, la requête est considérée comme normale et doit recevoir un 200 OK avec contenu complet — ou un code d'erreur approprié (404, 410, etc.).

Dans les logs serveur, une requête conditionnelle se repère facilement : la ligne contient l'en-tête concerné. Sur une plateforme CDN (Cloudflare, Fastly, Akamai), ces requêtes sont souvent gérées automatiquement si les en-têtes Last-Modified et ETag sont correctement configurés côté origine. Mais attention : certaines configurations par défaut retournent des 304 erronés sur requêtes normales — notamment sur des pages générées dynamiquement avec un cache mal paramétré.

• Un code 304 n'est légitime que si la requête inclut If-Modified-Since ou If-None-Match.
• Sur requête normale, un 304 bloque l'indexation en privant le crawler de contenu.
• Les sitemaps XML tolèrent 304, 404 ou fichier vide quand il n'y a pas de mise à jour.
• Vérifiez vos logs serveur pour repérer des 304 renvoyés à tort sur des requêtes sans en-tête conditionnel.
• Les configurations CDN par défaut ne garantissent pas toujours la conformité — auditez vos règles de cache.

Cette déclaration corrige-t-elle une pratique répandue ?

Absolument. Sur le terrain, on observe régulièrement des configurations serveur ou CDN qui retournent des 304 systématiques pour économiser la bande passante — sans vérifier si la requête est réellement conditionnelle. L'intention est louable (optimiser les performances), mais l'effet est catastrophique pour l'indexation. Googlebot, en l'absence d'en-têtes conditionnels dans ses premières requêtes vers une nouvelle URL, reçoit un 304 et conclut qu'il n'y a rien à indexer.

Cette confusion est particulièrement fréquente sur les sites e-commerce dynamiques où le cache applicatif (Varnish, Redis) est configuré pour servir des 304 dès qu'un fichier "n'a pas changé" — sans examiner la requête entrante. Résultat : des fiches produit récemment ajoutées restent invisibles dans Google pendant des semaines, jusqu'à ce qu'un crawl forcé ou une purge de cache force un 200. [A vérifier] si votre pile technique distingue correctement requêtes conditionnelles et normales.

Pourquoi Google tolère-t-il trois comportements pour les sitemaps ?

Parce que le sitemap XML n'est qu'un index de navigation — pas une ressource de contenu à part entière. Google cherche à savoir s'il y a de nouvelles URLs à explorer, pas à indexer le fichier sitemap lui-même. Retourner un 404 temporaire quand aucune modification n'a eu lieu peut sembler contre-intuitif, mais c'est une convention acceptée : "Ce sitemap n'existe pas dans sa version mise à jour, reviens plus tard."

En pratique, la plupart des CMS et générateurs de sitemap servent toujours un 200 avec le fichier complet, même si rien n'a changé. C'est la solution la plus simple et la plus fiable — aucun risque d'interprétation erronée. Mais pour les très gros sites (millions d'URLs), régénérer et servir un sitemap de plusieurs centaines de Mo à chaque requête Googlebot représente une charge serveur non négligeable. D'où l'intérêt du 304 conditionnel ou du fichier vide.

Quels signaux d'alerte indiquent un problème de 304 ?

Trois symptômes classiques : des pages récentes qui n'apparaissent pas dans l'index malgré leur présence dans le sitemap, un taux de couverture anormalement bas dans la Search Console (URLs découvertes mais non explorées), et des logs serveur montrant des séquences de 304 sur des URLs jamais crawlées auparavant. Si Googlebot n'a jamais reçu le contenu initial, il ne peut pas savoir que "rien n'a changé".

Autre indice : une configuration CDN ou cache inversé qui affiche un hit rate (taux de succès du cache) supérieur à 95 % sur des pages théoriquement nouvelles. Cela signifie souvent que le cache répond 304 par défaut, sans valider la nature de la requête. Testez vos URLs avec curl en omettant volontairement les en-têtes If-Modified-Since — si vous obtenez un 304, vous avez un problème.

Comment vérifier que votre serveur gère correctement les 304 ?

Lancez un test avec curl ou un outil de diagnostic HTTP (Postman, Insomnia) sur une URL indexable. Première requête sans en-tête conditionnel : vous devez obtenir un 200 OK avec le HTML complet. Notez la valeur de l'en-tête Last-Modified ou ETag dans la réponse. Puis rejouez la requête en ajoutant If-Modified-Since avec la date récupérée — cette fois, un 304 est attendu.

Si la première requête (sans condition) retourne un 304, votre configuration est défectueuse. Examinez vos règles Apache mod_headers, Nginx expires, ou les paramètres de votre CDN. Sur Cloudflare, par exemple, l'option "Respect Existing Headers" peut provoquer des 304 intempestifs si l'origine ne gère pas correctement les en-têtes conditionnels.

Quelles erreurs faut-il absolument éviter ?

Ne configurez jamais votre serveur pour retourner un 304 "par défaut" sur toutes les requêtes GET sans analyser les en-têtes. Certains tutoriels d'optimisation de performances recommandent des règles de cache agressives qui ne distinguent pas les types de requêtes — ignorez ces conseils. Un 304 mal placé coûte infiniment plus cher en perte de trafic organique qu'il ne fait économiser en bande passante.

Autre piège : les pages JavaScript hydratées côté client (React, Vue, Angular) dont le serveur retourne un shell HTML minimal avec un 304 pour le contenu dynamique. Si Googlebot n'obtient jamais le HTML initial complet, il ne peut pas exécuter le JS dans de bonnes conditions. Assurez-vous que la première réponse serveur contient suffisamment de contenu indexable — même si le rendu final dépend du JS.

Quelle configuration recommander pour les sitemaps XML ?

La solution la plus robuste reste de toujours servir un 200 OK avec le fichier sitemap complet, même s'il n'a pas changé. C'est simple, prévisible, et n'introduit aucun risque d'interprétation erronée. Si la charge serveur devient un problème (sitemap > 50 Mo, crawls très fréquents), implémentez un mécanisme de 304 conditionnel basé sur la date de dernière modification du fichier.

Évitez le 404 temporaire sauf si votre génération de sitemap est événementielle (déclenché uniquement après ajout/modification de contenu). Un 404 permanent sur le sitemap déclaré dans robots.txt génère des erreurs dans la Search Console et peut retarder la découverte de nouvelles URLs. Le fichier vide (0 octet avec 200 OK) fonctionne mais peut perturber certains parsers XML — servir le dernier sitemap valide reste préférable.

• Testez vos URLs avec curl sans en-tête If-Modified-Since — elles doivent renvoyer 200, jamais 304.
• Vérifiez que vos en-têtes Last-Modified et ETag sont correctement générés et cohérents.
• Auditez vos règles CDN et cache inversé pour repérer des 304 renvoyés à tort sur requêtes normales.
• Pour les sitemaps, privilégiez un 200 OK systématique sauf contrainte de charge serveur documentée.
• Surveillez les logs d'accès Googlebot pour détecter des séquences anormales de 304 sur des URLs récentes.
• Documentez votre configuration de cache dans un runbook accessible à l'équipe technique — les 304 mal configurés sont souvent introduits lors de mises à jour infrastructure.