Le 304 Not Modified booste-t-il vraiment votre budget de crawl ?

Qu'est-ce qu'un code 304 et pourquoi Google s'y intéresse ?

Le code HTTP 304 Not Modified est une réponse serveur indiquant qu'une ressource n'a pas changé depuis la dernière visite. Concrètement, quand Googlebot recrawle une page, il envoie un en-tête If-Modified-Since ou If-None-Match avec sa requête. Si le serveur détecte que la ressource est identique, il répond 304 au lieu de 200, sans renvoyer tout le contenu.

Cette mécanique permet de réduire la bande passante consommée et d'accélérer les échanges. Pour Google, c'est une façon d'optimiser son infrastructure : moins de données à transférer, moins de temps passé à parser du contenu déjà connu. Pour vous, c'est un levier pour libérer du budget de crawl et orienter Googlebot vers vos pages nouvelles ou modifiées.

Pourquoi ce mécanisme est-il critique sur les gros sites ?

Un site avec des milliers de pages voit Googlebot allouer un budget de crawl limité. Si la majorité des URLs retournent du 200 avec du contenu inchangé, Google gaspille ses ressources sur des pages déjà indexées et stables. Sur un e-commerce de 50 000 références, cela peut signifier que vos nouvelles fiches produits restent invisibles pendant des jours.

En configurant correctement vos en-têtes de cache (Last-Modified, ETag), vous signalez à Google quelles pages ont changé et lesquelles sont identiques. Résultat : Googlebot peut crawler davantage de pages fraîches dans le même laps de temps. C'est particulièrement efficace sur les contenus éditoriaux, les fiches produits ou les pages paginées.

Comment Google gère-t-il concrètement les 304 ?

Googlebot stocke les métadonnées de cache (dates de dernière modification, ETag) lors de ses passages. Lors d'un recrawl, il envoie ces infos dans les en-têtes de requête. Si le serveur répond 304, Google considère que le contenu reste valide et n'a pas besoin d'être retraité. Le gain est double : moins de bande passante, moins de charge serveur.

Soyons honnêtes : tous les CMS ne configurent pas ces en-têtes par défaut. WordPress, par exemple, nécessite souvent des plugins ou des ajustements .htaccess. Les plateformes e-commerce custom peuvent avoir des configurations serveur complexes. Si vos pages retournent systématiquement 200 alors qu'elles n'ont pas bougé, vous surconsommez du budget de crawl pour rien.

• Le 304 ne remplace pas le crawl : Googlebot visite quand même l'URL, mais ne retélécharge pas le contenu entier.
• Il faut des en-têtes de cache corrects : Last-Modified, ETag, ou Cache-Control avec validateurs conditionnels.
• Les bénéfices sont proportionnels au volume : un blog de 50 pages ne verra pas de différence notable, un site de 100 000 pages oui.
• Ne forcez pas de 304 sur des pages qui changent régulièrement : si votre home est dynamique, un 304 empêchera Google de voir les mises à jour.
• Surveillez vos logs serveur : la proportion de 304 vs 200 pour Googlebot est un KPI d'efficacité de crawl.

Cette déclaration reflète-t-elle vraiment ce qu'on observe sur le terrain ?

Oui, et c'est l'une des rares affirmations Google vérifiables empiriquement. En analysant les logs serveur, on constate que Googlebot envoie bien des en-têtes If-Modified-Since et If-None-Match, et qu'il accepte les 304 sans redownloader le contenu. Les sites qui ont mis en place une stratégie de cache agressive voient effectivement une hausse du nombre de pages crawlées par jour.

Le problème, c'est que Google ne donne aucun ordre de grandeur chiffré. Combien de budget de crawl économise-t-on exactement avec 30 % de 304 au lieu de 100 % de 200 ? Aucune donnée publique. On doit se contenter d'observations indirectes : taux de crawl dans Search Console, délai d'indexation des nouveautés. [A vérifier] : Google ne fournit pas de métrique directe pour mesurer l'impact réel du 304 sur le budget de crawl dans Search Console.

Quelles nuances faut-il apporter à cette affirmation ?

