Faut-il vraiment conserver le header Vary User-Agent pour vos sites mobiles ?

Pourquoi Google insiste-t-il encore sur ce header HTTP en particulier ?

Le header HTTP Vary User-Agent indique aux serveurs intermédiaires et aux caches qu'une URL peut renvoyer différentes versions de contenu selon le user-agent qui effectue la requête. Concrètement, cela signifie qu'un cache intelligent ne servira pas la version mobile d'une page à un utilisateur desktop et inversement.

Google utilise ce signal pour comprendre qu'un site pratique le serving dynamique, c'est-à-dire qu'il sert différents contenus HTML depuis la même URL selon l'appareil. Sans ce header, les caches intermédiaires risquent de servir la mauvaise version à vos utilisateurs, et Googlebot peut avoir plus de mal à distinguer vos contenus mobile et desktop lors du crawl.

Cette recommandation existe depuis des années, mais Google la réitère parce que beaucoup de sites négligent encore cette configuration. Le problème se pose surtout pour les architectures qui n'ont pas migré vers le responsive design pur ou vers des URL séparées pour mobile.

Dans quels cas ce header joue-t-il un rôle critique ?

La situation concerne principalement les sites pratiquant le dynamic serving, où la même URL renvoie un HTML différent selon que l'utilisateur arrive depuis mobile ou desktop. Si votre site est entièrement responsive avec un seul HTML identique pour tous les devices, ce header n'apporte aucune valeur.

Les CDN et proxies de cache s'appuient sur ce header pour décider s'ils peuvent servir une version mise en cache ou doivent interroger le serveur d'origine. Google mentionne explicitement qu'Akamai et certains autres CDN ne détectent pas toujours correctement ce header, ce qui peut créer des situations où des utilisateurs mobiles reçoivent du contenu desktop en cache.

Pour l'indexation, Googlebot utilise deux user-agents distincts (desktop et mobile). Le header Vary aide Google à comprendre qu'il doit crawler l'URL avec les deux user-agents pour obtenir les deux versions du contenu. Sans ce signal, Google pourrait ne crawler qu'une seule version et manquer des différences importantes pour l'index mobile-first.

Quelle est la différence avec les autres approches mobile ?

