Choisissez les locales à partir du contenu réel et des engagements opérationnels
Une locale est la langue et, seulement quand cela importe, le public régional d’une page. Tenez une matrice du type de page, de la langue, de la région, du propriétaire, des différences de contenu, du schéma d’URL et du fallback. Ajoutez une version régionale seulement lorsque son contenu principal ou ses conditions commerciales diffèrent réellement et que quelqu’un peut la maintenir à jour ; une page générique en langue est souvent le meilleur choix.
Ne traduisez pas seulement les en-têtes et pieds de page autour d’un contenu principal inchangé et appelez cela du localisé. Google met en garde contre le risque d’expérience médiocre et de résultats dupliqués liés aux seules traductions de boilerplate. Passez en revue les textes prioritaires, les prix, la disponibilité, les politiques, le support et les messages transactionnels. Si une page ne peut pas encore être prise en charge, omettez-la plutôt que publier une coquille trompeuse.
Enregistrez le code prévu, le modèle d’URL public, le propriétaire, la cible canonical, le fallback et l’état de lancement dans un tableau gouverné unique.
Utilisez des URLs stables et laissez les personnes choisir
Donnez à chaque version linguistique une URL directe que le navigateur et l’explorateur peuvent demander. Google recommande des URL distinctes plutôt que de changer la langue via des cookies ou des réglages du navigateur. Les domaines pays, sous-domaines et sous-répertoires peuvent fonctionner ; choisissez le schéma que votre équipe peut gouverner de façon cohérente. Google considère les paramètres d’URL comme non recommandés pour la segmentation basée sur l’URL.
Affichez un choix de langue ou de région et conservez le visiteur sur la version sélectionnée. Google déconseille les redirections automatiques basées sur une langue devinée et indique que les changements dynamiques peuvent empêcher la découverte des variantes. N’utilisez pas la localisation IP comme mécanisme décisif ; Google indique que c’est difficile, généralement peu fiable, et cela peut limiter le crawl. Préservez les URLs directes et un moyen facile de revenir en arrière.
Ouvrez chaque URL de locale dans une session propre et confirmez qu’elle sert cette version sans rebond basé sur la localisation.
Construisez des clusters hreflang complets et valides
Un cluster hreflang relie des URL locales équivalentes. Google prend en charge les éléments link HTML, les en-têtes HTTP Link pour les réponses non-HTML, ou les entrées de sitemap XML, et traite ces méthodes comme équivalentes. Choisissez celle que votre processus de déploiement peut générer et auditer. Chaque URL alternative doit être pleinement qualifiée, y compris https, et résoudre vers la page publique prévue.
Sur chaque page équivalente, publiez le même ensemble : une auto-référence et toutes les alternatives prises en charge. Google indique que les balises peuvent être ignorées quand les pages ne se pointent pas mutuellement et identifie les liens de retour manquants comme une erreur courante. Générez les clusters à partir de données partagées, pas de modèles édités manuellement. Si une page n’est pas disponible dans une locale, n’inventez pas une correspondance approximative juste pour remplir la grille.
Pour chaque paire listée, vérifiez que les deux pages exposent le même ensemble d’alternatives, y compris leur propre URL.
Utilisez la méthode de l’en-tête HTTP Link pour les PDF localisés quand le balisage head HTML n’est pas disponible.
Sélectionnez les balises de langue en pensant à l’implémentation de recherche
Les balises de langue sont des identifiants tels que en, en-GB ou zh-Hant. BCP 47 est le cadre IETF recommandé, et le registre IANA Language Subtag Registry est le registre de référence que W3C oriente aux auteurs. Commencez par une langue principale, puis ajoutez script ou région uniquement lorsqu’ils distinguent le contenu. Le W3C conseille de garder les balises aussi courtes que la distinction nécessaire le permet.
Pour hreflang Google, suivez les règles de codes prises en charge par Google, pas toutes les balises syntaxiquement valides BCP 47. Google exige d’abord une langue, jamais une région seule, et documente les codes ISO 639-1 pour les langues avec des régions optionnelles ISO 3166-1 Alpha-2. Il indique explicitement que es-419 n’est pas pris en charge pour hreflang. Vérifiez les codes lors de l’implémentation et rejetez les valeurs improvisées dans les contrôles de déploiement.
N’utilisez en-GB que lorsque la version Royaume‑Uni diffère de façon significative ; sinon une version générique en est plus simple.
Maintenez canonicals, fallback et signaux de contenu compatibles
La canonicalisation choisit une URL préférée parmi des URL dupliquées ou très similaires ; hreflang identifie des alternatives intentionnelles. Pour des pages locales indépendantes, utilisez un canonical auto-référent ou un canonical dans la même langue. Google recommande un canonical en même langue ou le meilleur substitut disponible. Un canonical inter-langue peut consolider l’alternative que vous aviez l’intention de présenter.
Utilisez x-default pour les personnes dont la langue du navigateur ne correspond à aucune version listée, en particulier avec un sélecteur de langue ou de pays. C’est un fallback, pas un remplacement des vraies alternatives. Décidez s’il s’agit d’un sélecteur neutre ou d’une page en langue par défaut, rendez-le utilisable et évitez les boucles de redirection automatiques. Gardez le contenu principal visible de chaque page clairement dans une langue unique.
Comparez l’URL demandée, l’URL finale, le canonical, l’indexabilité, les cibles hreflang et l’entrée du sitemap sur chaque échantillon.
Testez le déploiement comme un changement de routage et de contenu
Avant le déploiement, échantillonnez chaque type de modèle : accueil, catégorie, commercial, éditorial, aide et fichiers localisés. Inspectez le head délivré, les en‑têtes ou le sitemap selon la méthode choisie. Confirmez les réponses publiques, les URL finales HTTPS, les alternances auto‑et réciproques, les cibles canonical, le contenu local visible, un sélecteur fonctionnel et l’absence de noindex ou de blocage robots accidentel.
Après la mise en ligne, inspectez des pages représentatives dans Search Console. Son test en direct vérifie si Google peut accéder à une page actuelle ; le rapport d’indexation peut montrer le canonical sélectionné. Le test en direct ne peut pas prédire le canonical choisi ni garantir l’indexation. Tenez un journal de release daté avec les clusters testés, les exceptions, les propriétaires et les preuves de retest.
Bloquez la mise en ligne lorsqu’une page prioritaire redirige incorrectement, a une paire réciproque cassée, est en conflit avec son canonical ou ne peut pas être sélectionnée.
Versionnez la configuration des locales et conservez la carte d’URL et d’annotations antérieure pour un retour en arrière sûr des modèles partagés.