Fusionner deux sites web : pourquoi Google ne traite-t-il pas ça comme une migration classique ?

Quelle est la différence fondamentale entre migration et fusion ?

Une migration classique consiste à déplacer un site d'un domaine A vers un domaine B sans modifier l'architecture ou le contenu. Google suit les redirections 301, transfère les signaux (PageRank, autorité), et le processus est relativement prévisible.

La fusion, elle, combine deux entités distinctes en une seule. Cela implique de refondre l'arborescence, de décider où placer chaque contenu, et de créer une nouvelle structure hybride. Google doit tout recrawler comme s'il découvrait un site neuf — exit le confort de la simple redirection.

Pourquoi Google doit-il re-crawler massivement lors d'une fusion ?

Parce que le moteur ne peut pas simplement transférer les signaux d'un point A vers un point B. Il doit comprendre la nouvelle relation entre les contenus fusionnés : sont-ils concurrents ? complémentaires ? redondants ?

Les signaux de pertinence (liens internes, cocons sémantiques, profondeur de page) changent radicalement. Une page qui était profondément enfouie sur le site A peut devenir centrale dans la nouvelle structure — ou inversement. Google doit réévaluer chaque URL dans son nouveau contexte.

Comment la structure de fusion impacte-t-elle la vitesse de traitement ?

Martin Splitt souligne que le choix architectural est déterminant. Deux approches existent : mélanger les contenus (approche intégrée) ou créer des sections distinctes (approche modulaire).

L'approche modulaire — où chaque ancien site conserve sa propre section — facilite le crawl : Google peut traiter chaque bloc séparément. L'approche intégrée — où les contenus se mêlent par thématique — exige une analyse plus fine des signaux de cannibalisation et de cohérence sémantique, ce qui ralentit le processus.

• Fusion = nouveau site aux yeux de Google, pas un simple déplacement
• Le re-crawl massif est inévitable — prévoir plusieurs semaines voire mois
• La structure choisie (mixte ou modulaire) influe directement sur la vitesse de récupération
• Les signaux de pertinence doivent être reconstruits, pas simplement transférés
• Budget de crawl critique : un site fusionné de 50k pages demande une gestion fine

Cette déclaration correspond-elle à ce qu'on observe sur le terrain ?

Absolument. Les fusions provoquent systématiquement des fluctuations de trafic bien plus violentes qu'une migration classique. On observe régulièrement des chutes de 30-50% pendant 2-3 mois avant stabilisation — là où une migration bien exécutée limite la casse à 10-15% sur 3-4 semaines.

Ce que Google ne dit pas : le vrai problème n'est pas technique mais éditorial. Fusionner deux sites, c'est souvent fusionner deux stratégies SEO qui se cannibalisent. On se retrouve avec trois pages sur "avocat divorce Paris" qui se battent pour le même mot-clé. Google doit démêler ce bordel — et ça prend du temps.

Quelles nuances faut-il apporter à cette affirmation ?

Splitt parle de "vitesse de traitement" sans donner de chiffres. [À vérifier] : est-ce qu'on parle de semaines, de mois, de trimestres ? La réponse dépend de facteurs qu'il n'évoque pas : taille du site, crawl budget disponible, qualité des contenus fusionnés.

Autre angle mort : la question des backlinks. Fusionner deux sites, c'est fusionner deux profils de liens. Si le site A a 5000 backlinks pointant vers /services/ et le site B 3000 vers /prestations/, que devient cette autorité quand on fusionne en /offres/ ? Google dilue, consolide ou ignore ? Splitt reste flou.

Dans quels cas cette logique ne s'applique-t-elle pas pleinement ?

Si l'un des deux sites est quasi-mort (trafic organique négligeable, crawl budget minimal), la fusion se comporte davantage comme une migration avec augmentation de contenu. Google traite principalement le site dominant et absorbe l'autre progressivement.

Autre exception : les fusions de sous-domaines vers un domaine principal. Techniquement c'est une fusion, mais si blog.site.com migre vers site.com/blog/, Google gère ça plus rapidement qu'une vraie fusion de deux domaines distincts — les signaux d'autorité sont déjà partiellement partagés.

Que faut-il faire concrètement avant de fusionner deux sites ?

D'abord, auditer la cannibalisation potentielle. Identifie tous les doublons sémantiques : si les deux sites ciblent les mêmes requêtes, décide quelle version conserver. Privilégie celle qui a le meilleur historique de trafic organique, pas celle qui "semble" mieux écrite.

Ensuite, cartographie les redirections en amont. Contrairement à une migration classique où c'est du 1:1, ici tu peux avoir du 2:1 (deux anciennes URLs vers une nouvelle), du 1:0 (contenu obsolète qu'on abandonne), ou du 1:nouveau (contenu refondu). Chaque choix impacte le crawl budget et la vitesse de traitement.

Comment structurer la fusion pour minimiser l'impact SEO ?

L'approche modulaire (sections distinctes) est plus sûre mais moins élégante. Elle préserve les silos thématiques existants et facilite le suivi post-fusion — tu peux mesurer la performance de chaque ancien site séparément.

L'approche intégrée est plus risquée mais potentiellement plus performante à long terme. Elle exige une refonte éditoriale complète : fusion des contenus complémentaires, suppression des redondances, création d'une nouvelle architecture sémantique cohérente. Cela dit, le temps de récupération sera plus long — et c'est là que ça coince pour beaucoup de clients.

Quelles erreurs éviter absolument lors d'une fusion de sites ?

Ne jamais lancer une fusion en période de forte activité commerciale (Black Friday, soldes, lancement produit). La perte de visibilité temporaire peut coûter une fortune. Planifie en basse saison.

Évite aussi de fusionner sans renforcer le crawl budget au préalable. Soumets un nouveau sitemap XML combiné, augmente la fréquence de mise à jour du contenu, optimise les temps de réponse serveur. Google doit avoir les ressources pour digérer cette masse de contenu rapidement.

• Réaliser un audit de cannibalisation sémantique complet (outils : Ahrefs, SEMrush, Screaming Frog)
• Cartographier toutes les redirections (2:1, 1:1, 1:nouveau) dans un fichier de mapping exhaustif
• Choisir entre approche modulaire (sections distinctes) et intégrée (contenus mêlés) selon les ressources disponibles
• Préparer un sitemap XML fusionné et le soumettre via Search Console avant la bascule
• Planifier la fusion hors période commerciale critique pour absorber la baisse de trafic temporaire
• Monitorer quotidiennement le crawl budget et les erreurs 404 post-fusion pendant au moins 90 jours