Google reconnaît trois configurations principales pour les sites mobiles : le responsive design (un seul HTML qui s'adapte), le dynamic serving (URLs identiques, HTML différent selon le device), et les URL séparées comme m.example.com. Le header Vary User-Agent ne concerne que le dynamic serving.

Si vous utilisez des URL séparées avec des sous-domaines mobiles dédiés, vous n'avez pas besoin de ce header puisque les versions sont physiquement distinctes. Le responsive design n'en a pas besoin non plus puisque le HTML est identique. C'est uniquement quand vous servez dynamiquement du contenu différent depuis la même URL que ce header devient indispensable.

La nuance importante : même si votre site est majoritairement responsive, certaines sections peuvent pratiquer du dynamic serving pour des raisons de performance ou de fonctionnalité. Dans ce cas, le header doit être présent sur ces URLs spécifiques.

• Le header Vary User-Agent est obligatoire uniquement pour le dynamic serving (même URL, HTML différent selon l'appareil)
• Il aide les caches à stocker et servir les bonnes versions selon le user-agent demandeur
• Google l'utilise pour savoir qu'il doit crawler une URL avec ses deux bots (mobile et desktop)
• Certains CDN comme Akamai ne le respectent pas toujours correctement, créant des risques de cache mal configuré
• Les sites responsive purs ou avec URLs séparées n'ont pas besoin de ce header

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

Soyons honnêtes : cette déclaration de Google arrive tard dans le calendrier. L'indexation mobile-first est déployée depuis plusieurs années maintenant, et la majorité des sites professionnels ont migré vers du responsive design pur. Le dynamic serving est devenu une pratique minoritaire, utilisée surtout par de gros sites legacy ou des plateformes avec des contraintes techniques spécifiques.

Le fait que Google continue de rappeler cette recommandation suggère deux choses. D'abord, qu'il reste un volume non négligible de sites en dynamic serving qui ne configurent pas correctement ce header. Ensuite, que Google observe probablement des problèmes d'indexation récurrents sur ces sites mal configurés, d'où la nécessité de réitérer les bonnes pratiques.

Ce qui est moins clair dans la déclaration, c'est l'impact réel sur le ranking. Google dit que cela "améliore l'indexation" et aide à "différencier les contenus", mais ne quantifie pas l'effet. [A vérifier] sur le terrain : les sites qui ajoutent ce header après coup constatent-ils une amélioration mesurable dans Search Console ? Les données publiques manquent.

Le problème des CDN qui ignorent ce header est-il vraiment répandu ?

Google cite explicitement Akamai comme exemple de CDN qui ne détecte pas toujours le header Vary User-Agent. C'est une affirmation technique précise qui mérite attention. Akamai étant l'un des plus gros CDN du marché, cela concerne potentiellement des millions de sites.

Concrètement, si votre CDN ignore ce header, il va mettre en cache la première version servie (mobile ou desktop) et la servir à tous les visiteurs suivants, quel que soit leur device. Résultat : des utilisateurs mobiles reçoivent du HTML desktop non responsive, et inversement. C'est un problème d'expérience utilisateur majeur qui impacte aussi les signaux comportementaux que Google mesure.

La nuance : la plupart des CDN modernes permettent de configurer manuellement les règles de cache basées sur le user-agent, même s'ils n'honorent pas le header Vary. Il faut vérifier la configuration spécifique de votre CDN plutôt que de compter uniquement sur ce header. [A vérifier] : demandez à votre fournisseur CDN comment il gère le cache par user-agent.

Quand cette recommandation peut-elle être ignorée sans risque ?

Si votre site sert exactement le même HTML à tous les devices et utilise uniquement CSS et JavaScript pour adapter l'affichage, vous n'avez absolument aucun besoin de ce header. C'est le cas de 90% des sites WordPress modernes avec des thèmes responsive récents.

De même, si vous utilisez des URLs séparées (m.example.com vs www.example.com) avec les balises rel=alternate et rel=canonical correctement configurées, le header Vary n'apporte rien. Google sait déjà qu'il s'agit de versions distinctes grâce à ces balises.

Le vrai cas d'usage aujourd'hui se limite aux sites qui ont fait le choix conscient du dynamic serving pour des raisons de performance serveur (éviter d'envoyer du HTML inutile aux mobiles) ou de fonctionnalités très différentes entre mobile et desktop. Ces sites sont minoritaires mais existent encore, notamment dans l'e-commerce à forte volumétrie ou les médias.

Comment vérifier si votre site a besoin de ce header ?

Première étape : identifiez votre architecture mobile actuelle. Ouvrez votre site sur mobile et desktop, puis examinez le code source HTML. Si le HTML est strictement identique (même balises, même contenu, seul le CSS change l'affichage), vous êtes en responsive et n'avez pas besoin du header.

Si le HTML diffère significativement entre les deux versions alors que l'URL est identique, vous pratiquez du dynamic serving et le header devient obligatoire. Pour vérifier techniquement, utilisez curl avec différents user-agents et comparez les réponses.

Vérifiez ensuite les headers HTTP actuellement envoyés par votre serveur. Dans Chrome DevTools, onglet Network, rechargez la page et examinez les Response Headers. Cherchez une ligne "Vary: User-Agent". Si elle est absente alors que vous faites du dynamic serving, c'est un problème à corriger rapidement.

Quelle est la procédure de correction selon votre stack technique ?

Sur Apache, ajoutez dans votre .htaccess ou dans la configuration du vhost : Header append Vary User-Agent. Cette directive ajoute le header à toutes les réponses HTML. Attention à ne pas l'ajouter aux ressources statiques (CSS, JS, images) où il serait inutile.

Sur Nginx, dans votre bloc server ou location, utilisez : add_header Vary User-Agent always; Le flag "always" garantit que le header est ajouté même si la réponse a un code d'erreur. Redémarrez Nginx après modification.

Pour les sites sous Cloudflare, Fastly ou autre CDN, vérifiez d'abord la configuration du CDN lui-même. Certains CDN ont des règles de cache prédéfinies basées sur le user-agent qui peuvent entrer en conflit avec votre header Vary. Consultez la documentation spécifique de votre fournisseur.

Quels indicateurs suivre après l'implémentation ?

Dans Search Console, surveillez l'évolution du nombre de pages indexées dans les rapports de couverture. Si Google crawle désormais correctement vos deux versions, vous devriez voir une stabilisation ou une légère augmentation des URLs indexées. Vérifiez aussi les rapports d'erreurs pour détecter d'éventuels problèmes de compatibilité mobile.

Côté analytics, examinez le taux de rebond et le temps sur site segmentés par type de device. Si des utilisateurs mobiles recevaient auparavant du contenu desktop en cache, vous devriez constater une amélioration des métriques d'engagement après correction. C'est un signal indirect que le header fait son travail.

Surveillez aussi vos Core Web Vitals dans la Search Console. Un cache mal configuré peut forcer des utilisateurs à charger des ressources inadaptées à leur device, dégradant les performances. L'amélioration du cache via le header Vary peut avoir un effet positif mesurable sur le LCP et le CLS mobiles.

• Auditez votre architecture mobile actuelle (responsive, dynamic serving ou URLs séparées)
• Vérifiez la présence du header Vary User-Agent dans les Response Headers avec DevTools
• Testez votre site avec curl et différents user-agents pour confirmer les variations de contenu
• Ajoutez le header dans votre configuration serveur (Apache, Nginx) si nécessaire
• Vérifiez la configuration de votre CDN et ses règles de cache par user-agent
• Surveillez Search Console pendant 2-4 semaines pour mesurer l'impact sur l'indexation