Auditer les balises hreflang pour le SEO international : le guide complet

Un mail de la directrice marketing d'une enseigne de cosmétiques : "Google indexe la version allemande de notre site chez les Autrichiens. On perd toute la Suisse." Le site en question avait six versions linguistiques, toutes propres. Sauf que trois d'entre elles pointaient vers une URL qui redirigeait en 302 vers la racine française. Le hreflang dit "voici la version allemande pour l'Autriche". La redirection dit "retour au français". Google n'a aucune raison de croire le premier quand la seconde crie plus fort.

Auditer les balises hreflang pour le SEO international, ce n'est pas vérifier que les balises existent. C'est vérifier que la chaîne entière — déclaration, cible, réponse serveur — tient debout. La plupart des audits s'arrêtent à l'étape 1 et déclarent victoire.

Ce que Google attend vraiment d'une déclaration hreflang

La balise rel="alternate" hreflang="..." est une déclaration d'intention. Elle dit à Google : "pour un utilisateur qui parle telle langue dans telle région, voici l'URL à servir". Google peut suivre cette recommandation, ou l'ignorer s'il détecte une contradiction.

Les règles techniques sont peu nombreuses, mais leur non-respect invalide l'ensemble du groupe.

Les cinq règles non négociables

1. Réciprocité : si la page A déclare B comme alternative, B doit déclarer A en retour. Une seule omission casse le lien dans un sens.
2. Auto-référence : chaque page doit se citer elle-même dans le groupe. Un oubli fréquent sur les sites générés par template.
3. Codes valides : en-GB, pas en-uk. ja, pas jp. Le code pays suit la norme ISO 3166-1 alpha-2, la langue suit ISO 639-1.
4. Cohérence de cible : la balise hreflang pointe vers une URL canonique, en 200, sans redirection.
5. x-default désigné une fois : une seule URL du groupe porte hreflang="x-default".

Le point 4 est celui qui saute le plus souvent aux yeux lors d'un audit sérieux. Un site e-commerce français, il y a deux ans, avait migré ses URL allemandes sans mettre à jour ses hreflang. Pendant quatre mois, chaque balise de-DE pointait vers une 301. Google a fini par retirer la version allemande de l'index. Le trafic organique depuis l'Allemagne a chuté de 62 %. Silence radio côté analytics pendant trois semaines, personne ne regardait ce segment.

La procédure d'audit réellement outillée étape par étape

Voici la méthode que j'utilise maintenant, après avoir fait l'erreur de valider un site à l'œil pendant des mois. Spoiler : ça ne marche pas. Pas au-delà de 40 URL.

Étape 1 — un crawl complet, pas un échantillon

Deux outils font le travail : Screaming Frog (version payante, indispensable au-delà de 500 URL) ou un crawl Sitebulb. On configure le rendu JavaScript activé si le site en dépend. Sans ça, vous ratez toutes les balises injectées côté client.

Le rapport à surveiller : "Hreflang" dans l'onglet des onglets de crawl. Il expose quatre colonnes qui comptent vraiment : hreflang, hreflang URL, hreflang return links, hreflang validation.

Étape 2 — croiser avec la Search Console

Dans GSC, rapport "Ciblage international". Il remonte trois catégories d'anomalies : "Aucune version de la page avec balise canonique sélectionnée", "Balise hreflang non valide", "Valeur hreflang erronée". Ce rapport agrège les signaux côté Google, ce qui complète bien le crawl côté serveur.

Un détail pratique : ce rapport a un délai de latence. Ne vous attendez pas à voir une correction apparaître le lendemain. Comptez plusieurs jours à quelques semaines selon la taille du site.

Étape 3 — vérifier les redirections et les canoniques

Pour chaque URL cible déclarée dans un hreflang, on vérifie :

• Code HTTP = 200
• Aucune redirection, même temporaire
• La balise canonical pointe vers elle-même, pas vers la version française
• Le contenu servi est bien dans la langue annoncée

La contradiction canonique vs hreflang est la plus vicieuse. Une page es-MX qui déclare une canonical vers es-ES envoie un signal contradictoire : "je suis la version mexicaine" et "je ne suis qu'une copie de la version espagnole". Google tranche en faveur de la canonical dans la majorité des cas que j'ai observés.

Prioriser les erreurs : ce qui bloque vraiment l'indexation

Toutes les erreurs hreflang ne se valent pas. Traiter une majuscule manquante avant une réciprocité cassée, c'est comme repeindre la porte d'une maison qui n'a plus de toit.

