hreflang améliore-t-il le classement d'une page ?

Non, ce n'est pas un critère de classement. hreflang aide Google à choisir laquelle de vos versions afficher pour un internaute donné, il ne fait pas monter la page dans les résultats. Son bénéfice est indirect : la bonne version dans le bon pays, c'est une meilleure expérience et moins de visiteurs perdus.

x-default est-il obligatoire ?

Non, il est facultatif mais recommandé dès que votre audience dépasse les langues déclarées : il indique la page à servir par défaut à tous les internautes qui ne correspondent à aucune version. En pratique, on y place souvent la version internationale en anglais ou une page de choix de langue.

Peut-on mettre les balises uniquement sur la page d'accueil ?

Non. Les annotations fonctionnent page par page : chaque page française doit déclarer son équivalente anglaise précise, et réciproquement. Une déclaration limitée à l'accueil laisse toutes les pages profondes sans correspondance.

Faut-il un hreflang si mon site n'existe qu'en français ?

Si toutes vos pages n'existent qu'en une langue et visent un seul public, non. Le sujet devient pertinent dès que vous servez plusieurs pays francophones avec des contenus distincts (France, Belgique, Canada), car c'est précisément le cas où Google confond le plus facilement les versions.

Référencement international : le guide hreflang pour viser plusieurs pays

Le problème que hreflang résout

Prenons un site qui existe en français, en anglais et en espagnol. Sans indication, Google doit deviner quelle version proposer à un internaute de Bruxelles, de Londres ou de Bogota. Il se trompe rarement quand les langues sont très différentes, beaucoup plus souvent quand elles sont proches : un site avec une version pour la France et une pour le Canada francophone verra régulièrement la mauvaise sortir dans les résultats.

L'attribut hreflang répond à ce problème. C'est une annotation qui déclare : cette page existe aussi dans telle langue, à telle adresse. Google s'en sert pour afficher la bonne version au bon public, ce qui améliore l'expérience et évite que vos variantes se cannibalisent entre elles.

Précision utile avant d'entrer dans la syntaxe : Google traite hreflang comme un signal, pas comme un ordre. Des annotations propres augmentent fortement les chances que la bonne version sorte, elles ne le garantissent pas. Tout cela est documenté sur Google Search Central, la référence officielle sur le sujet.

La syntaxe exacte, sans approximation

Trois implémentations possibles, au choix : des balises dans le <head> de chaque page, des en-têtes HTTP (utile pour les fichiers non HTML comme les PDF), ou le sitemap XML. Pour la version HTML, chaque page liste l'ensemble de ses variantes :

<link rel="alternate" hreflang="fr" href="https://www.exemple.com/fr/" />
<link rel="alternate" hreflang="en-gb" href="https://www.exemple.com/uk/" />
<link rel="alternate" hreflang="x-default" href="https://www.exemple.com/" />

Le code de langue suit la norme ISO 639-1 (fr, en, es), éventuellement complété d'un code pays ISO 3166-1 alpha-2 (fr-ca pour le français du Canada, en-gb pour l'anglais du Royaume-Uni). La langue seule est autorisée, le pays seul ne l'est pas. Les URL doivent être absolues, protocole compris.

Deux règles font tenir l'ensemble. D'abord l'auto-référence : chaque page se déclare elle-même dans sa propre liste. Ensuite la réciprocité : si la page française pointe vers la page anglaise, la page anglaise doit pointer en retour vers la française, sinon Google ignore l'annotation. Quant à x-default, il désigne la version à servir quand aucune langue déclarée ne correspond au visiteur, souvent une page d'accueil avec sélecteur de langue.

Domaine par pays, sous-domaine ou sous-dossier ?

Question à trancher en amont : où loger chaque version ? Trois architectures existent. Le domaine national (exemple.fr, exemple.de) envoie le signal géographique le plus fort et rassure les internautes locaux, mais chaque domaine repart de zéro : autorité, liens entrants et maintenance sont multipliés par le nombre de pays. Je le réserve aux entreprises qui ont une vraie présence locale et les moyens de la faire vivre.

Le sous-dossier (exemple.com/fr/, exemple.com/de/) est l'option que je recommande dans la majorité des cas : toutes les versions capitalisent sur l'autorité du même domaine, l'hébergement reste unique et le suivi dans la Search Console peut être découpé proprement par répertoire.

Le sous-domaine (fr.exemple.com) occupe l'entre-deux, sans avantage décisif à mes yeux. Google indique traiter les trois structures correctement : le choix relève donc surtout de contraintes techniques, juridiques et organisationnelles. Sa page sur la gestion des sites multirégionaux détaille les compromis de chaque option.

Les erreurs que je retrouve dans presque tous les audits

Des années de crawls m'ont laissé une collection d'erreurs hreflang, presque toujours les mêmes. La plus répandue : les balises retour manquantes. La version française déclare l'anglaise, mais l'anglaise a été mise en ligne sans ses annotations, et l'ensemble ne vaut plus rien. C'est mécanique : la réciprocité n'est pas une option.

Viennent ensuite les codes inventés. en-uk n'existe pas (le code du Royaume-Uni est gb), pas plus que les codes pays employés seuls. Une annotation avec un code invalide est simplement ignorée, sans message d'erreur nulle part : seul un audit technique du site la fait remonter.

Troisième famille : des balises qui pointent vers des URL qui ne répondent pas directement. Une variante qui redirige, une page passée en noindex, une URL non canonique. Les annotations hreflang doivent viser la version finale et indexable de chaque page ; si une redirection 301 s'est glissée dans la chaîne, corrigez l'URL déclarée plutôt que de laisser Google suivre le détour. J'ajoute un classique de migration : les URL relatives, qui cassent tout dès qu'un protocole ou un domaine change.

Vérifier que tout tient, dans la durée

Une implémentation hreflang n'est jamais acquise : chaque nouvelle page, chaque refonte, chaque changement d'URL peut la casser. Ma routine tient en trois gestes. Un crawl du site avec un outil qui contrôle la réciprocité des annotations, à relancer après chaque mise en production significative. Un œil sur le rapport de performance de la Search Console filtré par pays, où une version qui sort dans le mauvais marché se repère vite. Et si vous passez par le sitemap pour porter vos annotations, gardez-le irréprochable : mon guide sur le robots.txt et le sitemap XML couvre les fondamentaux.

Un dernier mot sur le contenu, parce que la technique ne fait pas tout. Une version traduite automatiquement et jamais relue n'est pas une version locale, c'est un doublon de mauvaise qualité qui peut tirer l'ensemble vers le bas. Mieux vaut trois langues bien servies que dix langues au rabais. La stratégie internationale la plus solide que je connaisse : n'ouvrir une version que lorsqu'on peut la maintenir au même niveau que l'originale.