SEO International et Checklist Hreflang

Le SEO International rend le contenu équivalent découvrable et utile à travers les langues et les régions. Cette checklist contrôle le système derrière ces pages : URLs, localisation, signaux alternatifs, devise, redirections, découvrabilité et mesure.

Checklist : préparation internationale et hreflang. Timebox : 2 à 4 jours ouvrés pour un modèle et jusqu’à cinq marchés ; ajoutez un jour pour chaque processus de paiement, régime juridique ou CMS sensiblement différent. Responsable : responsable SEO international, avec un ingénieur web et un relecteur de contenu local par langue. Autorité de publication : le responsable SEO international et le propriétaire du produit ou du marché conjointement.

Ceci n’est pas une relecture. Il s’agit de décider si les utilisateurs et les moteurs de recherche peuvent atteindre l’URL du bon marché et accomplir le parcours localisé.

Pourquoi cette checklist existe, et pourquoi elle intervient ici

L’implémentation internationale consomme les livrables des phases précédentes du processus SEO : marchés et objectifs prioritaires, accès aux analytics et à Search Console, base de référence technique, recherche de requêtes au niveau marché, architecture de l’information et inventaire des pages qui méritent des équivalents. Sans eux, les équipes traduisent en masse et créent des URLs pour des marchés que l’entreprise ne peut pas soutenir.

Exécutez-la après les décisions de marché et de modèle mais avant que les URLs localisées ne soient publiées ou soumises. Plus tôt rend le modèle d’URL spéculatif ; plus tard expose aux robots des canoniques contradictoires, des balises de retour incomplètes, des redirections forcées et des traductions superficielles.

La recherche marché décide où concurrencer ; l’inventaire décide ce qui nécessite un équivalent ; cette checklist décide comment chaque équivalent est traité, connecté, localisé et vérifié. Une modification rouvre chaque vérification dépendante.

Entrées et sorties

Les sorties constituent le contrat pour l’ingénierie, le contenu, les analytics et la QA. « Hreflang complet » n’est pas suffisant.

La checklist

Chaque élément a une raison, une règle, une méthode, un outil et une condition d’achèvement observable. Enregistrez RÉUSSI, ÉCHEC ou N/A avec des preuves pour chaque élément.

1. Confirmer le contrat marché-page

Pourquoi : la langue et le pays diffèrent. L’espagnol peut servir l’Espagne, le Mexique ou un public mondial, tandis qu’un pays peut nécessiter plusieurs langues. Un code locale n’est pas une stratégie de marché. Quoi : définissez l’audience et la capacité pour chaque locale, puis regroupez uniquement les pages ayant un objectif équivalent. Comment : cartographiez la langue, la région, l’intention, l’offre, le prix, l’exécution, le propriétaire légal et la voie de support ; marquez les pages sensiblement différentes comme « sans équivalent ». Outil : brief marché, recherche de requêtes, catalogue, exigences légales et inventaire. Fait quand : chaque URL a une audience et un propriétaire, chaque cluster a une intention équivalente et aucune cellule vide ne devient une traduction présumée.

2. Choisir délibérément une structure d’URL

Pourquoi : le modèle de routage contrôle la consolidation d’autorité, l’infrastructure, le reporting, l’indépendance opérationnelle et le risque de migration pendant des années. Quoi : choisissez entre les domaines de premier niveau par code de pays (ccTLD, comme example.de), les sous-domaines (comme de.example.com) ou les sous-dossiers (comme example.com/de/) en utilisant les conséquences plutôt que les préférences.

Comment : évaluez les trois modèles selon la propriété, les contraintes légales, l’hébergement, le CMS, les analytics, l’équité des liens, la migration, l’autonomie de publication et le coût d’exploitation sur cinq ans. N’utilisez pas les paramètres de requête comme structure de locale principale car ils sont faciles à supprimer, dupliquer et mal gérer dans les canoniques et les liens. Outil : enregistrement de décision d’architecture, inventaire DNS et CMS, plan analytics et modèle de redirection. Fait quand : un modèle et une grammaire de routage sont approuvés, chaque exception a un propriétaire, et des exemples d’URLs pour la page d’accueil, la catégorie, l’article, le produit et les états de page indisponible se résolvent sans ambiguïté.

