Pourquoi l'en-tête Vary est-elle indispensable quand vous servez du contenu différencié par user-agent ?

Qu'est-ce que l'en-tête Vary et pourquoi Google s'en préoccupe-t-il ?

L'en-tête HTTP Vary indique aux caches et aux bots quels critères de requête influencent le contenu servi. Quand vous renvoyez Vary: User-Agent, vous signalez que la même URL peut produire des réponses différentes selon le navigateur ou l'appareil qui la demande.

Pour Googlebot, c'est un signal critique : le bot comprend qu'il doit crawler cette URL avec plusieurs user-agents (desktop, mobile) pour capturer toutes les variations. Sans cet en-tête, Google risque de mettre en cache une seule version et de ne jamais découvrir que votre site sert du contenu différent aux mobiles.

Dans quels cas cette configuration s'applique-t-elle encore ?

Cette directive vise les sites utilisant la détection côté serveur de l'agent utilisateur pour servir des versions HTML différentes sur la même URL. C'était courant avant l'ère du responsive design : un desktop recevait une structure, un mobile une autre, sans redirection vers un sous-domaine dédié.

Aujourd'hui, la plupart des sites modernes utilisent le responsive design (même HTML, CSS adaptatif) ou des URL distinctes (m.example.com). Dans ces deux cas, Vary: User-Agent n'est pas nécessaire. Mais si votre infrastructure backend génère dynamiquement du HTML différent selon le user-agent, cette règle reste d'actualité.

Que se passe-t-il si vous omettez cet en-tête ?

Sans Vary: User-Agent, Googlebot peut cacher une seule version de votre page et supposer qu'elle est identique pour tous les devices. Résultat : votre version mobile peut ne jamais être crawlée correctement, ou votre contenu desktop peut être indexé comme version mobile (et inversement).

Google peut aussi crawler moins fréquemment vos pages, considérant que le contenu est statique. Le crawl budget est mal alloué, et certaines variations stratégiques (contenu enrichi pour mobile, fonctionnalités spécifiques desktop) restent invisibles aux yeux du moteur.

• Vary: User-Agent signale explicitement que la même URL sert du contenu différent selon le device.
• Cette directive concerne uniquement les sites avec détection côté serveur, pas le responsive design pur.
• L'absence de cet en-tête peut causer des problèmes d'indexation mobile et un gaspillage de crawl budget.
• Les sites modernes en responsive ou avec URLs distinctes (m.example.com) n'ont pas besoin de Vary.
• Google peut mettre en cache la mauvaise version de votre page si l'en-tête manque.

Cette recommandation est-elle encore pertinente avec le mobile-first indexing ?

Depuis le passage au mobile-first indexing, Googlebot crawle prioritairement avec un user-agent mobile. Si votre site détecte l'agent et sert une version mobile allégée, l'absence de Vary pourrait théoriquement poser moins de problèmes qu'avant. Mais attention : Google continue de crawler occasionnellement avec un user-agent desktop pour vérifier la cohérence.

Si vous servez du contenu substantiellement différent entre mobile et desktop sans Vary, vous créez une incohérence détectable. Google peut suspecter du cloaking ou simplement mal interpréter votre architecture. [A vérifier] dans quelle mesure Google pénalise activement l'absence de Vary, mais les retours terrain montrent des crawls moins efficaces et des versions mixées dans l'index.

Quels sites devraient vraiment s'inquiéter de cette directive ?

Soyons honnêtes : la majorité des sites lancés après 2015 utilisent le responsive design et n'ont jamais eu à toucher à Vary. Cette directive concerne surtout les infrastructures legacy (e-commerce historiques, plateformes custom, sites d'actualité complexes) qui ont gardé une logique de détection côté serveur pour des raisons de performance ou de personnalisation avancée.