Le 304 n'est pas une solution miracle. Si votre site a des problèmes structurels (arborescence chaotique, pages orphelines, facettes non canonicalisées), optimiser le cache ne changera rien à votre indexabilité. Googlebot peut économiser du crawl sur du contenu stable, mais si ce qu'il découvre ensuite est du duplicate ou du thin content, vous n'avancerez pas.

Autre point : les 304 ne concernent que le contenu HTML et certaines ressources. Les APIs, les flux JSON, les images lazy-loaded peuvent avoir des logiques de cache différentes. Si votre site repose sur du JavaScript côté client pour afficher le contenu, les 304 sur le HTML initial ne servent à rien si Googlebot doit quand même exécuter le JS pour découvrir vos liens et textes.

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

Les sites à faible volumétrie (moins de 1 000 pages) n'ont généralement pas de contrainte de budget de crawl. Googlebot peut crawler l'ensemble du site plusieurs fois par jour sans souci. Optimiser les 304 ne vous apportera rien de mesurable. Concentrez-vous sur la qualité du contenu et le maillage interne.

De même, si votre contenu change très fréquemment (flux d'actualité, cotations financières, résultats sportifs en direct), forcer des 304 serait contre-productif. Google doit voir les mises à jour en temps réel. Dans ce cas, configurez plutôt des sitemaps XML avec changefreq élevé et des IndexNow pings si vous êtes sur Bing.

Comment vérifier que votre site renvoie correctement des 304 à Googlebot ?

Première étape : analysez vos logs serveur. Filtrez les requêtes de Googlebot (user-agent compatible Googlebot) et comparez les codes de statut HTTP. Si vous avez 100 % de 200 et 0 % de 304, c'est que vos en-têtes de cache ne sont pas configurés ou que Googlebot ne les envoie pas (ce qui arrive sur les nouvelles URLs qu'il découvre).

Utilisez un outil comme Screaming Frog en mode crawl avec simulation Googlebot et en-têtes conditionnels activés. Ou testez manuellement avec curl : faites une première requête GET, notez le Last-Modified ou ETag, puis refaites une requête avec If-Modified-Since ou If-None-Match. Si le serveur répond 304, c'est bon. Si vous recevez 200 avec tout le contenu, vous avez un problème de config.

Quelles erreurs éviter lors de la mise en place ?

Ne configurez jamais des Last-Modified statiques sur des contenus qui évoluent. Certains CMS ou frameworks génèrent des dates de modification basées sur le déploiement du site, pas sur la vraie date d'édition du contenu. Résultat : Google croit que vos pages n'ont pas bougé alors qu'elles ont été mises à jour.

Évitez aussi de forcer des ETag génériques (basés uniquement sur l'inode ou la taille fichier) si votre contenu change sans modifier ces attributs. Un article dont vous modifiez juste un paragraphe peut garder la même taille en octets, et donc le même ETag. Google ne verra pas la mise à jour. Préférez des ETag basés sur un hash MD5 du contenu réel ou sur un timestamp de dernière édition en base de données.

Que faut-il faire concrètement pour optimiser le crawl avec les 304 ?

Configurez vos en-têtes HTTP pour inclure Last-Modified sur toutes les pages éditorialisées (articles, fiches produits, pages catégories). Si vous êtes sur Apache, un .htaccess avec FileETag ou des règles mod_headers suffit. Sur Nginx, utilisez les directives add_header Last-Modified et etag on. Sur WordPress, des plugins comme WP Rocket ou W3 Total Cache gèrent cela automatiquement.

Côté CMS, assurez-vous que les dates de modification en base de données sont correctement mises à jour lors des éditions de contenu. Ne vous contentez pas d'un champ created_at : ayez un updated_at réel. Si vous faites des imports massifs ou des migrations, vérifiez que les timestamps ne sont pas écrasés par la date d'import.

• Activez Last-Modified et ETag sur toutes les pages HTML indexables
• Testez avec curl et If-Modified-Since pour vérifier les réponses 304
• Surveillez le ratio 304/200 dans vos logs serveur pour Googlebot
• Comparez le taux de crawl avant/après dans Search Console (section Statistiques sur l'exploration)
• Ne forcez pas de 304 sur les pages à fort taux de mise à jour (home, pages actus en temps réel)
• Documentez votre stratégie de cache et formez vos équipes dev pour éviter les régressions lors des déploiements