Faut-il vraiment utiliser le header 'Vary: User-Agent' sur toutes vos pages adaptatives ?

Pourquoi Google insiste-t-il sur l'usage précis du header 'Vary: User-Agent' ?

Le header HTTP 'Vary: User-Agent' indique aux navigateurs et aux proxys de cache qu'une page peut servir un contenu différent selon l'agent utilisateur qui la demande. Quand ce header est présent, les serveurs de cache comprennent qu'ils doivent stocker plusieurs versions de la même URL.

Le problème ? Si vous appliquez ce header sur toutes vos pages alors que seule une partie de votre contenu varie réellement, vous fragmentez inutilement le cache. Googlebot crawle alors plusieurs versions identiques, ce qui ralentit l'exploration et dilue votre crawl budget.

Qu'est-ce qu'une page web adaptative dans ce contexte ?

Une page adaptative (responsive design adaptatif) sert du HTML différent selon l'appareil, contrairement au responsive pur qui adapte le CSS uniquement. Par exemple, votre page desktop affiche un carrousel avec 10 images, mais la version mobile n'en charge que 3 pour alléger le poids.

Dans ce cas précis, le contenu diffère réellement et le header 'Vary: User-Agent' est justifié. Mais si votre page sert exactement le même HTML avec juste quelques ajustements CSS, ce header devient contre-productif.

Comment identifier les pages qui nécessitent réellement ce header ?

Inspectez votre source HTML en comparant desktop et mobile. Si les balises structurelles, les contenus textuels, les images ou les scripts diffèrent, alors oui, le header est pertinent. Un simple changement de mise en page via CSS ne compte pas.

Surveillez également vos logs serveur et vos temps de réponse. Un cache fragmenté se traduit par des hit rates faibles et des temps de chargement plus élevés pour vos utilisateurs mobiles. C'est souvent le premier signal que vous appliquez le header trop largement.

• N'appliquez 'Vary: User-Agent' que sur les pages servant un HTML différent selon l'appareil
• Évitez d'utiliser ce header de manière globale sur toutes les URLs de votre site
• Vérifiez régulièrement vos logs de cache pour détecter une fragmentation excessive
• Distinguez clairement responsive CSS (pas de Vary) et contenu adaptatif HTML (Vary nécessaire)
• Documentez les pages concernées dans votre stratégie technique SEO

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

Absolument. J'ai audité des dizaines de sites qui appliquaient 'Vary: User-Agent' en mode cargo cult, sans comprendre l'impact réel. Résultat : des taux de cache CDN descendant sous 40%, des temps de crawl Googlebot multipliés par deux, et des Core Web Vitals dégradés.

Ce qui surprend, c'est que Google le formule aussi franchement. Habituellement, ils restent évasifs sur les headers HTTP. Ici, le message est clair : arrêtez d'utiliser ce header partout. C'est un signal que beaucoup de sites commettent cette erreur et que ça impacte leur infrastructure de crawl.

Quelles nuances faut-il apporter à cette déclaration ?

Google ne précise pas comment gérer les cas hybrides, ces pages qui servent 95% du même contenu mais avec quelques variations mineures. Par exemple, une page qui masque un bandeau promotionnel côté mobile via du rendering côté serveur. Techniquement, le HTML diffère. Faut-il vraiment fragmenter le cache pour ça ? [À vérifier]

Autre zone grise : les sites qui utilisent des frameworks JavaScript modernes avec du server-side rendering conditionnel. Next.js, Nuxt, Astro... tous peuvent générer des outputs différents selon l'agent. La recommandation de Google reste-t-elle valable quand le delta de contenu est minime mais structurellement présent ?

Dans quels cas cette règle pourrait-elle poser problème ?

Sur des sites e-commerce avec personnalisation avancée, le contenu peut varier selon l'appareil pour des raisons business. Mobile-first pricing, offres géolocalisées différentes, sections produits réorganisées... Si vous servez réellement un catalogue différent selon l'appareil, le header est légitime.

Attention aussi aux AMP ou versions mobiles dédiées. Si vous maintenez encore des URLs séparées (m.site.com), cette recommandation ne s'applique pas directement. Le 'Vary: User-Agent' devient alors crucial pour éviter que Google serve la version desktop aux mobiles.

Que faut-il faire concrètement sur votre site ?

Commencez par un audit complet de vos headers HTTP. Utilisez curl ou un outil comme Screaming Frog pour extraire tous vos headers 'Vary' sur un échantillon représentatif d'URLs. Comparez ensuite le HTML source entre desktop et mobile pour chaque type de page.

Si vous constatez que votre site utilise un responsive design pur CSS, retirez immédiatement le header 'Vary: User-Agent'. Vous n'en avez pas besoin. Par contre, si certaines pages catégories ou fiches produits chargent moins d'éléments côté mobile, segmentez l'application du header uniquement sur ces URLs.

Quelles erreurs éviter impérativement ?

Ne configurez jamais le header au niveau du serveur global (Apache, Nginx) si toutes vos pages ne nécessitent pas ce traitement. Descendez au niveau des règles par type de page, voire par URL si nécessaire. Un .htaccess mal configuré peut saboter vos performances cache.

Évitez également de mélanger plusieurs stratégies adaptatives sur un même site. Si vous passez d'un design adaptatif à un responsive pur, nettoyez tous les anciens headers. Les configurations hybrides sont la première source de bugs d'indexation mobile-first.

Comment vérifier que votre configuration est optimale ?

Surveillez vos métriques de cache avant et après modification. Un bon CDN affiche un hit rate supérieur à 80% sur les contenus statiques. Si vous êtes en dessous après avoir retiré le header, c'est que d'autres facteurs fragmentent votre cache (cookies, query strings...).

Analysez aussi vos rapports de crawl Search Console. Une indexation mobile-first perturbée par des headers mal configurés se manifeste par des écarts importants entre pages découvertes et pages indexées, ou par des temps de réponse serveur élevés dans les stats d'exploration.

• Auditez tous vos headers HTTP 'Vary' sur un échantillon représentatif d'URLs
• Comparez le HTML source desktop vs mobile pour chaque type de page clé
• Retirez le header sur les pages responsive pure CSS sans variation HTML
• Configurez le header au niveau page, pas au niveau serveur global
• Surveillez vos hit rates CDN avant et après modification
• Vérifiez les rapports de crawl Search Console pour détecter des anomalies d'indexation