Si vous générez dynamiquement du HTML différent selon le user-agent (pas juste du CSS différent, mais bien du markup distinct), vous êtes concerné. Les sites AMP avec canonical vers des URLs non-AMP qui détectent l'agent doivent aussi surveiller ce point. En revanche, si votre backend envoie le même HTML à tout le monde et que seul le CSS change, vous pouvez ignorer cette recommandation.

Quelles erreurs fréquentes observe-t-on sur le terrain ?

L'erreur classique : un site ajoute Vary: User-Agent alors qu'il fait du responsive pur. Résultat : les caches intermédiaires (CDN, proxies) stockent des copies multiples inutiles de la même page, ce qui dégrade les performances sans bénéfice. C'est un overhead technique injustifié.

L'inverse est pire : un site sert du contenu réellement différent mais oublie l'en-tête. Google crawle la version desktop, la met en cache, et ignore la version mobile pendant des semaines. Le mobile-first indexing se base alors sur une version inadaptée. Les audits techniques manquent souvent ce point parce que les outils testent rarement les headers HTTP avec plusieurs user-agents.

Comment vérifier si votre site a besoin de Vary: User-Agent ?

Première étape : testez votre site avec différents user-agents et comparez le HTML source brut (pas le rendu visuel). Utilisez curl avec un user-agent desktop puis mobile : curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" https://votresite.com et curl -A "Mozilla/5.0 (iPhone; CPU iPhone OS 14_0 like Mac OS X)" https://votresite.com.

Si le HTML retourné est strictement identique (hors éventuels timestamps dynamiques), vous n'avez pas besoin de Vary. Si des sections entières changent (structure, balises, contenu), vous devez implémenter l'en-tête. Ne vous fiez pas au rendu visuel : le responsive CSS peut masquer des différences qui n'existent que côté présentation.

Comment implémenter correctement l'en-tête Vary ?

Côté serveur, ajoutez Vary: User-Agent dans les headers de réponse HTTP. En Apache, utilisez Header set Vary "User-Agent" dans votre .htaccess ou votre vhost. En Nginx : add_header Vary User-Agent;. En PHP : header('Vary: User-Agent');.

Attention aux multiples valeurs Vary : si votre site varie aussi selon Accept-Encoding ou Cookie, combinez-les : Vary: User-Agent, Accept-Encoding. Ne surchargez pas Vary avec des critères non pertinents : chaque valeur ajoutée multiplie les versions mises en cache. Testez avec les DevTools de Chrome (onglet Network, inspectez les Response Headers) pour confirmer que l'en-tête est bien présent sur toutes les pages concernées.

Quels sont les pièges à éviter lors de la mise en œuvre ?

Ne confondez pas détection user-agent côté serveur et feature detection côté client. Si votre JavaScript adapte le contenu après le chargement initial, le HTML source reste identique et Vary n'est pas nécessaire. Le piège : certains frameworks (Next.js, Nuxt) font du SSR conditionnel qui peut changer le markup selon le user-agent. Dans ce cas, Vary est indispensable.

Autre erreur : ajouter Vary sans réellement servir du contenu différent, juste par précaution. Vous fragmentez inutilement vos caches et ralentissez le site. Inversement, ne supprimez pas Vary si votre backend détecte l'agent, même si vous pensez migrer vers du responsive "bientôt". Le temps que la migration soit terminée, vous aurez accumulé des problèmes d'indexation.

• Testez le HTML source avec curl et plusieurs user-agents pour confirmer les différences réelles.
• Ajoutez Vary: User-Agent uniquement si le markup HTML change selon l'agent.
• Vérifiez que votre CDN respecte l'en-tête Vary et ne l'ignore pas dans sa config de cache.
• Combinez Vary avec d'autres critères pertinents (Accept-Encoding) sans surcharger l'en-tête.
• Auditez régulièrement vos headers HTTP avec les DevTools pour confirmer la présence de Vary.
• Documentez cette configuration dans votre documentation technique pour éviter les régressions lors des mises à jour.