Un site qui s’adresse à plusieurs pays peut proposer des pages presque identiques, mais pas destinées aux mêmes lecteurs. L’attribut hreflang aide les moteurs de recherche à associer chaque page à sa variante linguistique ou régionale.
Ce signal ne remplace ni une bonne traduction ni un contenu pertinent. Pour être utile, il doit relier des pages équivalentes, employer des codes corrects et rester cohérent avec les URL canoniques.
Hreflang : les principes du ciblage linguistique et géographique
Selon Google Search Central, les annotations hreflang indiquent les variantes linguistiques ou régionales d’une page aux moteurs de recherche. Elles facilitent le choix de l’URL présentée à l’internaute, sans garantir une position particulière dans les résultats.
Une boutique fictive, Atelier Boréal, vend des manteaux en France, en Belgique et au Canada. Ses pages françaises peuvent partager une langue, tout en présentant des prix, des modalités de livraison ou des références adaptées à chaque marché.
Le ciblage linguistique désigne la langue du contenu ; le ciblage géographique précise le public régional visé. La balise n’est donc pas réservée aux sites traduits : elle peut aussi distinguer des versions régionales d’une même langue.
À retenir :
- Orientation des internautes vers la variante la plus pertinente
- Distinction claire entre langues et marchés régionaux
- Meilleure cohérence des pages internationales équivalentes
- Signal technique complémentaire, sans garantie de classement
Syntaxe hreflang : codes de langue et exemples corrects
Une fois les marchés définis, il faut traduire cette stratégie en annotations valides. La syntaxe hreflang combine généralement un code de langue ISO 639-1 et, si nécessaire, un code de pays ISO 3166-1.
Par exemple, fr désigne le français sans préciser de région, tandis que fr-CA cible le français au Canada. Pour distinguer des contenus anglais, on peut employer en-GB et en-US ; le code régional britannique est GB, et non « UK ».
Dans le code HTML, chaque variante peut être déclarée avec une balise link rel= »alternate ». Les adresses doivent être absolues et pointer vers des pages accessibles, indexables et réellement équivalentes.
Voici les vérifications essentielles avant publication :
- Employer les codes de langue et de région dans le bon ordre
- Déclarer l’URL de la page elle-même parmi les variantes
- Ajouter des liens réciproques entre toutes les pages concernées
- Choisir une URL canonique cohérente pour chaque version
| Valeur hreflang | Interprétation | Exemple d’usage |
|---|---|---|
| fr | Contenu en français, sans région précisée | Page française destinée à plusieurs marchés |
| fr-CA | Français ciblant le Canada | Offre adaptée aux clients canadiens |
| en-GB | Anglais ciblant le Royaume-Uni | Contenu et conditions britanniques |
| en-US | Anglais ciblant les États-Unis | Prix ou informations propres au marché américain |
Implémenter hreflang en HTML, dans un sitemap ou en HTTP
La syntaxe choisie dépend surtout du volume et de l’architecture du site. Pour quelques pages, l’ajout dans l’en-tête HTML reste facile à contrôler ; les grands catalogues gagnent souvent à automatiser les annotations.
Balises HTML pour les sites de taille modeste
Dans l’en-tête de chaque page, les liens relient ses variantes, y compris la page courante. Si la page française pointe vers la canadienne, cette dernière doit aussi référencer la française : cette réciprocité aide les moteurs à reconnaître l’ensemble comme un groupe cohérent.
Selon Google Search Central, chaque version doit fournir les mêmes annotations à l’échelle du groupe. Une configuration possible pour deux pages serait :
• Page française : <link rel="alternate" hreflang="fr-FR" href="https://exemple.fr/produit/">
• Page canadienne : <link rel="alternate" hreflang="fr-CA" href="https://exemple.ca/produit/">
L’entrée x-default peut signaler une page de sélection ou une version par défaut lorsqu’aucune variante ne correspond clairement. Elle est facultative et ne remplace pas les versions destinées à des publics précis.
Sitemap XML et en-tête HTTP pour les gros volumes
Pour des milliers d’URL, déclarer les relations dans un sitemap XML peut simplifier la gestion centralisée. Chaque URL et ses variantes doivent cependant être listées de manière complète et concordante, au risque de créer des signaux contradictoires.
Selon la documentation de Google Search Central, les annotations peuvent aussi être transmises par en-tête HTTP, une option adaptée notamment aux fichiers non HTML comme certains PDF. Le choix d’une méthode unique réduit les divergences ; combiner plusieurs méthodes n’est pertinent que si leurs données restent identiques.
Les critères de choix sont principalement opérationnels :
- Pages peu nombreuses : annotations dans le HTML
- Catalogue étendu : gestion centralisée via sitemap XML
- Document non HTML : annotations dans l’en-tête HTTP
- Déploiement automatisé : contrôle systématique des versions publiées
| Méthode | Contexte adapté | Contrôle à prévoir |
|---|---|---|
| HTML | Site de taille limitée | Présence dans chaque page et réciprocité |
| Sitemap XML | Grand nombre de pages traduites | Correspondance entre les URL et les variantes |
| En-tête HTTP | PDF ou ressource non HTML | Valeurs renvoyées par le serveur |
| Plusieurs méthodes | Besoin technique spécifique | Identité exacte des déclarations |
Erreurs hreflang fréquentes et vérifications utiles
Après la mise en place, les défauts apparaissent souvent lors d’une migration ou de l’ajout d’une langue. Une seule URL redirigée, canonisée vers une autre page ou bloquée peut rendre une relation moins exploitable.
Selon Google Search Central, les erreurs de retour peuvent empêcher la reconnaissance d’une paire de pages. Il faut aussi distinguer langue et pays : es-MX vise l’espagnol au Mexique, tandis que es ne précise pas de région.
Un audit régulier compare les annotations, les URL canoniques, les réponses serveur et les pages réelles. Atelier Boréal peut, par exemple, vérifier chaque ajout de pays dans son processus de publication, plutôt que corriger un grand nombre d’anciennes pages après coup.
Les contrôles prioritaires portent sur ces points :
- Liens réciproques et présence de l’URL propre à chaque page
- Codes de langue et région correctement formés
- URL actives, canoniques et accessibles aux robots
- Mise à jour des groupes après toute modification d’adresse
Une vérification doit enfin confronter les annotations à l’expérience réelle : le lecteur arrive-t-il sur la bonne offre, avec la bonne devise et les bonnes informations locales ? Le signal technique fonctionne mieux lorsque l’architecture, le contenu et les choix éditoriaux racontent la même histoire.
Source : Google Search Central, « Versions localisées de vos pages », documentation sur la recherche Google.
Choisir sa formation informatique comme un projet, pas un réflexe
Qu'il s'agisse d'un diplôme classique, d'une certification professionnelle ou d'un bootcamp intensif, chaque parcours mérite d'être anticipé. Comprendre ses propres contraintes — niveau de départ, temps disponible, objectif professionnel — permet d'en tirer aussi des bénéfices concrets : montée en compétences réelle, insertion professionnelle et évolution de carrière durable.
Pour aller plus loin
- Vérifier l'adéquation entre le format de formation et votre rythme de vie
- Comparer les certifications reconnues dans votre domaine cible
- Vous renseigner sur les dispositifs de financement disponibles (CPF, France Travail...)
- Échanger avec d'anciens élèves ou diplômés avant de vous engager
