Hreflang sur les domaines régionaux : une liste de contrôle pour une migration en toute sécurité

Lancements échelonnés

Les équipes demandent souvent si l'hreflang peut être mis en ligne sur un site avant l'autre. C'est possible.

Google ignorera simplement les balises jusqu'à ce que les deux côtés se confirment mutuellement. Aucun dommage. L'ordre retarde simplement le bénéfice. Conservez les balises du premier site valides et ne publiez pas de jeux partiels qui nomment des URL qui n'existent pas encore. Lorsque vous vérifiez les backlinks des sites sur les deux domaines, vous voyez également quel hébergeur régional est déjà préféré par le monde extérieur, ce qui est une preuve utile pour décider quelle URL devient x-default.

Deux cas concrets

Imaginons que vous gériez un site allemand et un site UK sur deux domaines, avec une redirection 301 de la racine UK vers un dossier /uk/ ajouté il y a quelque temps. L'équipe souhaite maintenant supprimer cette règle et demande comment conserver l'équité des liens.

Récupérez d'abord toppages pour les deux hébergeurs. Si la plupart des liens externes pointent vers la racine, la racine doit désormais servir une page réelle, avec hreflang et un auto-canonical, ou rediriger vers la meilleure correspondance régionale. Effectuez le test avec un script, conservez l'ancienne règle dans le contrôle de version, et examinez le résultat après le prochain rafraîchissement mensuel de notre index.

Le deuxième cas est plus petit. Un site Blogger ou Squarespace migre vers un domaine personnalisé. Redirigez chaque ancien chemin un par un, car la première partie de l'URL change tandis que le slug reste souvent identique. Consultez la recette de la carte de redirection pour la boucle de test, et conservez l'ancienne propriété vérifiée dans Search Console afin de pouvoir surveiller la couverture sur les deux.

Au-delà de hreflang et des canonicals : que vérifier encore entre pays

Hreflang et canonicals sont les balises que les gens vérifient en premier, et ils ne sont pas les seuls endroits où une configuration transfrontalière peut échouer. Les redirections dépendant de la localisation, un sélecteur de langue qui envoie les robots d'indexation vers une locale, et un sitemap listant une seule version changent tous l'URL que Google considère comme la page d'accueil pour chaque marché.

Passez en revue ces points après le passage des balises. Chacun peut annuler silencieusement une balise qui semble correcte dans le modèle.

Redirections géographiques et sélecteurs de langue

Une redirection qui sélectionne une locale en fonction de la localisation du visiteur peut envoyer Googlebot vers un pays sans jamais lui montrer les autres. Le robot ne voit alors qu'une seule version, et les alternates ne sont pas récupérés. Les redirections forcées sont une source courante de ce problème, testez donc avec un agent utilisateur de crawler et, si possible, depuis un deuxième pays.

Un sélecteur de langue doit lier vers la même page dans chaque locale. S'il ne lie qu'à la page d'accueil de l'autre site, les alternates perdent leurs liens internes et deviennent plus difficiles à trouver.

Sitemaps contenant les alternates

Un sitemap XML peut lister les URL alternées de chaque marché à un seul endroit, afin que l'ensemble soit lu ensemble plutôt que page par page. Maintenez cette liste alignée avec les balises sur les pages elles-mêmes.

Supprimez toute locale qui renvoie une redirection ou un noindex du sitemap, sinon les deux sources seront en désaccord sur les versions existantes.

Plugins promettant une automatisation

Les plugins peuvent générer hreflang pour de nombreux sites, et ils constituent un bon point de départ. Un plugin ne peut pas savoir quelle URL régionale est la bonne cible, ou si une redirection ailleurs le contredit.

Vérifiez la sortie du plugin par rapport à une analyse plutôt que de faire confiance à l'écran des paramètres. L'analyse est la seule vue qui montre ce qu'un bot reçoit réellement.

Exécution de deux domaines en parallèle pendant un certain temps

Une exécution parallèle maintient les deux domaines actifs pendant que le nouveau gagne sa place. Cela aide lorsque l'ancien domaine reçoit encore des liens et des visites. Cela a aussi un coût. Deux ensembles de balises doivent être cohérents en même temps.

Si vous exécutez les deux, choisissez à l'avance la page d'accueil de chaque marché. Notez ce choix dans l'ensemble hreflang, puis laissez le sitemap et les liens internes le suivre.

Pages de destination et redirections douces

Une page de destination sur un autre domaine avec un bouton qui mène à votre site est un lien sortant ordinaire. Elle peut faire passer les visiteurs, mais elle ne déplace pas l'historique d'une adresse comme le fait un 301. Ne comptez pas dessus comme une étape de migration.

Utilisez de telles pages comme un pont pour les humains, et conservez la redirection serveur comme le mécanisme qui transporte les liens.

Surveiller les deux hébergeurs pendant la période de chevauchement

Conservez les deux propriétés vérifiées dans Search Console, et récupérez les données de liens pour les deux hébergeurs selon le même calendrier. Des calendriers désalignés font paraître un déplacement normal comme une perte.

Comparez les données similaires à chaque extraction : le même hébergeur, la même action, le même mois. Ainsi, la différence que vous voyez est le déplacement, et non le calendrier. Notez la date de tout changement de redirection dans le même fichier, afin que le timing ne soit jamais une supposition.

Vérifier si les liens suivent chaque migration régionale

Une migration régionale n'est à moitié terminée que lorsque les balises et les redirections sont correctes. L'autre moitié est de savoir si les sites externes pointent maintenant vers la bonne URL régionale, et c'est une question de liens.

Quel hébergeur régional est préféré par les sites externes

Récupérez toppages pour chaque hébergeur régional, puis utilisez compare pour placer les deux bases de liens côte à côte, afin de vérifier les backlinks des sites dans un seul tableau. Faites cela pour les hébergeurs qui vous intéressent avant de décider lequel doit détenir les signaux de marché.

Un hébergeur qui rassemble la plupart des domaines liés vous indique où les sites externes envoient déjà leurs lecteurs.

Lorsqu'un hébergeur régional perd des domaines liés

Commencez par la liste des pages liées sur cet hébergeur. Trouvez les URL qui ont disparu, vérifiez si chacune redirige vers la bonne page régionale, et confirmez que les balises hreflang sur cette page nomment le même marché.

Si la baisse coïncide avec un changement de sitemap, comparez les anciennes et nouvelles listes de sitemap avant de toucher aux balises. L'arbre décisionnel pages non indexées couvre le cas où une page régionale existe mais reste hors de l'index.

Maintenir une base régionale

Sauvegardez la liste de liens pour chaque hébergeur régional avec la date dans le nom du fichier, afin qu'une extraction ultérieure ait quelque chose à comparer. Sans ce fichier, une baisse semble être un problème nouveau, alors qu'il peut s'agir d'un déplacement survenu il y a plusieurs mois.

Enregistrez l'ensemble hreflang et le choix canonical à côté du fichier de liens. Lorsqu'un hébergeur perd des liens, vous pouvez alors vérifier les balises par rapport à l'état qu'elles avaient lorsque les liens ont été comptés pour la dernière fois.

Exécutez la même extraction pour chaque hébergeur régional le même jour du mois, et conservez la sortie dans un dossier par hébergeur. Une comparaison entre hébergeurs n'est équitable que lorsque les dates correspondent, et les noms de fichiers sont le moyen le plus simple de le rendre visible.