Générez des balises hreflang pour vos pages multilingues

Vous renseignez chaque code régional et son URL absolue, ajoutez au besoin une destination générale x-default, puis recevez les liens individuels et un bloc HTML complet. L’outil contrôle la syntaxe, normalise la casse conventionnelle, refuse les doublons et protège les attributs HTML. Il convient aux sites multilingues, catalogues internationaux, portails documentaires et chaînes éditoriales qui doivent déclarer leurs variantes de façon cohérente.

Constituez une correspondance complète

Créez une ligne pour chaque page équivalente appartenant au même ensemble multilingue ou multirégional. Chaque ligne exige un code de langue et une URL HTTP ou HTTPS absolue. Un code simple comme fr ou en convient lorsqu’une page sert toutes les personnes parlant cette langue. Ajoutez une région, par exemple fr-CA ou en-GB, si les prix, la disponibilité, l’orthographe ou les conditions juridiques diffèrent. Une sous-étiquette de script à quatre lettres permet de distinguer les systèmes d’écriture, comme zh-Hans ou sr-Latn. Le générateur accepte une langue de deux ou trois lettres, un script facultatif et une région facultative de deux lettres ou trois chiffres. Il normalise leur casse habituelle afin d’éviter un balisage incohérent. Incluez la page actuelle et toutes ses variantes : un ensemble hreflang doit se décrire entièrement. Choisissez des URL canoniques, indexables et propres au public annoncé. L’ordre des lignes reste inchangé, ce qui rend les blocs stables et faciles à relire dans le contrôle de versions.

Choisissez x-default avec discernement

Utilisez le champ x-default facultatif pour la page destinée aux visiteurs auxquels aucune version linguistique ou régionale ne correspond. Il peut s’agir d’un sélecteur de langue, d’un accueil international ou d’une version neutre invitant à choisir. Ne saisissez pas x-default comme une ligne ordinaire : le champ dédié évite les déclarations ambiguës ou en double et place toujours ce recours après les liens localisés. Vous pouvez le laisser vide si aucune destination générale n’est pertinente. Le HTML rendu contient un élément link par correspondance et, si vous le demandez, un élément x-default supplémentaire. Placez le bloc complet dans le head de chaque page de l’ensemble, ou envoyez des en-têtes Link équivalents si votre application gère les variantes au niveau HTTP. Veillez à la réciprocité : chaque page doit mentionner elle-même et les mêmes variantes. L’outil produit la déclaration, mais ne vérifie ni les liens distants, ni l’indexabilité, ni les redirections. Confiez ces contrôles à un audit ou à une exploration distincte.

Validez, publiez et entretenez le résultat

Les codes mal formés sont refusés au lieu d’être produits silencieusement. Vous repérez ainsi les traits de soulignement, espaces extérieurs, langues absentes, sous-étiquettes supplémentaires non prises en charge ou x-default placé dans la liste. Les doublons sont également refusés après normalisation : en-us et en-US ne peuvent donc pas créer deux destinations concurrentes. Les URL doivent être absolues et employer HTTP ou HTTPS ; les chemins relatifs et autres protocoles ne désignent pas des pages explorables. Une fois l’entrée validée, copiez le champ html dans votre modèle ou consommez le tableau links si votre framework génère lui-même les métadonnées du head. Chaque enregistrement expose la valeur hreflang normalisée, l’URL originale et la balise achevée. Régénérez le bloc lorsqu’une route change, qu’un marché ouvre ou que la destination générale déménage. Considérez cette correspondance comme une configuration durable du site. En automatisation, conservez l’entrée avec les routes et comparez le résultat au déploiement. Chaque requête API coûte $0.002 ; le navigateur sert aux besoins ponctuels et l’API déterministe aux publications répétables.