L’en-tête Vary : Accept-Language agit comme une instruction spécifique pour les caches Web et les moteurs de recherche, indiquant que le contenu d’une page change en fonction des préférences linguistiques du navigateur demandeur. En incluant cet en-tête dans votre réponse HTTP, vous garantissez que les serveurs mettent en cache différentes versions d’une page pour différents groupes linguistiques, évitant ainsi qu’un utilisateur en France ne reçoive une page en anglais mise en cache. Ce paramètre technique est indispensable pour maintenir une indexation de recherche internationale précise.
Pourquoi l’en-tête Vary est-il important pour les moteurs de recherche ?
Les moteurs de recherche donnent la priorité à la diffusion du contenu le plus pertinent dans la langue préférée de l’utilisateur. Lorsque votre serveur utilise la même URL pour diffuser différentes versions linguistiques en fonction des paramètres du navigateur, l’en-tête Vary sert de guide aux robots d’exploration. Sans lui, un CDN ou un cache peut stocker une version de votre page et la servir à tout le monde, quels que soient leurs paramètres linguistiques. Cela empêche Google d’indexer correctement les diverses versions linguistiques de votre contenu, car le robot d’exploration ne verra peut-être que la version renvoyée par le cache.
Lorsque Googlebot rencontre une URL qui répond différemment selon les en-têtes, le signal Vary confirme que la réponse n’est pas une erreur statique ou une méprise. Il indique au moteur de recherche que la variation est intentionnelle. Sans cela, le moteur de recherche pourrait supposer à tort que le site contient du contenu dupliqué ou, pire, indexer la mauvaise variante linguistique comme version canonique pour toutes le régions.
Considérez un scénario où un utilisateur navigue depuis le Japon avec des paramètres de langue anglaise dans son navigateur. Si votre serveur n’est pas configuré pour envoyer l’en-tête Vary : Accept-Language, le cache peut servir la version japonaise de la page en raison de l’adresse IP de l’utilisateur, même si ses préférences de navigateur indiquent clairement une préférence pour l’anglais. Une configuration correcte des en-têtes résout ce conflit entre la localisation basée sur l’IP et la préférence linguistique définie par l’utilisateur.
Comment la mise en cache côté serveur interagit-elle avec les en-têtes de langue ?
Les couches de mise en cache gèrent souvent mal les sites internationaux car elles mettent généralement en cache uniquement sur la base de l’URL. Si votre site diffuse du contenu basé sur l’en-tête de requête Accept-Language, le cache doit être conscient de cette dépendance. Si l’en-tête est absent, le cache traite toutes les requêtes comme identiques, ce qui entraîne une diffusion incorrecte du contenu. Cela crée un goulet d’étranglement où le premier visiteur d’une région spécifique détermine ce que voient les visiteurs suivants.
Les CDN modernes permettent la normalisation des clés de cache. Vous devez vous assurer que votre clé de cache inclut la valeur de l’en-tête Accept-Language en tant que paramètre. Si votre serveur envoie l’en-tête Vary : Accept-Language mais que votre CDN l’ignore, le CDN servira toujours la version mise en cache de la première personne ayant visité la page. C’est un point de défaillance courant qui entraîne une mauvaise expérience utilisateur pour les publics internationaux.
- Configurez votre serveur d’origine pour envoyer ‘Vary : Accept-Language’ dans l’en-tête de réponse HTTP.
- Assurez-vous que votre CDN prend en charge les en-têtes Vary et qu’il est configuré pour inclure l’en-tête dans sa clé de cache.
- Testez vos en-têtes de réponse à l’aide des outils de développement du navigateur ou d’outils de ligne de commande tels que curl.
- Surveillez les journaux de votre serveur pour vérifier que les différentes requêtes linguistiques atteignent les versions de cache correctes.
- Vérifiez que le contenu de votre site varie réellement lorsque l’en-tête est présent.
Quelles sont les erreurs courantes lors de la mise en œuvre des en-têtes de langue ?
De nombreux développeurs oublient que l’en-tête Vary doit être envoyé pour chaque page dépendante de la langue. Une autre erreur courante est de ne pas s’assurer que le contenu change réellement lorsque l’en-tête est présent. Si le contenu reste identique, l’ajout de l’en-tête Vary crée une fragmentation inutile dans votre cache, ce qui ralentit les performances de votre site et augmente inutilement la charge de votre serveur d’origine.
Une autre erreur consiste à surcompliquer la chaîne Vary. Inclure trop d’en-têtes tels que ‘Vary : Accept-Language, User-Agent, Cookie’ peut entraîner de faibles ratios de réussite de cache. Gardez l’en-tête Vary strictement axé sur la langue si c’est le seul facteur dynamique. De plus, évitez d’utiliser l’en-tête Vary si votre site repose sur une structure statique où chaque langue possède sa propre URL unique, car il est inutile dans cette architecture.
En résolvant ces lacunes techniques, vous vous assurez que Google dirige les visiteurs vers le contenu qui correspond à leur emplacement spécifique et à leurs paramètres linguistiques.
Google Search Central
Comment Alien Road applique les en-têtes Vary
Chez Alien Road, nous suivons un protocole strict lors de la gestion de projets internationaux. Nous commençons par auditer les en-têtes de réponse du serveur actuel pour tous les sous-domaines et sous-dossiers régionaux. Ensuite, nous configurons la détection de langue côté serveur pour qu’elle s’associe correctement à l’en-tête Vary, garantissant ainsi que le contenu de nos clients est correctement indexé par Googlebot. Nous ne nous arrêtons pas à la configuration ; nous vérifions ces paramètres à l’aide de requêtes simulées provenant de divers emplacements internationaux pour nous assurer que le cache se comporte comme prévu.
Par exemple, dans le cadre d’une mission typique pour un client e-commerce mondial, nous cartographions d’abord tous les chemins linguistiques. Nous testons ensuite les en-têtes sur un environnement de staging pour garantir que le CDN sépare correctement le cache. Une fois confirmé, nous déployons les modifications par petits incréments, en surveillant le rapport ‘Statistiques d’exploration’ de Google Search Console pour nous assurer que Googlebot peut toujours atteindre toutes les versions linguistiques du site sans rencontrer de boucles de redirection.
- Auditez les en-têtes HTTP existants sur toutes les versions globales du site.
- Implémentez des signaux Vary : Accept-Language cohérents au niveau du serveur d’origine.
- Vérifiez les configurations des clés de cache du CDN pour inclure les en-têtes de langue comme identifiant unique.
- Effectuez des tests inter-régionaux à l’aide de VPN pour confirmer une diffusion précise du contenu.
- Examinez les journaux d’exploration pour vous assurer que Googlebot n’est pas bloqué par des erreurs de configuration du cache.
Comment vérifier votre mise en œuvre cette semaine
Vous pouvez commencer par utiliser l’onglet Réseau (Network) dans les outils de développement de votre navigateur pour vérifier les en-têtes de réponse de vos pages de destination. Recherchez le champ ‘Vary’ et confirmez qu’il inclut ‘Accept-Language’. Si vous remarquez qu’il manque, coordonnez-vous avec votre équipe d’ingénierie pour mettre à jour la configuration de votre serveur ou les règles de périphérie de votre CDN. Ce changement simple améliore la fiabilité de votre stratégie SEO internationale et prévient les erreurs d’indexation.
Exécutez un test à l’aide d’un outil tel que curl dans votre terminal : ‘curl -I -H “Accept-Language : fr” https://example.com/’. Examinez la sortie à la recherche de l’en-tête Vary. En effectuant cette vérification par rapport à différentes chaînes de langue, vous pouvez confirmer que votre serveur répond avec les instructions correctes au cache. C’est le moyen le plus efficace de vous assurer que votre site est prêt pour un public mondial.