3. Localiser l’expérience, pas seulement les phrases

Pourquoi : la traduction change les mots ; la localisation rend l’expérience précise et naturelle pour un marché. Un résultat automatique littéral peut manquer l’intention, la terminologie, les unités, le langage fiscal, les signaux de confiance ou les appels à l’action. Quoi : adaptez le parcours complet, en n’utilisant la traduction automatique que comme ébauche lorsque la politique le permet. Comment : un relecteur local vérifie les requêtes, métadonnées, textes, médias, dates, unités, prix, mentions légales, formulaires, validation, paiement et support. Recherchez des mots-clés locaux plutôt que de les traduire. Outil : guide de locale, recherche marché, mémoire de traduction, navigateur de préproduction et feuille d’acceptation. Fait quand : aucun fragment de langue source ne subsiste, les affirmations sont valides localement, le relecteur complète un parcours de conversion et son nom, sa date et son résultat sont enregistrés.

4. Construire des clusters hreflang complets

Pourquoi : un signal alternatif unidirectionnel est ambigu ; la destination doit confirmer la relation. Hreflang est l’attribut HTML qui identifie les alternatives de langue ou de langue-région, pas une instruction de redirection ni un substitut à la localisation. Quoi : faites en sorte que chaque membre indexable se liste lui-même et chaque autre membre valide, avec une balise de retour correspondante depuis chaque destination. Utilisez les codes de langue ISO 639-1 lorsque disponibles, suivis d’un code de région ISO 3166-1 alpha-2 optionnel, comme en, en-GB ou pt-BR ; n’utilisez jamais un pays seul. Comment : générez les balises à partir du manifeste du cluster plutôt que de modifier les modèles à la main. Comparez les URLs absolues finales sous forme d’ensembles et validez le statut, la syntaxe du code, l’auto-référence et la réciprocité. Outil : générateur de manifeste, robot d’exploration, HTML rendu, client HTTP et validateur hreflang. Fait quand : 100 % des membres indexables du cluster retournent 200, listent l’ensemble de membres identique, s’incluent eux-mêmes, utilisent des codes valides et n’ont aucune balise de retour manquante ou contradictoire.

5. Aligner les canoniques, l’indexabilité et les signaux alternatifs

Pourquoi : hreflang associe des alternatives, tandis qu’une canonique inter-langue les consolide. Ensemble, ces instructions entrent en conflit. Une URL canonique identifie le duplicata préféré ; l’indexabilité signifie qu’une page est éligible pour un index de recherche. Quoi : donnez à chaque page localisée une auto-canonique et ne regroupez que les URLs indexables retournant 200. Comment : comparez la canonique déclarée et celle sélectionnée par Google, les directives robots, le statut, la cible finale et la destination alternative. Supprimez les URLs noindex, redirigées, bloquées, soft-404 et non canoniques jusqu’à correction. Outil : robot d’exploration, en-têtes, source, testeur de robots et Inspection d’URL. Fait quand : chaque membre est crawlable et indexable avec une auto-canonique, et aucune alternative ne redirige, n’a d’erreur ou ne canonicalise ailleurs.

6. Utiliser x-default uniquement pour un véritable fallback

Pourquoi : les utilisateurs non appariés ont besoin d’une destination stable, mais inventer une valeur par défaut peut envoyer les moteurs de recherche vers un marché commercial arbitraire. x-default est une valeur hreflang pour un sélecteur de langue, une page globale ou un fallback qui n’est pas ciblé vers une locale listée. Quoi : ajoutez exactement un x-default par cluster uniquement lorsqu’une telle page de fallback existe réellement. Comment : choisissez délibérément le sélecteur global ou le fallback neutre, incluez-le réciproquement dans le cluster et vérifiez qu’il ne force pas les visiteurs à aller ailleurs avant de pouvoir choisir. Outil : manifeste de cluster, HTML rendu, navigateur avec cookies vierges et robot d’exploration. Fait quand : chaque cluster concerné a un x-default réciproque avec un objectif documenté ; les clusters sans fallback valide n’en ont aucun.

