L'en-tête HTTP Vary est-il vraiment inutile pour le SEO mobile ?

Qu'est-ce que l'en-tête HTTP Vary et à quoi sert-il ?

L'en-tête HTTP Vary informe les navigateurs et les proxies que le contenu d'une URL peut varier selon certains critères. Pour le SEO, on parle principalement du Vary: User-Agent, qui signale que le serveur délivre un HTML différent selon le type d'appareil.

Cet en-tête était crucial à l'époque du dynamic serving, quand les sites servaient un HTML spécifique pour mobile et un autre pour desktop sur la même URL. Sans ce signal, les caches intermédiaires risquaient de servir la version desktop à un utilisateur mobile, ou l'inverse. Google en avait alors fait une recommandation forte.

Pourquoi Google dit maintenant que c'est optionnel ?

Le responsive design a écrasé le dynamic serving. Aujourd'hui, la majorité des sites utilisent le même HTML avec des breakpoints CSS pour s'adapter aux écrans. Dans ce cas, le contenu ne varie pas selon le User-Agent : il est identique.

Google simplifie donc sa position. Si vous servez le même contenu à tous les appareils, l'en-tête Vary: User-Agent ne transmet aucune information utile au moteur de recherche. Il devient redondant, un vestige d'une autre époque du web mobile.

Que se passe-t-il si je l'ai déjà implémenté ?

Google précise que la présence de l'en-tête Vary n'est pas problématique. Il ne s'agit pas d'un signal négatif qui nuirait à votre crawl budget ou à votre indexation. Le moteur ignore simplement ce qu'il ne comprend pas ou ce qui ne s'applique pas.

Cette tolérance est logique. Beaucoup de sites ont migré du dynamic serving vers le responsive sans nettoyer leur configuration serveur. Retirer cet en-tête peut impliquer des modifications dans Nginx, Apache ou le CDN. Google ne veut pas pénaliser une configuration historique inoffensive.

• L'en-tête Vary: User-Agent est pertinent uniquement avec du contenu distinct par appareil (dynamic serving)
• Avec un design responsive, cet en-tête est inutile mais sans danger
• Google ne pénalise pas sa présence, il l'ignore simplement
• Cette déclaration clarifie une zone grise persistante depuis la généralisation du mobile-first

Cette déclaration correspond-elle à ce qu'on observe sur le terrain ?

Oui. Les audits techniques montrent depuis des années que les sites responsive avec Vary: User-Agent ne subissent aucun handicap de crawl ou d'indexation. Google a toujours été assez souple sur ce point dans la pratique, même si sa documentation restait floue.

Ce qui déroute les praticiens, c'est que Google a longtemps recommandé cet en-tête dans sa documentation sur le dynamic serving. Beaucoup de développeurs l'ont donc implémenté par précaution, même sur des sites responsive. Cette déclaration évite désormais de perdre du temps à débattre de son utilité lors des audits.

Quelles nuances faut-il apporter à cette affirmation ?

Le diable est dans le détail. Certains sites servent un HTML identique mais avec des ressources différentes (images, scripts) selon le device. Dans ce cas, le Vary reste pertinent pour les caches intermédiaires, même si Google s'en fiche.

Par ailleurs, cette déclaration ne couvre pas le Vary: Accept-Encoding ou d'autres variantes. Elle vise spécifiquement le User-Agent dans un contexte mobile vs desktop. Ne retirez pas tous vos Vary header sans réfléchir.

Quand cette règle ne s'applique-t-elle pas ?

Si vous pratiquez encore du dynamic serving, l'en-tête Vary: User-Agent reste obligatoire. Certains sites e-commerce complexes ou des plateformes legacy maintiennent cette architecture pour des raisons de performance ou de compatibilité.

De même, si vous utilisez des URL séparées pour mobile (m.example.com) et desktop, l'en-tête Vary ne s'applique pas : chaque URL sert un contenu unique. Dans ce cas, c'est le rel alternate qui fait le lien entre les versions, pas l'en-tête HTTP.

Que faut-il faire concrètement avec cette information ?

Si vous avez un site responsive et que le Vary: User-Agent est présent dans vos headers HTTP, vous pouvez le conserver. Aucune urgence à le retirer, Google ne vous pénalisera pas. C'est une dette technique mineure, pas un problème bloquant.

Si vous montez un nouveau site ou refondez votre architecture, ne l'ajoutez pas. Simplifiez votre stack serveur. Moins il y a de configuration inutile, moins vous aurez de maintenance à gérer.

Comment vérifier si mon site utilise cet en-tête ?

Inspectez les headers HTTP de vos pages principales avec un outil comme curl, Postman ou les DevTools de Chrome (onglet Network). Cherchez la ligne "Vary:" dans la réponse du serveur. Si elle contient "User-Agent", vous l'utilisez.

Testez aussi en simulant différents User-Agents. Si le HTML renvoyé est strictement identique, l'en-tête est redondant. Si vous voyez des différences (sections masquées, scripts différents), vous pratiquez du dynamic serving et devez garder le Vary.

Quels pièges éviter lors du nettoyage de cette configuration ?

Ne retirez pas l'en-tête Vary si vous n'êtes pas sûr de servir exactement le même HTML. Certains CMS ou frameworks modifient subtilement le contenu selon le device, même sur un site prétendument responsive. Vérifiez d'abord.

Si vous utilisez un CDN comme Cloudflare ou Fastly, l'en-tête Vary peut influencer leur stratégie de cache. Retirer un Vary: User-Agent peut unifier vos caches et améliorer votre hit ratio. Testez en staging avant de déployer.

• Inspectez vos headers HTTP pour détecter la présence de Vary: User-Agent
• Comparez le HTML servi à différents User-Agents (mobile vs desktop) pour vérifier s'il est identique
• Si vous pratiquez du dynamic serving, conservez impérativement cet en-tête
• Sur un site responsive moderne, retirez l'en-tête lors de la prochaine refonte technique pour simplifier la stack
• Purgez les caches CDN après toute modification de configuration Vary
• Documentez votre choix dans les guidelines techniques du projet pour éviter les régressions futures