L'en-tête Vary mal configuré impacte-t-il vraiment l'indexation de votre site responsive ?

Qu'est-ce que l'en-tête Vary et pourquoi existe-t-il ?

L'en-tête Vary est un mécanisme HTTP qui permet aux serveurs d'indiquer aux navigateurs et aux crawlers quelles variables influencent la version du contenu servie. Pour un site responsive qui sert le même HTML à tous les devices, l'en-tête Vary n'a aucune utilité — puisque justement, la même version est envoyée à tous.

Le problème survient quand les développeurs configurent Vary: User-Agent par habitude ou par méconnaissance. Cette directive signale à Googlebot que le contenu peut changer selon le User-Agent, ce qui est contradictoire avec l'architecture même du responsive design. Le bot interprète alors qu'il doit peut-être recrawler la page avec différents User-Agents pour s'assurer de bien indexer toutes les versions.

Pourquoi Googlebot recrawle-t-il inutilement ces pages ?

Googlebot détecte l'en-tête Vary: User-Agent et suppose que le contenu diffère selon qu'il crawle avec un User-Agent mobile ou desktop. Dans le doute, il planifie des passages supplémentaires pour vérifier si les deux versions présentent des différences significatives.

Ces recrawls ne nuisent pas à l'indexation — la page reste bien dans l'index, le contenu est compris et classé normalement. Mais vous consommez du crawl budget pour rien, ce qui est problématique sur des sites de plusieurs dizaines de milliers de pages. Chaque passage inutile est un passage qui ne se fait pas sur une URL qui en aurait réellement besoin.

Cette déclaration change-t-elle quelque chose aux bonnes pratiques ?

Non, elle confirme simplement ce que les praticiens observaient déjà : une mauvaise configuration technique peut ralentir le crawl sans pour autant casser l'indexation. Mueller rassure sur le fait qu'il n'y a pas de pénalité directe, mais cela ne signifie pas qu'il faut ignorer le problème.

Pour les sites de petite taille, l'impact sera marginal — Googlebot a largement le temps de tout crawler. Pour les plateformes à forte volumétrie, e-commerce ou médias, c'est une autre histoire : chaque recrawl inutile est une opportunité manquée d'explorer de nouvelles pages ou de détecter des mises à jour importantes.

• Vary: User-Agent sur un site responsive est une configuration incohérente qui génère des recrawls superflus
• L'indexation n'est pas compromise, mais le crawl budget est gaspillé
• Les sites à forte volumétrie sont les plus impactés par cette inefficacité
• La correction est simple : retirer l'en-tête Vary ou le configurer correctement selon l'architecture technique réelle
• Google ne pénalise pas cette erreur, mais elle reste un frein à l'optimisation du crawl

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, complètement. Les audits techniques montrent régulièrement des sites qui servent le même contenu responsive avec un Vary: User-Agent en place. Dans les logs serveur, on observe effectivement que Googlebot visite ces URLs plus fréquemment, avec alternance entre User-Agent mobile et desktop, sans que cela n'impacte le positionnement ou la présence dans l'index.

Ce que Mueller ne dit pas explicitement, c'est à quel point ce gaspillage peut être significatif. Sur un site de 50 000 URLs avec un crawl budget limité, un doublement du nombre de passages nécessaires peut retarder de plusieurs jours la découverte de nouveaux contenus. C'est mesurable dans les données Search Console et dans les logs, mais Google reste vague sur l'ampleur réelle du problème. [A vérifier] selon votre volumétrie et votre fréquence de mise à jour.

Quelles nuances faut-il apporter à cette affirmation ?

Mueller parle d'un site responsive, mais la situation est différente avec du dynamic serving (servir un HTML différent selon le User-Agent). Dans ce cas, l'en-tête Vary: User-Agent est non seulement recommandé, mais obligatoire pour que Google comprenne qu'il doit crawler les deux versions.

Le problème ne vient donc pas de l'en-tête Vary en lui-même, mais de son utilisation incohérente avec l'architecture technique. Si vous faites du responsive, pas de Vary. Si vous faites du dynamic serving, Vary est indispensable. La confusion vient souvent d'un changement d'architecture mal accompagné : le site passe au responsive mais les headers HTTP restent configurés pour du dynamic serving.

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

Si vous servez réellement des contenus différents selon le User-Agent — par exemple un sous-domaine mobile avec une structure HTML différente — alors l'en-tête Vary est pertinent et les recrawls sont justifiés. Google a besoin de voir les deux versions pour les indexer correctement.

Autre cas limite : certains CDN ou proxies ajoutent automatiquement des headers Vary pour gérer leur cache interne, sans que le propriétaire du site en ait conscience. Dans ce cas, le problème ne se règle pas côté serveur origine, mais dans la configuration du CDN. Une analyse des réponses HTTP réelles envoyées par le CDN est nécessaire pour identifier la source du problème.

Comment vérifier si votre site envoie un en-tête Vary inutile ?

Utilisez les DevTools de votre navigateur (onglet Network) ou un outil comme cURL pour inspecter les headers HTTP de réponse de vos pages principales. Si vous voyez Vary: User-Agent alors que votre site est responsive, vous avez identifié le problème.

Vérifiez également dans vos logs serveur si Googlebot crawle vos URLs avec alternance entre User-Agent mobile et desktop sur une courte période. Un pattern de double crawl systématique est un bon indicateur que Google réagit à cet en-tête Vary incohérent. La Search Console ne vous alertera pas directement sur ce point — c'est dans les logs que ça se voit.

Que faut-il faire concrètement pour corriger cette erreur ?

Si votre site est bien responsive et sert le même HTML à tous les devices, supprimez l'en-tête Vary: User-Agent de vos réponses HTTP. Côté serveur Apache, cela se fait dans le .htaccess ou la configuration du vhost. Côté Nginx, dans le bloc server ou location concerné.

Si vous utilisez un CDN (Cloudflare, Fastly, Akamai…), vérifiez la configuration de cache : certains CDN ajoutent automatiquement un Vary: User-Agent pour gérer leurs propres politiques de cache. Dans ce cas, désactivez cette règle ou ajustez la configuration pour qu'elle ne s'applique pas aux crawlers. Testez ensuite avec un crawler de votre côté pour valider que la modification a bien été prise en compte.

Quelles erreurs éviter lors de cette correction ?

Ne retirez pas l'en-tête Vary si vous faites réellement du dynamic serving — vous casseriez alors la capacité de Google à détecter qu'il existe plusieurs versions. Assurez-vous d'abord que votre architecture est bien responsive avant de toucher aux headers.

Évitez également de modifier les headers sans tester l'impact sur le cache du CDN. Un changement brutal peut entraîner une purge du cache et une hausse temporaire de la charge serveur. Prévoyez un déploiement progressif si vous gérez un site à fort trafic. Enfin, documentez le changement dans vos procédures techniques pour éviter qu'un futur déploiement ne réintroduise l'erreur par inadvertance.

• Inspecter les headers HTTP de réponse pour détecter un Vary: User-Agent inutile
• Analyser les logs serveur pour identifier les patterns de double crawl Googlebot
• Supprimer l'en-tête Vary si le site est responsive (même HTML pour tous les devices)
• Vérifier la configuration du CDN pour s'assurer qu'il ne rajoute pas cet en-tête automatiquement
• Tester la modification avec un crawler avant déploiement en production
• Documenter le changement pour éviter les régressions futures