7. Rendre la découverte des locales cohérente

Pourquoi : les balises alternatives ne remplacent pas les chemins de crawl. Une page qui n’existe que dans une balise ou un contrôle de formulaire peut rester difficile à découvrir pour les utilisateurs et les robots. Un plan de site XML est une liste d’URLs lisible par machine, tandis que la crawlabilité signifie que les robots peuvent atteindre et lire ces URLs. Quoi : exposez les alternatives de locale via des liens crawlables et soumettez des URLs canoniques complètes dans les plans de site. Utilisez une seule méthode d’implémentation pour hreflang — HTML, en-têtes HTTP pour les fichiers non HTML ou plans de site XML — sauf si l’équipe peut prouver que plusieurs méthodes restent identiques. Comment : crawlez depuis chaque page d’accueil du marché, inspectez les sélecteurs comme des liens ordinaires, comparez les plans de site avec le manifeste et vérifiez que la navigation ne supprime jamais la page équivalente courante inutilement. Outil : robot d’exploration, analyseur de plan de site, navigateur sans JavaScript et graphe de liens. Fait quand : chaque URL localisée prioritaire a au moins un chemin interne crawlable, chaque entrée de plan de site est canonique et retourne 200, et toutes les sources hreflang implémentées déclarent des clusters identiques.

8. Garder la devise séparée du ciblage de locale

Pourquoi : la langue, la destination et la devise sont liées mais pas interchangeables. Quoi : affichez la devise et les conditions correctes sans utiliser la devise seule pour créer ou changer une URL de locale. Comment : définissez l’inclusion de taxe, la liste de prix ou le taux de change, l’arrondi, l’heure de mise à jour et le comportement en cas de produit indisponible. Maintenez un état de prix crawlable stable par marché ; traitez la devise choisie par l’utilisateur comme une présentation sauf si elle représente un marché distinct. Outil : catalogue, service de tarification, règles fiscales, données structurées et test d’achat. Fait quand : la devise est explicite, la page et le paiement concordent, les qualificatifs de taxe et de livraison apparaissent, les données structurées correspondent et le changement de devise ne modifie pas la canonique ou l’identité hreflang.

9. Remplacer les redirections géolocalisées forcées par un choix

Pourquoi : la localisation par adresse IP et la langue du navigateur sont des indices imparfaits. Les redirections forcées peuvent piéger les robots sur un seul marché, empêcher les voyageurs et les utilisateurs multilingues de choisir, créer des boucles de redirection et rendre une URL partagée directement inaccessible. Quoi : gardez chaque URL de locale directement accessible et proposez une suggestion de marché désactivable au lieu de rediriger uniquement depuis l’IP ou Accept-Language. Comment : testez des sessions vierges depuis plusieurs emplacements, des états connecté et déconnecté, des agents utilisateur de robots, des cookies désactivés et une préférence stockée explicite. Préservez la route équivalente de la page courante lorsqu’un utilisateur change de marché ; si aucun équivalent n’existe, expliquez le fallback. Outil : test de localisation par navigateur, client HTTP, règles edge/CDN, journaux serveur et tests de redirection automatisés. Fait quand : une première requête vers chaque URL localisée retourne sa page 200 prévue, les robots ne sont pas redirigés par géographie, les choix explicites persistent, les utilisateurs peuvent les annuler et aucune boucle ou chaîne à plusieurs sauts ne se produit.

10. Valider les modèles et URLs représentatives avant le passage à l’échelle

