Max-age écrase-t-il vraiment Expires dans la gestion du cache HTTP ?

Pourquoi Google précise-t-il cette hiérarchie entre max-age et Expires ?

Les deux en-têtes existent pour dire aux navigateurs et aux CDN combien de temps ils peuvent garder une ressource en cache. Expires utilise une date/heure absolue ("Expires: Thu, 01 Dec 2025 16:00:00 GMT"), tandis que max-age compte en secondes à partir du moment où la réponse est servie ("Cache-Control: max-age=3600"). Quand les deux cohabitent, c'est le bazar : quelle directive respecter ?

Google tranche net. Max-age gagne à tous les coups. Peu importe ce que dit Expires, si max-age est présent, c'est lui qui fixe la durée. Cette priorité simplifie la vie des crawlers et des navigateurs, mais elle crée aussi des pièges pour qui ne vérifie pas ses headers.

Qu'est-ce que ça change pour le crawl et l'indexation ?

Googlebot respecte les directives de cache comme n'importe quel client HTTP moderne. Si max-age dit "garde ça 7 jours", le bot ne repassera probablement pas avant. Si tu as laissé traîner un Expires obsolète avec un max-age court, c'est max-age qui compte : pas de surprise.

Le problème survient quand tu crois jouer sur Expires alors que max-age annule tout. Tu penses avoir forcé une expiration longue, mais un max-age=0 caché dans ta config Apache ou Nginx efface ta directive. Résultat : pages recrawlées trop souvent, serveur saturé, ou pire, contenu pas assez frais parce que tu pensais Expires actif.

Cette règle s'applique-t-elle à tous les types de ressources ?

Oui. HTML, CSS, JS, images, PDF : peu importe. Dès qu'un en-tête Cache-Control avec max-age est présent, Expires devient un figurant. Les CDN modernes (Cloudflare, Fastly, Akamai) appliquent la même logique : ils lisent max-age en priorité.

Attention aux configurations héritées qui mélangent les deux sans raison valable. Certains CMS anciens génèrent Expires par défaut, et un plugin ou un vhost rajoute max-age par-dessus. Le risque ? Croire que tu contrôles le cache via Expires alors que c'est max-age qui pilote, avec des valeurs que tu ignores.

• Max-age écrase toujours Expires quand les deux sont présents dans la réponse HTTP.
• La durée se compte en secondes depuis la réponse, pas en date fixe comme Expires.
• Les crawlers, navigateurs et CDN appliquent cette priorité sans exception.
• Les configs serveur (Apache, Nginx, IIS) peuvent injecter max-age sans que tu le voies dans ton code applicatif.
• Vérifier les headers réels avec curl ou les DevTools est indispensable pour éviter les surprises.

Cette déclaration est-elle cohérence avec ce qu'on observe sur le terrain ?

Totalement. Les tests sur des milliers de sites montrent que max-age prime systématiquement. Les CDN et les navigateurs ne font pas d'exception : si max-age est là, Expires ne sert à rien. Google ne fait que rappeler un standard HTTP/1.1 établi depuis des années, mais beaucoup de praticiens l'ignorent encore.

Le vrai souci, c'est la confusion héritée du passé. Expires date d'HTTP/1.0, une époque où Cache-Control n'existait pas. Aujourd'hui, garder les deux dans une config est souvent un oubli, rarement un choix éclairé. Résultat : des fichiers de conf pleins de directives contradictoires que personne ne nettoie jamais.

Quelles nuances faut-il apporter à cette règle ?

La priorité de max-age ne signifie pas qu'Expires est inutile. Si tu ne spécifies aucun Cache-Control, Expires reprend la main. Dans les faits, c'est rare : la plupart des serveurs modernes injectent au moins un Cache-Control minimal, même vide.

Autre nuance : max-age peut cohabiter avec d'autres directives Cache-Control comme no-cache, must-revalidate, public, private. Ces directives modifient le comportement du cache sans annuler max-age. Par exemple, "Cache-Control: max-age=3600, must-revalidate" impose une revalidation après 3600 secondes, mais max-age reste actif. [A vérifier] : certains CDN interprètent must-revalidate différemment selon leur config propriétaire, ce qui peut créer des divergences entre le cache navigateur et le cache edge.

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

Si aucun en-tête Cache-Control n'est envoyé, Expires reprend le contrôle total. C'est le seul scénario où Expires joue vraiment son rôle. Mais dès qu'un Cache-Control apparaît, même vide ou invalide, Expires perd toute influence.

Attention aussi aux overrides applicatifs. Un service worker en JavaScript peut court-circuiter les headers HTTP et gérer le cache à sa façon. Dans ce cas, ni max-age ni Expires ne comptent : c'est le code JS qui décide. Googlebot ne traite pas toujours les service workers comme un navigateur classique, ce qui peut créer des écarts entre ce que tu vois en local et ce que le bot crawle.

Que faut-il faire concrètement pour maîtriser cette priorité ?

Commence par auditer tes headers HTTP sur toutes les typologies de ressources. Utilise curl, wget ou les DevTools Chrome pour vérifier les réponses réelles. Beaucoup de sites envoient Expires et max-age sans le savoir, parce qu'un plugin, un CDN ou une règle Apache les injecte automatiquement.

Ensuite, choisis un camp. Si tu veux un contrôle précis en secondes, mise tout sur max-age et supprime Expires de tes configs. Si tu as des contraintes legacy avec des clients HTTP/1.0 (rare aujourd'hui), garde Expires comme fallback mais sois conscient que max-age écrasera tout pour les clients modernes.

Quelles erreurs éviter dans la configuration du cache ?

Ne mélange pas des valeurs contradictoires entre max-age et Expires sans raison valable. Par exemple, un Expires dans 30 jours et un max-age=60 (1 minute) : c'est max-age qui gagne, donc tes ressources expirent en 1 minute, pas 30 jours. Ce genre de config arrive quand un CMS ancien génère Expires et qu'un CDN rajoute max-age par défaut.

Autre piège : oublier que max-age=0 désactive le cache, même si Expires dit "dans un an". Certains frameworks injectent max-age=0 sur les pages dynamiques pour forcer la fraîcheur, mais si tu pensais contrôler le cache avec Expires, tu te retrouves avec zéro mise en cache effective.

Comment vérifier que mon site respecte cette hiérarchie correctement ?

Lance un crawl complet avec Screaming Frog ou Oncrawl en activant la capture des headers HTTP. Filtre les ressources qui envoient à la fois max-age et Expires, puis compare les valeurs. Si tu trouves des incohérences, c'est le signe que ta config n'est pas sous contrôle.

Teste aussi les comportements réels : recharge une page en vidant le cache, puis recharge-la immédiatement. Vérifie dans l'onglet Network si les ressources sont servies depuis le cache (status 304 ou "from cache"). Si le comportement diffère de ce que max-age indique, creuse : peut-être qu'un service worker ou un header Vary interfère.

• Auditer les headers HTTP de toutes les ressources (HTML, CSS, JS, images) avec curl ou DevTools.
• Supprimer Expires si max-age est déjà défini, pour éviter toute confusion.
• Vérifier que max-age reflète bien la durée de cache souhaitée (en secondes).
• Contrôler les configs serveur (Apache .htaccess, Nginx vhost, CDN rules) pour repérer les injections automatiques.
• Tester le comportement réel du cache navigateur et CDN après modification.
• Documenter la stratégie de cache dans un runbook pour éviter les régressions lors des mises à jour.