Type d'erreur	Impact sur l'indexation	Priorité
Réciprocité manquante	Élevé — le lien est ignoré dans un sens	1
Canonical conflictuelle	Élevé — la version est consolidée vers une autre	1
Cible en redirection ou en 404	Élevé — la balise est morte	1
Code langue/région invalide	Moyen — la balise est rejetée, le groupe reste partiel	2
Auto-référence absente	Moyen — affaiblit la clarté du groupe	2
x-default manquant	Faible à moyen — aucune version par défaut désignée	3
Casse incohérente (EN-gb)	Faible — Google tolère, mais le signal est bruité	4

Je classe systématiquement en priorité 1 tout ce qui touche à la réciprocité, aux canoniques et aux redirections. Le reste attend. Un audit qui traite tout à plat prend deux fois plus de temps et corrige des choses sans effet mesurable.

Les cas limites que personne ne documente

Hreflang sur pages paginées

Question qui revient : faut-il déclarer hreflang sur /page/2/, /page/3/ d'une catégorie ? La réponse pragmatique : non, sauf si la pagination est indexable et génère du trafic. Dans 90 % des cas que j'ai vus, les pages paginées sont en noindex, follow ou en canonical vers la page 1. Déclarer hreflang dessus crée du bruit et peut générer des faux positifs dans votre audit.

Contenu quasi-dupliqué entre régions

Le cas fr-FR vs fr-BE pose un problème réel : si les contenus sont identiques à 95 %, Google peut consolider et ne garder qu'une version. La solution que j'applique : s'assurer qu'il y a un vrai delta régional (prix, devises, disponibilité, mentions légales, exemples localisés). Sans ce delta, mieux vaut une seule version fr sans ciblage régional.

x-default sur pages sans équivalent

Une page blog uniquement disponible en anglais n'a pas besoin d'x-default ni de hreflang du tout. Le piège classique : mettre x-default sur chaque page par réflexe, y compris celles qui n'ont pas de groupe. Bilan : des dizaines d'auto-références inutiles qui polluent les rapports.

Interaction avec le rendu JavaScript

Si vos balises hreflang sont injectées par du JS côté client, Google les voit — mais avec un délai. Et surtout, vos outils de crawl ne les verront pas si le rendu JS est désactivé. J'ai perdu une demi-journée à auditer un site SPA avant de comprendre que les balises étaient bien là, juste invisibles à mon crawler configuré en mode HTML brut.

Ce qu'il faut mesurer après l'audit

Corriger ne suffit pas. Il faut vérifier que les corrections ont produit un effet dans l'index.

Trois indicateurs à suivre dans les semaines suivant la mise en production :

• Le nombre d'URL indexées par version linguistique dans GSC (rapport Couverture)
• La disparition progressive des erreurs dans "Ciblage international"
• Les impressions et clics par pays dans le rapport Performances, filtrés par répertoire de langue

Sur un site que j'ai audité l'an dernier (12 versions linguistiques, environ 40 000 URL), les erreurs de réciprocité concernaient 2 300 URL. Après correction, il a fallu six semaines pour voir les premiers effets visibles côté indexation. Le trafic depuis l'Espagne et l'Italie a progressé de 18 % sur le trimestre suivant. Pas spectaculaire, mais net et durable.

À quelle fréquence auditer ?

Mon rythme :

• Trimestriel pour un site stable, avec un crawl complet
• Après chaque migration d'URL ou de CMS, sans exception
• Après chaque ajout de version linguistique

Les migrations sont le moment où tout casse. J'ai vu trois refontes de site casser leur hreflang en silence, parce que le nouveau template ne générait plus les balises pour les langues secondaires. Personne ne s'en est aperçu pendant deux mois.

Le vrai angle mort de la plupart des audits

La majorité des audits hreflang que je vois passer traitent la balise comme un objet isolé. Ils vérifient la syntaxe, comptent les erreurs, produisent un rapport. Puis on corrige les balises et on considère le sujet clos.

Sauf que la balise ne vit pas seule. Elle vit dans un écosystème de signaux : canonical, redirections, contenu réel, sitemap, en-têtes HTTP, rendu JS. Un audit qui ne croise pas ces couches produit un rapport rassurant qui peut masquer un désastre d'indexation.

La question que je pose maintenant avant tout audit hreflang : est-ce que chaque URL déclarée est réellement servie, dans la bonne langue, sans détour ? Si la réponse est oui, la balise fera son travail. Si la réponse est non, aucune balise correcte ne sauvera la situation.

Le jour où votre rapport d'audit sera propre en quinze minutes, méfiez-vous. C'est souvent le signe que vous n'avez pas regardé au bon endroit.