Pourquoi : une page d’accueil correcte ne prouve qu’un seul modèle. Les défauts internationaux se cachent souvent dans la pagination, les variantes de produits, les traductions manquantes, les routes facetées et les pages indisponibles dans un marché. Quoi : testez chaque modèle distinct et état limite avant la publication en masse. Comment : sélectionnez au moins 10 URLs par marché, incluant la page d’accueil, les pages les plus demandées, chaque modèle, un produit ou service indisponible, une route paginée ou filtrée le cas échéant et une URL sans alternative. Comparez la source, le rendu, la réponse, la canonique, hreflang, la navigation, la langue du contenu et le parcours de conversion. Outil : crawl de préproduction, navigateur, diff de manifeste, client HTTP et feuille de cas de test. Fait quand : chaque modèle distinct et état limite requis est représenté, toutes les URLs échantillonnées réussissent chaque règle applicable et tout échec au niveau du modèle bloque toutes les URLs générées par ce modèle.

11. Établir une mesure au niveau marché

Pourquoi : le trafic agrégé peut augmenter pendant qu’un marché cible perd en visibilité, et un nouveau dossier peut sembler sain uniquement parce que la langue par défaut le domine. Quoi : créez des dimensions de reporting pour le marché, la route linguistique, le répertoire, le pays, l’appareil, la conversion et le revenu avant le lancement. Comment : vérifiez les pages vues et événements analytics en préproduction, connectez chaque propriété Search Console requise ou propriété de domaine, annotez l’heure de lancement et sauvegardez une base de référence pour la même période et le même ensemble de requêtes. Outil : débogueur analytics, Search Console, rapports pays et répertoires d’AmICited et registre de lancement. Fait quand : les sessions de test apparaissent sous le marché et la route prévus, les conversions conservent le marché et la devise, toutes les propriétés sont accessibles au propriétaire et une base de référence datée existe avant la publication.

12. Effectuer une vérification en live et conserver la propriété

Pourquoi : la préproduction ne peut pas prouver le DNS, le CDN, les redirections de production, les canoniques finales ni ce que Google sélectionne après la découverte. Quoi : répétez les vérifications critiques immédiatement après le déploiement et assignez un suivi plutôt que de considérer le lancement comme une fin. Comment : crawlez l’échantillon de production, soumettez les plans de site mis à jour, inspectez les URLs prioritaires, vérifiez les journaux et les analytics, puis planifiez des vérifications après la découverte et après la première fenêtre de reporting significative. Outil : robot d’exploration de production, AmICited, Search Console, journaux serveur et suivi des incidents. Fait quand : la production correspond au manifeste approuvé, aucun échec bloquant ne subsiste, chaque observation a un horodatage et chaque vérification de données différée a un propriétaire et une date plutôt qu’un « surveiller » sans échéance.

Outils dans AmICited

AmICited fournit des preuves issues de Search Console pour la découverte, le lancement et le suivi. Il ne remplace pas un relecteur local ni un crawl complet des balises réciproques.

1. Ouvrez Pays et Appareils dans le rapport pays et appareils . Examinez les pays avec des impressions mais une faible position ou un faible taux de clics avant de supposer que la demande est absente.

2. Utilisez Répertoires Google Search dans le rapport de répertoires pour comparer les dossiers de locale et explorer les modèles faibles.

3. Ouvrez Plans de site et Indexation dans le rapport plans de site et indexation . Confirmez le téléchargement sans avertissements ni erreurs, puis demandez l’indexation des URLs prioritaires. Les demandes ne peuvent pas rendre indexables des URLs bloquées.

4. Vérifiez des URLs représentatives dans Inspection d’URL dans le rapport d’inspection d’URL . Comparez les canoniques déclarées et sélectionnées par Google. Sa liste de couverture est un échantillon, pas un audit hreflang.

Règles de décision

« Mauvais » est une condition qui bloque la publication ou déclenche une correction, pas un sentiment sur la qualité de la traduction.

Les écarts de taux de clics et de position sont diagnostiques, pas des échecs automatiques. Comparez des pages et des périodes comparables ; aucun pourcentage universel ne prouve un défaut de localisation.

Livrable : le pack de lancement international

Remettez un dossier versionné ou un ensemble de tickets contenant au minimum ces éléments :

01-url-model.md
- Décision, alternatives rejetées, grammaire de routage, propriétaires, migration et rollback

