Comment vérifier la langue principale déclarée dans une page HTML ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre langue principale de la page

La langue principale déclarée dans le document aide notamment les technologies d’assistance à interpréter correctement la prononciation et certaines conventions linguistiques. Une page française sans attribut lang, ou déclarée dans une autre langue, peut donc être comprise avec de mauvaises règles de lecture.

Inspecter le comportement réellement servi

Lisez l’élément html de la réponse rendue et relevez la valeur de lang. Comparez-la à la langue réellement dominante du contenu. Contrôlez plusieurs gabarits, car une page correcte n’exclut pas qu’un autre layout ou une zone d’authentification soit produit avec une valeur différente.

Distinguer les notions qui se ressemblent

L’attribut lang décrit la langue du contenu pour l’accessibilité et le traitement du document. Hreflang sert à relier des variantes linguistiques ou régionales pour la recherche. Les deux notions peuvent coexister mais ne se remplacent pas et ne doivent pas être fusionnées dans un même diagnostic.

Identifier les causes les plus probables

Une valeur incorrecte peut provenir d’un template par défaut, d’une traduction de thème incomplète, d’un rendu côté client qui change le contenu sans mettre à jour le document, ou d’un système multilingue qui applique la même langue à toutes les routes.

Décider ce qui mérite d’être corrigé en premier

Corrigez d’abord les pages dont la langue déclarée contredit nettement le contenu principal, puis les valeurs absentes. Sur un site multilingue, vérifiez que chaque version possède sa propre déclaration cohérente au lieu d’utiliser une valeur globale pour tout le domaine.

Corriger à la bonne couche

Placez une valeur de langue valide sur l’élément html depuis la source qui connaît réellement la locale de la page. Pour des passages significatifs dans une autre langue, une déclaration plus locale peut être pertinente. Évitez cependant de baliser chaque mot étranger sans bénéfice réel.

Traiter les cas limites sans automatisme

Les noms de marque, termes techniques et expressions courtes n’impliquent pas forcément un changement de langue. Les pages hybrides demandent d’identifier la langue dominante avant de multiplier les attributs. Le diagnostic doit rester lié à l’expérience de lecture assistée.

Valider la correction sur des cas réels

Inspectez le HTML final après cache, rendu serveur et éventuelle hydratation. Testez quelques pages de chaque langue et vérifiez que la valeur ne change pas de façon inattendue au chargement. Sur un site international, comparez ensuite séparément la configuration hreflang.

Prévenir la régression dans le temps

Faites dériver lang de la locale applicative plutôt que d’une chaîne copiée dans le template. Ajoutez une vérification dans les tests de gabarit pour détecter une valeur absente, vide ou incohérente lors de l’ajout d’une nouvelle langue.

Clôturer le contrôle sur langue principale de la page

Pour clôturer le contrôle « Comment vérifier la langue principale déclarée dans une page HTML ? », conservez une preuve avant/après : URL ou composant testé, constat initial, origine technique, correction appliquée et résultat de la vérification. Contrôlez aussi les pages liées /site/accessibilite, /site/ordre-titres-accessibilite, /seo/international-hreflang afin de vérifier que la correction reste cohérente avec le reste du corpus. Le périmètre documentaire reste volontairement borné : Distinguer la langue principale déclarée pour l’accessibilité de hreflang destiné aux variantes linguistiques en recherche. Ne pas présenter l’attribut lang comme un signal de ciblage SEO équivalent à hreflang. Si le comportement dépend d’un gabarit, d’un CDN, d’un navigateur ou d’un outil tiers, testez au moins un second cas représentatif. Une anomalie ambiguë doit rester en revue plutôt que d’être fermée sur une hypothèse. Attribuez enfin la règle à une source précise — composant, template, serveur, CMS ou configuration — pour pouvoir la retester après une refonte.

Conserver une preuve exploitable dans l’audit

Un contrôle sur langue principale de la page est utile seulement si une autre personne peut reproduire le constat. Enregistrez la réponse ou l’état observé, l’outil utilisé, le contexte de test et l’élément exact qui justifie la conclusion. Évitez les captures isolées sans URL, statut ou propriété mesurée. Pour les anomalies répétées, comptez les occurrences par gabarit avant et après correction. Cette trace permet de distinguer une résolution globale d’un exemple corrigé manuellement et évite de rouvrir le même diagnostic sans information nouvelle. Lorsque la documentation officielle est la borne du contrôle, notez également la source utilisée afin de pouvoir réévaluer la règle si elle évolue.

Tester un scénario représentatif

Sur un site français qui possède une version anglaise, choisissez trois routes : une page française, son équivalent anglais et une page technique partagée comme la connexion. Relevez lang sur l’élément html avant et après rendu client, puis comparez la langue réellement affichée. Contrôlez séparément hreflang : une paire de variantes peut être correctement reliée pour la recherche tout en exposant un mauvais lang pour les technologies d’assistance. Ajoutez un passage court contenant une marque ou un terme anglais et vérifiez qu’il ne conduit pas le template à changer la langue principale du document. Enfin, testez une erreur 404 ou une page de consentement, souvent produite par un layout différent. Ce scénario révèle les configurations globales trop simplistes et aide à déterminer si la locale applicative, le CMS ou un composant tiers est propriétaire de la valeur. Pour chaque route de test, notez locale applicative, attribut html lang, éventuel xml:lang, langue du titre, langue du contenu principal et code hreflang associé. Ajoutez les pages système : 404, connexion, consentement, erreur serveur et recherche vide. Les valeurs fr, fr-FR, en ou en-GB doivent être analysées selon la langue réelle du document, sans convertir ce contrôle d’accessibilité en règle de ciblage géographique. Sur une page bilingue contenant une citation longue en anglais, inspectez la possibilité d’appliquer lang localement au bloc cité tout en gardant fr sur html. Cela permet de tester la granularité sans transformer les noms propres, acronymes techniques ou menus communs en changements de langue artificiels. Vérifiez les codes BCP 47 réellement utilisés par l’application, la casse, les sous-tags régionaux et les valeurs héritées par les composants embarqués. Une iframe possède son propre document et sa propre langue ; un fragment injecté dans la page hérite du contexte du document hôte. Cette distinction aide à diagnostiquer les widgets externes sans modifier inutilement la langue globale.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• w3c language page