Notre Domain Rating Ahrefs est passé de 23 à 6. Le chiffre était difficile à ignorer. Il n’en était pourtant pas une explication.
Cette distinction a orienté l’enquête. Un score tiers peut vous dire qu’un élément a changé dans son modèle. Il ne peut pas vous dire quelle décision technique a causé ce changement, ni si le même mouvement apparaît dans les performances de recherche. Nous avons donc traité cette baisse comme un signal pour inspecter le site, pas comme un verdict.
L’inspection a mis au jour un vrai problème à la racine. Pour les visiteurs ne disposant pas déjà d’une préférence de langue, la même URL pouvait renvoyer une redirection temporaire vers différents chemins de langue selon la localisation de la requête. Ce comportement était incompatible avec la structure de langue permanente que nous voulions que les moteurs de recherche comprennent.
Nous l’avons corrigé. Nous ne pouvons toujours pas dire honnêtement que cette redirection a causé la baisse du Domain Rating.
Ce que le score indique réellement
Ahrefs définit le Domain Rating comme une mesure relative du profil de backlinks d’un site sur une échelle de 0 à 100. Le calcul dépend des sites qui renvoient vers un domaine et de l’index plus large d’Ahrefs. Un score peut donc évoluer même lorsqu’un site n’a pas perdu la même proportion de backlinks.
Ahrefs précise aussi que le Domain Rating n’est pas un facteur de classement Google. C’est utile pour comparer des profils de backlinks et repérer des changements, mais ce n’est pas une mesure directe de la manière dont Google classe une page.
Cela nous a laissés avec deux faits distincts :
- Nous avons observé le score passer de 23 à 6.
- Le comportement de redirection à la racine devait être corrigé.
Ces faits existaient en même temps. Leur chronologie ne prouve pas que l’un a causé l’autre.
Ce que faisait l’URL racine
Le middleware ancien sélectionnait une langue à partir du pays de la requête lorsqu’aucune préférence de langue n’était déjà présente. Il redirigeait ensuite un chemin non localisé, comme l’URL racine, vers cette langue avec une réponse 302.
Sous une forme simplifiée, le comportement pertinent ressemblait à ceci :
const country = request.cf?.country
|| request.headers.get('CF-IPCountry')
|| 'US'
const targetLocale = LOCALE_MAP[country] || 'en'
return new Response(null, {
status: 302,
headers: { Location: `/${targetLocale}/` },
})
Le code essayait d’être utile. Un visiteur en Allemagne pouvait être envoyé vers la langue allemande, tandis qu’un visiteur aux États-Unis pouvait être envoyé vers l’anglais.
Le problème venait du crawler face au contrat. Une source URL n’avait pas une destination stable unique. Sa réponse dépendait de la localisation, et la redirection indiquait que le déplacement était temporaire.
Cela compte, car Google traite les redirections permanentes et temporaires différemment. Sa documentation sur les redirections indique que les redirections permanentes comme 301 et 308 sont de forts signaux que la cible devrait devenir canonique. Avec les redirections temporaires comme 302 et 307, la source reste généralement l’URL canonique dans les résultats de recherche.
Les redirections temporaires sont valides quand le changement est réellement temporaire. Elles sont le mauvais choix par défaut lorsque le site possède une hiérarchie de langues permanente et a besoin d’un point d’entrée canonique déterministe.
Pourquoi l’acheminement dépendant de la localisation était risqué
Imaginez deux crawlers qui demandent la même URL racine depuis des localisations différentes. L’un reçoit une redirection vers /en/. L’autre reçoit une redirection vers /de/. Dans les deux cas, les réponses sont temporaires.
Aucun élément dans l’une ou l’autre réponse ne raconte une histoire stable sur la destination racine préférée du site. Ce comportement peut aussi amener des outils externes à enregistrer des chaînes différentes selon l’endroit et le moment où ils crawlaient.
Cela ne détruit pas automatiquement l’autorité, et un 302 n’est pas une pénalité. Les moteurs de recherche peuvent interpréter des redirections en s’appuyant sur plus que le seul code de statut. Le problème, c’est que notre implémentation a mélangé trois préoccupations dans une seule réponse :
- La structure permanente du site
- La langue probable du visiteur
- La préférence enregistrée du visiteur
Ces préoccupations méritent d’être gérées séparément. La route canonique doit être stable. La personnalisation ne devrait intervenir qu’en présence d’une préférence explicite ou après que la page stable a été chargée.
La correction déterministe
Le middleware corrigé sépare une nouvelle requête d’un visiteur de retour ayant choisi une langue.
Pour une requête sans cookie vers un chemin non localisé, le serveur renvoie désormais une redirection permanente 301 vers le chemin anglais. La destination est la même quelle que soit la country :
https://zenovay.com/ -> https://zenovay.com/en/
Pour un visiteur disposant déjà d’un cookie de préférence de langue, le middleware peut encore respecter ce choix personnel avec une redirection temporaire. Il s’agit alors d’une réponse réellement spécifique à l’utilisateur, et non d’une affirmation sur la structure canonique du site.
Il s’agit d’un petit changement de code avec une propriété utile : un crawler et un navigateur propre voient désormais un premier saut prévisible. Nous avons vérifié la réponse racine en production avec des requêtes ordinaires, des requêtes Googlebot et des en-têtes de langue différents. Chacune renvoyait un 301 vers la même URL anglaise.
La correction ne nous oblige pas à supprimer des pages localisées. Chaque langue conserve son URL propre. Les sélecteurs de langue et les préférences enregistrées continuent de servir les visiteurs. Le changement ne rend déterministe que le chemin d’entrée par défaut.
Ce que nous pouvons conclure, et ce que nous ne pouvons pas
Nous pouvons conclure que la redirection racine ancienne était un défaut technique. Elle utilisait un statut temporaire pour une structure de site permanente et permettait à la destination de varier selon la localisation de la requête. Le comportement actuel est plus simple à analyser pour les crawlers, les outils d’audit externes et les humains.
Nous ne pouvons pas conclure que ce défaut a causé le changement complet du score Ahrefs. Nous ne disposons pas d’une expérience contrôlée qui isole la redirection des changements dans l’index d’Ahrefs, du graphe des backlinks, des domaines référents ou d’autres facteurs du site.
Nous ne pouvons pas non plus affirmer qu’il y a eu une récupération avant que les données ne montrent quelque chose. Déployer la correction, c’est le début de l’observation, pas la fin de l’histoire.
La démarche responsable consiste à enregistrer la date du changement et à observer plusieurs signaux séparément :
- Domain Rating et les domaines référents associés
- Les backlinks nouvellement découverts et ceux perdus
- Les impressions et clics depuis les données de recherche de première partie
- L’indexation et la sélection canonique pour les pages racine et de langue
- La réponse de redirection vue par des requêtes propres au fil du temps
Si ces signaux s’améliorent ensemble après la correction, les éléments deviennent plus intéressants. Ils nécessitent toutefois une interprétation prudente.
Un audit de redirection pratique
Vous n’avez pas besoin d’une grande plateforme SEO pour détecter ce type de problème. Commencez par la réponse HTTP elle-même.
- Demandez l’URL racine sans cookies et enregistrez le statut ainsi que l’en-tête
Location. - Répétez la requête avec des en-têtes de langue différents et, si possible, depuis des régions différentes.
- Confirmez que les routes publiques permanentes ont une destination déterministe unique.
- Suivez la chaîne et vérifiez qu’elle se termine sans sauts supplémentaires ni boucles.
- Examinez les liens canoniques et les liens de langue alternatifs de la page finale.
- Testez séparément un visiteur de retour avec une préférence explicite de langue.
- Enregistrez le résultat ainsi que la date de déploiement afin que les changements ultérieurs de métriques aient un contexte.
Un contrôle en ligne de commande utile est volontairement ennuyeux :
curl -I https://example.com/
Ensuite, ne faites varier qu’un seul paramètre à la fois. Ajoutez un en-tête Accept-Language. Utilisez un cookie jar propre. Lancez la requête depuis une autre région. Si l’URL publique est censée avoir une destination canonique unique, le premier saut ne devrait pas devenir un tirage au sort géographique.
La leçon plus générale
Les baisses de métriques créent une pression pour une histoire rapide. Une histoire rapide est souvent là où une observation technique se transforme en affirmation causale non étayée.
La meilleure séquence est plus lente et plus utile :
- Confirmer ce que mesure la métrique.
- Inspecter le système à la recherche de défauts concrets.
- Corriger les défauts parce qu’ils sont des défauts.
- Séparer le comportement vérifié des hypothèses sur l’impact.
- Surveiller les signaux principaux et tiers après le changement.
Notre baisse de Domain Rating nous a conduits à un vrai problème de redirection. En corrigeant ce problème, nous avons donné au site un chemin d’entrée canonique stable. Reste à savoir si cela explique le mouvement du score : c’est une question ouverte, et nous préférons la laisser ouverte plutôt que de fabriquer une certitude.
C’est le type de trace de débogage en laquelle nous avons confiance : exacte sur le code, prudente sur la causalité, et claire sur ce qu’il faut mesurer ensuite.