02-market-page-matrix.csv
- marché, langue, région, URL source, URL localisée, intention, disponibilité, relecteur

03-hreflang-manifest.csv
- URL, code, auto-canonique, alternatives, x-default, statut, indexabilité, résultat

04-localization-acceptance.csv
- URL, champ/parcours, relecteur, résultat, preuve, exception

05-redirect-selector-spec.md
- logique de suggestion, choix explicite, persistance, comportement des robots, comportement sans équivalent

06-launch-verification.csv
- URL, déployé le, résultat de crawl, état du plan de site, état d'inspection, preuve analytics, propriétaire

Décision : RÉUSSI — PUBLIER | ÉCHEC — SUSPENDRE
Date de révision suivante et propriétaire désigné :

Conciliez le manifeste avec la production. Stockez les exceptions avec leur raison, risque, approbateur, date d’expiration et responsable de correction. Un changement de modèle d’URL, de modèle de page, d’ensemble de locales, de canonique ou de politique de redirection rouvre les vérifications concernées.

Ce qui peut mal tourner

• Chaque page source est traduite automatiquement. Des pages sans demande locale, avec des produits indisponibles et des affirmations non prises en charge sont publiées parce que la traduction a été confondue avec la sélection de marché.
• La langue par défaut devient canonique partout. Les moteurs de recherche reçoivent simultanément des instructions de consolidation et d’alternative ; les URLs localisées disparaissent ou la mauvaise URL est sélectionnée.
• Seule la page source liste les alternatives. Les balises de retour manquantes rendent le cluster incomplet même si un modèle semble correct.
• Les codes pays sont utilisés comme langues. Des valeurs telles que UK ou BR n’expriment pas une paire langue-région ; des exemples valides sont en-GB et pt-BR.
• x-default pointe vers le plus grand marché. Une page commerciale d’un pays est étiquetée comme fallback neutre et reçoit des utilisateurs qu’elle ne peut pas servir correctement.
• Le sélecteur est uniquement en JavaScript. Les utilisateurs voient une liste déroulante, mais les robots n’ont pas de liens ordinaires pour découvrir les alternatives.
• La localisation IP force la route. Les robots et les voyageurs ne peuvent pas conserver une URL directement demandée, les caches varient par emplacement et des boucles de redirection apparaissent entre les règles edge et applicatives.
• La devise crée des URLs de locale en double. Les paramètres ou chemins se multiplient tandis que le contenu, les canoniques et les prix structurés divergent.
• La page d’accueil passe et le passage à l’échelle commence. Les modèles de produit, catégorie, pagination et sans équivalent émettent différents ensembles de balises à travers des milliers d’URLs.
• Le reporting commence après le lancement. Aucune base de référence ni annotation n’existe, donc les équipes ne peuvent pas séparer les effets de l’implémentation de la saisonnalité, de la demande de marque ou des versions non liées.

Phase suivante

Cette checklist remet son pack de lancement à la checklist de QA pré-publication . La QA a besoin du modèle d’URL, du candidat de production, du manifeste, des approbations de localisation, des modifications de plan de site et de redirection, de l’ensemble de test, de l’autorité de publication et des exceptions. Elle vérifie ces enregistrements avant la publication.

Après le lancement, le responsable SEO international conserve le manifeste. Les nouvelles pages, les produits retirés, les ajouts de langue, les migrations de routage et les modifications de canonique sont des changements de cluster, pas des modifications de page isolées. Revalidez les clusters concernés, mettez à jour les plans de site, inspectez les URLs prioritaires et annotez le reporting à chaque fois.

FAQ

Questions fréquemment posées

Rendre le premier lancement international mesurable

Utilisez le rapport pays et appareils pour capturer la base de référence du marché, puis publiez uniquement lorsque le modèle d’URL, le relevé de localisation, le manifeste du cluster, les redirections, le plan de site et l’échantillon représentatif de production réussissent tous. Le CTA de conclusion de la mise en page academy fournit la route suivante vers AmICited.