Pourquoi un code 304 Not Modified peut-il bloquer l'indexation de vos pages ?

Qu'est-ce qu'une requête conditionnelle et comment fonctionne le code 304 ?

Une requête conditionnelle contient des headers spécifiques comme If-Modified-Since ou If-None-Match. Le navigateur ou le bot demande au serveur : "J'ai une version datant du 15 janvier, y a-t-il du nouveau ?" Si rien n'a changé, le serveur répond 304 et économise de la bande passante en ne renvoyant pas le corps de la réponse.

Le 304 est donc un mécanisme d'optimisation, pas un code d'erreur. Il suppose qu'une version valide existe déjà côté client. C'est la raison pour laquelle Google insiste sur le contexte : ce code ne fait sens que lorsqu'une condition est posée explicitement.

Que se passe-t-il si on retourne un 304 sur une requête normale ?

Pour une requête sans header conditionnel, un 304 devient problématique. Le bot ne possède aucune version en cache, il attend du contenu. En recevant un 304, Googlebot interprète cela comme "aucun contenu disponible" et ne peut donc pas indexer la page.

Concrètement ? Votre page disparaît de l'index. C'est particulièrement vicieux parce que le serveur ne renvoie pas d'erreur flagrante — juste une réponse vide techniquement valide mais sémantiquement fausse dans ce contexte.

Pourquoi cette erreur survient-elle fréquemment avec les sitemaps ?

Les sitemaps XML sont des fichiers régulièrement crawlés mais rarement modifiés. Certains développeurs mettent en place un mécanisme de cache agressif qui retourne systématiquement un 304, même sans requête conditionnelle, dans l'idée d'économiser des ressources.

Le problème : Googlebot qui découvre le sitemap pour la première fois ou après un vidage de cache reçoit un 304 aveugle. Résultat, impossible de lire les URLs listées. Mueller suggère plusieurs alternatives selon le cas : un fichier XML vide valide, un 404 si le sitemap n'existe plus, ou un 304 uniquement si une requête conditionnelle est détectée.

• Le code 304 est réservé aux requêtes conditionnelles avec headers If-Modified-Since ou If-None-Match
• Un 304 sur requête normale signale l'absence de contenu et bloque l'indexation
• Les sitemaps mal configurés sont une source fréquente de cette erreur
• Les alternatives correctes : fichier vide, 404, ou 304 conditionnel uniquement
• Vérifier la logique serveur pour s'assurer que le 304 n'est jamais retourné aveuglément

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument. Les cas de désindexation mystérieuse liés à des 304 mal configurés ne sont pas rares, surtout sur des CMS custom ou des plateformes e-commerce avec cache Varnish/Nginx mal paramétré. L'erreur classique : un dev met en place un cache HTTP sans distinguer les requêtes initiales des requêtes de validation.

Les logs serveur montrent alors des 304 systématiques pour Googlebot, qui ne possède pourtant aucune version en cache. La Search Console affiche "Explorée, actuellement non indexée" sans autre explication, et il faut plonger dans les headers pour comprendre. C'est un bug silencieux qui peut persister des mois.

Dans quels cas cette règle ne s'applique-t-elle pas ou devient-elle floue ?

Mueller reste vague sur les scénarios de CDN et de reverse proxy. Certains CDN retournent des 304 basés sur leur propre état de cache, indépendamment du header conditionnel initial. Est-ce que Googlebot tolère cette situation si le CDN a déjà servi le contenu auparavant ? [A verifier]

Autre zone grise : les ressources statiques (CSS, JS, images). Google ne détaille pas si la règle s'applique aussi strictement. En pratique, les ressources statiques avec 304 aveugle posent moins de problèmes d'indexation directs, mais peuvent affecter le rendering si Googlebot ne parvient pas à charger un CSS critique. Le discours officiel manque de granularité sur ce point.

Faut-il bannir complètement le 304 des sitemaps ?

Non, ce serait une sur-réaction. Le 304 conditionnel sur un sitemap est parfaitement légitime et économise du crawl budget quand il est bien implémenté. Le piège est dans l'implémentation : beaucoup de frameworks retournent un 304 par défaut sans vérifier la présence du header If-Modified-Since.

La recommandation de Mueller sur le fichier vide est pragmatique pour les sitemaps temporairement vides (nouvelle section du site pas encore indexée, par exemple). Un fichier XML valide avec sans URL indique clairement "rien à crawler pour le moment" sans ambiguïté. C'est plus propre qu'un 404 qui pourrait signaler une erreur de configuration.

Comment vérifier que votre serveur ne retourne pas de 304 aveugle ?

Testez vos URLs et sitemaps avec curl ou Postman en émulant Googlebot. Faites une requête sans header conditionnel : curl -I -A "Googlebot" https://example.com/sitemap.xml. Si vous obtenez un 304, c'est un problème flagrant.

Ensuite, testez avec un header conditionnel : curl -I -H "If-Modified-Since: Mon, 01 Jan 2024 00:00:00 GMT" https://example.com/sitemap.xml. Là, un 304 est attendu si le fichier n'a pas changé depuis cette date. La différence de comportement entre les deux requêtes doit être nette.

Quelles configurations serveur faut-il auditer en priorité ?

Les reverse proxy comme Varnish ou Nginx sont les premiers suspects. Vérifiez la logique de cache : le 304 doit être conditionné à la présence d'un header de validation, pas à l'existence d'une entrée en cache côté serveur.

Côté applicatif, les frameworks PHP (Symfony, Laravel) et Node.js (Express) ont souvent des middlewares de cache HTTP. Assurez-vous qu'ils ne retournent un 304 que si req.headers['if-modified-since'] ou if-none-match est présent et correspond à la version actuelle. Un flag booléen "isCached" ne suffit pas.

Que faire si vous découvrez un 304 aveugle sur des pages indexées ?

Corrigez la configuration immédiatement et forcez un recrawl via Search Console pour les URLs critiques. Pour un sitemap, soumettez-le à nouveau une fois la correction déployée. Les pages déjà désindexées peuvent mettre plusieurs semaines à revenir selon le crawl budget du site.

Surveillez la couverture d'index dans Search Console pendant les semaines suivantes. Une chute brutale de pages indexées coïncidant avec un déploiement cache est un signal d'alerte. Les logs serveur doivent montrer une distribution normale de codes 200/304, pas un 304 systématique.

• Tester chaque URL critique avec curl sans header conditionnel et vérifier l'absence de 304
• Auditer la configuration Varnish/Nginx/CDN pour conditionner le 304 aux headers de validation
• Vérifier que les middlewares applicatifs vérifient explicitement If-Modified-Since ou If-None-Match
• Mettre en place une alerte monitoring sur le ratio 304/200 par type de bot (Googlebot vs utilisateurs)
• Documenter la logique de cache HTTP pour éviter les régressions lors des mises à jour
• Pour les sitemaps vides, privilégier un fichier XML valide vide plutôt qu'un 404 ou 304