Nous avons audité la configuration linguistique de 123 grands sites : ce que révèlent 78 pages d’accueil

Comment nous avons mené l’audit

Nous avons retenu 123 marques connues, grand public et B2B, issues du commerce, du voyage, du SaaS, de la banque, de l’industrie et de la grande consommation. Pour chacune, nous avons envoyé une seule requête HTTP GET simple vers la page d’accueil. Elle utilisait un user-agent générique de navigateur et un en-tête Accept-Language: en, partait d’un seul emplacement serveur et suivait les redirections. Nous avons ensuite lu l’en-tête de la page : l’attribut lang de l’élément html, les liens alternatifs hreflang et la balise canonical.

Une requête par site. Pas de connexion, pas de rendu navigateur, pas d’exploration.

78 des 123 sites ont renvoyé une page d’accueil lisible. Les 45 autres non. La plupart ont répondu HTTP 403 à une requête simple, quelques-uns 429 ou 202, ou ont expiré. Nous n’avons pas testé si ce blocage touche aussi les robots de recherche ou d’IA, et nous n’en tirons donc aucune conclusion. Tous les chiffres ci-dessous portent sur les 78.

Les chiffres en un coup d’œil

Chaque pourcentage s’appuie sur la base indiquée dans sa ligne.

Hreflang est courant, et souvent incomplet

45 des 78 sites (58 %) déclarent hreflang pour au moins deux langues. C’est logique pour de grandes marques présentes sur plusieurs marchés. 31 sites n’en déclarent aucun, ce qui ne les rend pas monolingues pour autant : une marque peut exploiter des domaines nationaux distincts, ou servir une seule langue à tout le monde. Nous ne savons que ce que dit l’en-tête de la page.

Les balises canonical sont quasi universelles dans le groupe hreflang : 44 sites sur 45. Les écarts se logent dans le détail.

x-default manque sur 14 des 45 sites

31 des 45 sites (69 %) incluent une entrée x-default. 14 (31 %) n’en ont pas. Cette entrée désigne la page à afficher quand aucune de vos versions linguistiques ne convient au visiteur, en général un sélecteur de langue ou une page globale. Sans elle, c’est le moteur de recherche qui tranche à votre place.

Un site publie trois valeurs invalides

Une valeur hreflang est un code de langue, éventuellement suivi d’une région : fr, fr-BE, es-ES. Un des 45 sites publie trois valeurs qui sortent de ce schéma. es-CE désigne une région qui n’existe pas. in-ID utilise in, un ancien code de l’indonésien, qui s’écrit id aujourd’hui. es-SP utilise SP, qui n’est pas un code pays ISO 3166, puisque l’Espagne est ES. Un moteur peut ignorer une valeur qu’il ne comprend pas : ces alternatives risquent donc de ne rien faire, sans qu’aucun message d’erreur ne prévienne personne.

Un site utilise des URL relatives

Un des 45 sites écrit ses liens hreflang sous forme d’URL relatives. Elles doivent être absolues, avec protocole et hôte. Un affichage du code source repère l’erreur en quelques secondes.

Trois pages d’accueil n’ont pas d’attribut lang

3 des 78 pages d’accueil n’ont aucun attribut lang sur l’élément html. La correction tient en une ligne. Navigateurs, lecteurs d’écran et outils de traduction s’appuient sur cet attribut pour choisir la prononciation, la césure et la proposition de traduire la page. Il doit correspondre à la langue de la page, pas à la valeur par défaut du CMS.

38 % redirigent le domaine nu vers une URL locale

30 des 78 sites (38 %) envoient le domaine nu vers une URL propre à un marché : un chemin par pays, un sous-domaine régional ou un autre hôte. Une redirection n’a rien de gênant quand elle mène les gens quelque part d’utile. Le risque apparaît quand une règle l’impose d’après l’adresse IP ou l’en-tête de langue du visiteur. Notre requête partait d’un seul emplacement et demandait l’anglais : nous ne pouvons donc pas dire quelle règle a déclenché chaque redirection.

Les robots rendent le sujet sensible. Google documente que ses robots visitent depuis peu d’emplacements et n’envoient souvent aucune préférence de langue. Une racine qui redirige toujours vers une seule version risque de ne leur montrer que celle-là. Les redirections forcées appartiennent à la même famille d’erreurs que celles décrites dans pourquoi les logiciels échouent à l’international.

Ce que ces chiffres ne disent pas

Lisez les résultats avec ces limites en tête.

• Pages d’accueil uniquement. Les pages plus profondes peuvent être configurées autrement.
• Grandes marques connues. L’échantillon dit peu de chose des petites entreprises.
• Les sites bloqués sont exclus. Les 45 que nous n’avons pas pu lire peuvent différer des 78 lisibles, ce qui peut fausser les résultats.
• Pas de hreflang ne veut pas dire monolingue. Certains de ces 31 sites servent peut-être plusieurs langues par d’autres moyens.
• Un emplacement, un jour. Un autre serveur ou une autre date pourrait donner d’autres redirections.
• Réciprocité et auto-référence non rapportées. Les redirections et les paramètres de suivi rendaient cette vérification peu fiable ; nous l’avons écartée plutôt que de deviner.

Une checklist de 10 minutes pour votre site

Les balises de langue ne sont qu’une couche de l’internationalisation. Notre explication de l’internationalisation logicielle couvre les couches du dessous. Les contrôles ci-dessous ne concernent que l’en-tête de votre page d’accueil.

• Trouvez les balises. Affichez le code source et cherchez hreflang. Chaque version linguistique doit apparaître, y compris la page où vous êtes.
• Vérifiez chaque code. Utilisez un code de langue ISO 639-1, éventuellement suivi d’une région ISO 3166 : fr-BE, nl-BE, es-ES. Balisez la langue que vous servez, pas le pays que vous espérez atteindre. Un site belge déclare souvent fr-BE et nl-BE.
• Ajoutez x-default. Faites-le pointer vers votre sélecteur ou votre page de repli.
• Utilisez des URL absolues. Incluez https:// et l’hôte.
• Renvoyez les liens. Chaque alternative doit lister les autres et elle-même.
• Alignez html lang. L’attribut doit nommer la langue de la page.
• Testez la racine. Ouvrez le domaine nu dans une fenêtre privée, sans préférence de langue, depuis un autre pays si possible. Si vous arrivez toujours sur la même version, un robot aussi.

Pour une boutique en ligne, ces contrôles se multiplient sur chaque fiche produit et chaque catégorie. Notre article sur le site e-commerce multilingue montre où se concentre le travail. Chez Globaprom, nous construisons en i18n d’abord : codes de langue, replis et routage existent dès le premier sprint, et personne ne les rattrape après coup.

Questions fréquentes