Panne de mapping de domaine après une migration vers des ccTLD par langue

Un fabricant d’équipements de sécurité au travail, jusque-là hébergé sur une structure en sous-dossiers de langue, a décidé de basculer vers des domaines nationaux distincts (site.de pour l’Allemagne, site.fr pour la France) afin de renforcer sa crédibilité locale sur son marché allemand, en pleine expansion. Dix jours après la bascule technique, le trafic organique sur le marché allemand avait chuté de 60 %, un effondrement bien plus brutal que la baisse temporaire habituellement attendue lors d’un changement de structure d’URL.

Cet article ne revient pas sur la migration de sous-dossiers vers sous-domaines, un cas différent déjà traité par ailleurs, mais détaille le diagnostic de cette panne précise, provoquée par un mapping de domaine mal configuré plutôt que par un problème de fond de référencement.

Symptôme

Le site allemand, désormais accessible sur site.de, semblait fonctionner normalement lors d’une navigation manuelle depuis un navigateur classique : pages accessibles, contenu correctement affiché en allemand, formulaires opérationnels. Rien dans l’expérience utilisateur directe ne laissait deviner un problème. C’est la chute de trafic organique constatée dans Google Search Console, bien supérieure à ce qu’une migration de domaine bien exécutée provoque habituellement, qui a déclenché l’alerte.

Diagnostic

Le premier réflexe, avant toute analyse SEO poussée, a été de vérifier la résolution technique du nouveau domaine avec des outils simples de diagnostic DNS et HTTP :

curl -I https://site.de/
curl -I https://www.site.de/
dig site.de A
dig www.site.de CNAME

Le résultat a immédiatement révélé le problème : la version avec www. renvoyait un code 200 correct, mais la version sans www., pourtant celle indiquée dans toute la communication du client et dans les liens externes déjà en place, renvoyait un code 301 vers l’ancienne URL en sous-dossier (site.com/de/), toujours active en parallèle pour une période de transition. Ce comportement provenait d’une configuration de mapping de domaine incomplète chez l’hébergeur : seul le sous-domaine www avait été correctement pointé vers l’installation WordPress multisite gérant le nouveau domaine allemand, la racine du domaine site.de ayant conservé, par erreur, une ancienne redirection de parking configurée par le registrar lors de l’achat du nom de domaine.

Conséquence directe pour le référencement : Googlebot, en recrawlant les URLs allemandes après la migration, suivait cette redirection vers l’ancien sous-dossier, désormais lui-même configuré pour rediriger vers le nouveau domaine — créant une boucle de redirection partielle que Google a interprétée comme un signal de contenu instable, entraînant une désindexation rapide des pages concernées.

Vérification de l’hypothèse

Un contrôle dans l’outil d’inspection d’URL de Google Search Console a confirmé le diagnostic : plusieurs URLs allemandes stratégiques affichaient le statut « URL en double, l’utilisateur n’a pas désigné d’URL canonique », révélateur d’une confusion algorithmique entre les deux domaines concurrents pour le même contenu. Le fichier hreflang, généré correctement par WPML, pointait bien vers site.de, mais cette information ne suffisait pas à compenser l’instabilité technique détectée par les robots d’exploration.

Correctif

# Configuration corrigée chez l'hébergeur (exemple Nginx)
server {
    server_name site.de;
    return 301 https://www.site.de$request_uri;
}

server {
    server_name www.site.de;
    root /var/www/site-de/public;
    # configuration WordPress standard
}

Une fois la racine du domaine correctement redirigée en 301 permanente vers la version www définitive, sans passer par l’ancien sous-dossier, la situation s’est stabilisée. L’ancien sous-dossier site.com/de/ a lui-même été configuré en redirection 301 directe vers www.site.de, éliminant tout maillon intermédiaire dans la chaîne de redirection.

Prévention

• Toujours tester la résolution des deux variantes d’un nouveau domaine (avec et sans www) avant toute communication publique du changement d’URL ;
• Vérifier qu’aucune redirection de parking par défaut du registrar n’est restée active après l’achat d’un nouveau nom de domaine ;
• Utiliser l’outil d’inspection d’URL de Search Console sur un échantillon de pages stratégiques dès les premiers jours suivant une migration de domaine, plutôt que d’attendre une baisse de trafic pour investiguer ;
• Cartographier l’intégralité de la chaîne de redirection avant bascule, un simple schéma sur papier suffisant souvent à repérer une boucle avant qu’elle ne devienne un problème en production.

Une migration de domaine ne se résume jamais à un changement de nom : c’est une chaîne complète de redirections qui doit être vérifiée maillon par maillon, la racine du domaine étant le maillon le plus souvent négligé parce qu’il semble le plus évident.

En résumé

Ce qui ressemblait à un problème de fond de référencement international s’est révélé être un simple défaut de configuration DNS, invisible en navigation normale mais fatal pour les robots d’exploration. Le trafic allemand a retrouvé son niveau antérieur en trois semaines après correction, confirmant que la cause profonde n’était bien ni le contenu ni la structure hreflang, mais ce maillon technique négligé lors de la bascule.