Pourquoi Google insiste-t-il sur l'implémentation du header If-Modified-Since ?

Qu'est-ce que le header If-Modified-Since et la réponse 304 ?

Le header If-Modified-Since permet au crawler de demander au serveur si une page a été modifiée depuis sa dernière visite. Si rien n'a changé, le serveur renvoie une réponse 304 Not Modified au lieu de retransmettre tout le contenu.

Concrètement, cela signifie que Googlebot ne télécharge pas inutilement des pages identiques à chaque passage. Le gain est double : moins de bande passante consommée, et des ressources serveur préservées pour d'autres tâches.

Pourquoi Google pousse-t-il cette recommandation maintenant ?

Gary Illyes souligne que cette fonctionnalité est sous-utilisée. Beaucoup de serveurs ne gèrent pas correctement ce mécanisme, ce qui oblige Googlebot à re-télécharger des pages qui n'ont pas bougé.

Pour Google, c'est du temps et de la bande passante gaspillés. Pour le site, c'est du crawl budget brûlé sur des requêtes inutiles — au détriment de pages qui mériteraient vraiment d'être crawlées.

Quel est l'impact sur le crawl budget ?

Si votre serveur ne renvoie jamais de 304, Googlebot doit systématiquement télécharger l'intégralité de chaque page visitée. Sur un site moyen ou gros, cela représente une charge serveur importante et un crawl budget mal optimisé.

À l'inverse, une implémentation propre du 304 permet de concentrer le crawl sur les pages réellement modifiées ou nouvelles. C'est particulièrement crucial pour les sites avec des milliers d'URLs peu changeantes.

• If-Modified-Since : header envoyé par Googlebot pour demander si la page a changé
• 304 Not Modified : réponse serveur indiquant qu'aucune modification n'a eu lieu
• Économise bande passante, charge serveur, et optimise le crawl budget
• Sous-utilisé : beaucoup de serveurs ne l'implémentent pas correctement
• Permet de concentrer le crawl sur les pages qui évoluent réellement

Cette recommandation change-t-elle vraiment la donne ?

Soyons honnêtes : le mécanisme 304 existe depuis des années. Ce n'est pas une nouveauté technique. Que Gary Illyes le mette en avant maintenant suggère que Google veut réduire sa facture de crawl — et que trop de sites ne jouent pas le jeu.

Ce qui est intéressant, c'est que Google ne dit pas « on va pénaliser les sites qui n'utilisent pas le 304 ». L'approche reste incitative : économisez vos ressources, on économisera les nôtres. Mais derrière, il y a une question de priorité de crawl. Si votre serveur facilite le travail de Googlebot, il reviendra probablement plus souvent sur les pages importantes.

Dans quels cas cette implémentation n'a-t-elle aucun intérêt ?

Petit site avec 50 pages qui changent souvent ? Le gain sera marginal. Sites d'actualité où tout bouge en permanence ? Même constat. En revanche, les sites e-commerce avec des milliers de fiches produits stables, les annuaires, les blogs avec archives — là, c'est du concret.

Il faut aussi que votre serveur gère correctement les dates de modification. Si votre CMS met à jour le champ Last-Modified à chaque requête sans raison, le 304 ne servira jamais. [À vérifier] : certains setups Apache ou Nginx mal configurés renvoient systématiquement un 200 même si rien n'a changé.

Quelle est la limite de cette approche ?

Le 304 fonctionne sur la base du Last-Modified ou de l'ETag. Si votre CMS ne gère pas proprement ces valeurs, vous ne pourrez pas en tirer parti. Et c'est là que ça coince souvent : WordPress par défaut peut générer des ETags incohérents, certains CDN les désactivent.

Comment vérifier si mon site gère correctement le 304 ?

Premier réflexe : consulter vos logs serveur. Cherchez les réponses 304 dans les requêtes de Googlebot. Si vous n'en voyez jamais, c'est mauvais signe.

Ensuite, testez manuellement avec curl ou un outil comme Screaming Frog en mode crawl personnalisé. Envoyez un header If-Modified-Since avec une date antérieure et vérifiez que le serveur renvoie bien un 304 si la page n'a pas bougé.

Quelles erreurs éviter lors de l'implémentation ?

Erreur classique : configurer le 304 mais oublier de définir correctement le Last-Modified. Si votre CMS régénère cette valeur à chaque requête, le mécanisme ne fonctionnera jamais.

Autre piège : les CDN qui désactivent les ETags ou modifient les headers de cache. Vérifiez la chaîne complète — origine, CDN, pare-feu — pour être sûr que le 304 passe bien jusqu'à Googlebot.

Que faut-il faire concrètement ?

• Vérifier que votre serveur renvoie un Last-Modified cohérent sur chaque page
• Tester avec curl ou un crawler que le 304 fonctionne bien en envoyant If-Modified-Since
• Analyser les logs serveur pour traquer les réponses 304 envoyées à Googlebot
• Configurer votre CMS pour qu'il ne régénère pas Last-Modified sans raison
• Vérifier que votre CDN ou votre proxy ne bloque pas les headers de cache
• Monitorer l'évolution du crawl budget avant/après implémentation dans la Search Console