Dois-je craindre la cannibalisation entre deux sites identiques ?

Pourquoi Google parle-t-il de contenu HTML identique ?

La précision compte ici : John Mueller mentionne explicitement le contenu HTML identique, pas juste le texte visible. Google compare le code source complet des pages, incluant balises meta, scripts, structures DOM. Deux sites peuvent afficher visuellement le même contenu mais avoir des signatures HTML différentes selon le CMS, le thème, ou les plugins utilisés.

Cette distinction est capitale en migration. Si vous dupliquez un site WordPress vers un nouveau domaine avec le même thème et la même configuration, Google détectera un duplicata parfait. En revanche, refondre le design ou changer de CMS peut suffire à éviter ce scénario, même si le contenu textuel reste proche.

Qu'est-ce que la détermination d'URL canonique dans ce contexte ?

Google ne se contente pas de constater le duplicata : il applique son processus de canonicalisation pour choisir quelle version afficher dans les résultats. Ce choix s'appuie sur plusieurs signaux : l'ancienneté du domaine, le profil de liens, les données d'utilisation, les déclarations canoniques explicites. Le moteur tente de deviner votre intention.

Le problème ? Cette détermination automatique n'est jamais garantie. Google peut privilégier l'ancien domaine alors que vous voulez promouvoir le nouveau, ou l'inverse. Sans redirection 301 propre ou balise canonical claire, vous perdez le contrôle et laissez l'algorithme décider à votre place. C'est un pari risqué.

Dans quels scénarios cette situation se présente-t-elle ?

La cause typique : une migration de domaine mal exécutée. L'entreprise lance le nouveau site, oublie de supprimer l'ancien ou de mettre en place les redirections. Résultat : deux domaines actifs avec le contenu strictement identique pendant des semaines, voire des mois. Google indexe les deux, puis décide arbitrairement lequel garder.

Autre cas fréquent : les environnements de test ou staging accessibles publiquement. Une agence crée une version de préproduction sans la bloquer via robots.txt ou authentification. Si cette version reprend le contenu du site de production avec la même structure HTML, Google la détecte et crée un conflit de canonicalisation non voulu.

• Migration sans redirections 301 : ancien et nouveau domaines actifs simultanément avec contenu identique
• Environnements staging indexables : versions de test crawlées par Google créant des duplicatas involontaires
• Sites miroirs multilingues mal configurés : même contenu HTML sans balises hreflang ni canonical appropriées
• Refonte partielle : nouveau domaine lancé avec seulement quelques pages redessinées, le reste copié tel quel
• Réutilisation de templates identiques : deux entreprises utilisant le même thème avec contenu similaire sans personnalisation suffisante

Cette déclaration est-elle cohérente avec les observations terrain ?

Absolument. Les cas de migration ratée avec perte de rankings sont documentés depuis des années. Quand un site migre sans redirections et conserve l'ancien domaine actif, on observe systématiquement une phase de confusion durant laquelle Google indexe les deux versions. Puis, progressivement, l'une disparaît de l'index au profit de l'autre.

Ce qui est moins prévisible : quelle version Google va privilégier. Dans 70% des cas observés, c'est l'ancien domaine qui garde les positions, le nouveau restant invisible. Pourquoi ? Probablement l'historique, le profil de liens existant, et les signaux d'autorité accumulés. Mais j'ai vu aussi l'inverse : Google bascule brusquement sur le nouveau domaine, vidant l'ancien de son trafic organique du jour au lendemain.

Quelles nuances Google ne mentionne pas ici ?

La déclaration reste floue sur le seuil de similarité nécessaire pour déclencher le duplicata. Combien de différences HTML faut-il pour que Google considère deux sites comme distincts ? Changer 20% du code suffit-il ? 50% ? [A vérifier] : aucune documentation officielle ne quantifie ce seuil, et les tests empiriques donnent des résultats variables selon les secteurs.

Autre point non abordé : la durée de la phase de confusion. Quand Google détecte deux versions identiques, combien de temps met-il à trancher ? Les observations montrent entre 2 et 8 semaines en moyenne, mais cela peut s'étirer sur plusieurs mois si les signaux sont contradictoires. Pendant cette période, vos rankings fluctuent brutalement, sans logique apparente.

Cette règle s'applique-t-elle aux sites en langues différentes ?

Techniquement oui, mais Google gère différemment les versions linguistiques. Si vous dupliquez votre site français vers un domaine anglais avec traduction automatique basique, le HTML peut rester quasi identique (même structure, mêmes balises, seul le texte change). Google détectera la similarité structurelle.

Cependant, les balises hreflang correctement implémentées signalent à Google qu'il s'agit de versions linguistiques intentionnelles, pas de duplicatas parasites. Le moteur applique alors une logique géo-ciblée plutôt que de canonicalisation pure. Attention toutefois : une traduction automatique médiocre peut être pénalisée pour contenu de faible qualité, indépendamment du duplicata technique.

Que faire concrètement lors d'une migration de domaine ?

La seule approche fiable : implémenter des redirections 301 permanentes de chaque URL de l'ancien domaine vers la nouvelle correspondante. Pas de raccourci, pas de redirection globale vers la homepage. Chaque page doit pointer vers son équivalent exact sur le nouveau domaine. Cette méthode transfère l'autorité et évite tout conflit de canonicalisation.

Une fois les redirections en place, laissez l'ancien domaine actif pendant minimum 6 mois. Google a besoin de ce délai pour transférer tous les signaux historiques. Désactiver l'ancien domaine trop tôt coupe court au transfert d'autorité et vous fait perdre une partie du jus SEO accumulé. Surveillez la Search Console : quand les crawls de l'ancien domaine chutent drastiquement, vous pouvez commencer à envisager sa fermeture.

Comment gérer les environnements de test sans créer de duplicatas ?

Bloquez systématiquement le crawl des environnements staging via robots.txt avec un Disallow: / global. Mieux encore, protégez-les par authentification HTTP basique ou IP whitelisting. J'ai vu trop de sites dont la version de test se classait mieux que la production parce qu'elle était indexée accidentellement avec un profil de liens externe propre.

Ajoutez une balise meta robots noindex en header de toutes les pages staging, en double sécurité. Si Google crawle malgré le robots.txt (ce qui arrive quand quelqu'un link vers le staging), le noindex empêche l'indexation. Contrôlez régulièrement via une recherche site:staging.votredomaine.com pour détecter toute fuite.

Quelle stratégie adopter si les deux domaines sont déjà indexés ?

Identifiez d'abord lequel Google privilégie actuellement. Utilisez la Search Console de chaque domaine : celui qui reçoit le plus d'impressions et de clics organiques est probablement celui que Google considère comme canonical. Si c'est le mauvais domaine, il faut forcer la bascule.

Implémentez immédiatement les redirections 301 depuis le domaine non désiré vers celui à promouvoir. Ajoutez simultanément une balise canonical auto-référentielle sur toutes les pages du domaine cible, signalant explicitement "ceci est la version à indexer". Demandez une réindexation manuelle des pages principales via Search Console pour accélérer le processus. Comptez 3 à 6 semaines avant stabilisation complète.

• Mapper toutes les URLs : créer une correspondance exacte ancien domaine → nouveau domaine avant migration
• Implémenter les 301 : rediriger page par page, pas de redirection globale vers la homepage
• Bloquer les environnements de test : robots.txt + noindex + authentification sur staging/dev
• Vérifier les canonicals : balises canonical auto-référentielles sur le domaine principal uniquement
• Monitorer Search Console : surveiller les crawls et impressions des deux domaines pendant 6 mois
• Désavouer si nécessaire : si l'ancien domaine avait des liens toxiques, les désavouer avant migration pour ne pas transférer la pénalité