La cannibalisation est souvent diagnostiquée trop vite : deux URL reçoivent des impressions sur une même requête, donc l’une devrait disparaître. Cette conclusion ignore les appareils, les pays, les périodes, les sous-intentions et la façon dont Search Console agrège ses données. Deux pages peuvent se compléter. À l’inverse, deux templates peuvent se concurrencer sans partager exactement les mêmes mots-clés si leur promesse, leur maillage et leur contenu deviennent interchangeables.
Une collision exploitable réunit plusieurs preuves : alternance des pages pour un groupe de requêtes, forte similarité de réponse, absence de frontière éditoriale, signaux internes contradictoires et performance instable. Le vrai enjeu n’est pas de réduire mécaniquement le nombre d’URL. Il est d’attribuer une intention propriétaire à une destination capable de la satisfaire, puis de donner aux autres pages un rôle différent ou un chemin de retrait.
L’API Search Console permet de grouper et filtrer par page, requête, pays ou appareil, tout en signalant que les dimensions page/requête peuvent entraîner une perte de données. Le pilotage SEO technique de Dawap associe cette mesure à un inventaire de templates, au rendu HTML, aux canonicals, aux liens et aux logs de déploiement.
Le diagnostic devient un objet versionné : période, propriété, type de recherche, dimensions, filtres, normalisation d’URL et version de template. Il sépare faits, interprétations et hypothèses. Une équipe peut ainsi reproduire la paire suspecte, tester une correction sur une cohorte, comparer la baseline et revenir en arrière sans réécrire l’histoire.
Pour qui : définir une collision sans faux positif
Distinguer coexistence et concurrence
Une requête générique peut naturellement faire apparaître une catégorie, une fiche et un contenu pédagogique selon le contexte. La coexistence devient problématique lorsque les pages échangent fréquemment leur rôle, proposent la même action et ne donnent aucun motif clair de choisir l’une plutôt que l’autre. L’analyse porte sur un cluster de requêtes et plusieurs semaines, pas sur une capture de position.
Le responsable SEO définit quatre niveaux : recouvrement attendu, ambiguïté à surveiller, collision probable et collision confirmée. Chaque niveau exige des preuves. Une même requête sur deux pages constitue seulement un recouvrement. Une alternance accompagnée d’une baisse de clics, d’un contenu substituable et de liens contradictoires justifie un test.
Accepter que la meilleure solution puisse être deux pages
En réalité, il ne faut pas fusionner dès qu’un chevauchement apparaît. Une page « comparer » et une page « acheter » peuvent partager le vocabulaire mais satisfaire des étapes différentes. Leur distinction se renforce par les preuves, les sections et les CTA. Les fusionner produirait une longue page confuse et ferait perdre un parcours.
La décision doit donc répondre à trois questions : l’utilisateur attend-il le même résultat, les pages peuvent-elles porter des preuves différentes, et le maillage peut-il exprimer cette frontière ? Si oui, la spécialisation prime. Sinon, une destination propriétaire absorbe la valeur et l’autre sort progressivement du graphe.
Extraire Search Console sans masquer les limites
Interroger chaque journée et paginer
La procédure officielle pour récupérer les données de performance recommande une requête quotidienne portant sur un jour, puis une pagination en augmentant startRow par blocs jusqu’à obtenir zéro ligne. Elle précise un maximum exposé de 50 000 lignes par jour et type de recherche, triées par clics. Le pipeline conserve donc une notion explicite de couverture.
Un job idempotent charge web, image et vidéo séparément lorsque nécessaire. Il stocke la requête JSON, la date de disponibilité, le nombre de lignes et la réponse brute. Les reprises n’écrasent pas une journée finalisée sans contrôle. Une clé unique sur propriété, date, type et dimensions empêche les doubles comptes.
Comprendre la perte de détail
Google indique que le groupement par page ou requête peut omettre certaines données, alors que des agrégations moins détaillées fournissent des comptes plus complets. Le pipeline exécute donc une requête de total par propriété et une requête détaillée page-requête. Le ratio entre les deux devient un indicateur de couverture, pas un problème à corriger par interpolation arbitraire.
La documentation de searchAnalytics.query précise aussi que les résultats sont classés par clics et ne garantissent pas toutes les lignes. Une absence de requête longue traîne n’équivaut pas à zéro impression. Le rapport réserve ses conclusions aux données observées et compare des extractions construites de la même manière.
Construire un graphe requête-page interprétable
Normaliser avant de relier
Les pages sont normalisées selon le host canonique, le protocole, les paramètres gouvernés et les redirections. Les requêtes sont conservées dans leur forme brute pour l’analyse principale ; une version normalisée sert uniquement au regroupement exploratoire. Accents, marques et ordre des mots peuvent porter une intention, ils ne doivent pas être supprimés sans trace.
Chaque arête contient impressions, clics, CTR, position, pays, appareil, date et type de recherche. Le graphe ne retient pas seulement les arêtes les plus fortes : il conserve le seuil d’inclusion et la couverture. Les pages sont enrichies par template, statut, canonical déclaré, profondeur et conversion. Cette jointure rapproche performance et architecture.
Calculer des signaux, pas un verdict opaque
Les signaux incluent part d’impressions partagée, fréquence d’alternance, écart de CTR, proximité de position et stabilité temporelle. Un score composite sert à prioriser la revue, jamais à supprimer automatiquement une page. Le dashboard expose les composantes pour que l’analyste puisse comprendre pourquoi une paire remonte.
La segmentation évite les paradoxes. Une page peut gagner sur mobile et l’autre sur desktop en raison d’une expérience ou d’une intention différente. Une agrégation locale peut être pertinente dans un pays seulement. Le modèle compare d’abord à l’intérieur des segments, puis résume. Il ne mélange pas des groupes qui obéissent à des parcours distincts.
Comparer les promesses et les preuves des templates
Extraire la structure rendue
Le crawler capture title, H1, H2, introduction, CTA, données structurées, ancres entrantes et blocs partagés. Il exécute le rendu SSR puis, pour les routes JavaScript, compare le DOM hydraté. Une différence de contenu essentiel entre HTML initial et hydratation devient un risque distinct de la cannibalisation.
Le diff sépare texte de composant et champs locaux. Deux pages peuvent sembler différentes parce que noms et villes varient alors que leur squelette et leur proposition restent identiques. À l’inverse, un composant partagé de navigation ne suffit pas à déclarer une collision. Le responsable éditorial examine les blocs qui portent la décision.
Écrire une fiche d’intention
Chaque template possède une phrase « pour qui, dans quelle situation, quelle décision, avec quelle preuve ». Les requêtes observées sont classées comme centrales, adjacentes ou hors périmètre. Les H2 et CTA doivent correspondre à cette fiche. Une requête centrale partagée par deux templates déclenche un arbitrage ; une requête adjacente peut être acceptée.
Le registre nomme un propriétaire métier et un responsable technique. Toute modification du template vérifie ses voisins connus. La CI peut détecter une hausse de similarité ou la copie d’un title, mais l’acceptation reste humaine et documentée. Le contrat est versionné avec la release.
Lire les canonicals comme un faisceau de signaux
Comparer déclaré, sélectionné et lié
Le canonical déclaré dans le HTML exprime une préférence ; Google peut sélectionner une autre URL. L’inspection d’URL fournit, sur un échantillon, les valeurs déclarée et choisie connues dans l’index. Le crawler ajoute les liens internes et le sitemap. Une page auto-canonique massivement liée vers sa concurrente envoie un message moins cohérent que sa balise seule.
La référence Google sur la canonicalisation présente redirections et rel=canonical comme signaux forts, et recommande de lier vers les URL canoniques. Le diagnostic recherche les contradictions entre ces méthodes plutôt que d’attendre d’une balise qu’elle tranche toute ambiguïté éditoriale.
Ne pas utiliser canonical pour deux intentions
Si deux pages ont des intentions distinctes, pointer l’une vers l’autre efface la différence au lieu de la renforcer. Si elles sont réellement dupliquées, conserver les deux dans le maillage dilue la consolidation. Le canonical est donc la conséquence d’un arbitrage, pas sa méthode. Le mapping doit être explicite et univoque.
Le test valide URL absolue, statut 200 de la cible, absence de chaîne et cohérence linguistique. JavaScript ne doit pas modifier la balise après le rendu serveur. Le cache et l’ISR doivent invalider source et cible ensemble lors d’une migration. Les logs de revalidation conservent les versions.
Choisir fusion, spécialisation, consolidation ou retrait
Fusionner quand les réponses sont substituables
La page propriétaire reçoit les preuves utiles, les liens et le contenu unique de l’autre. Les URL historiques sont mappées vers une destination équivalente par redirection permanente. Les sitemaps, breadcrumbs et modules basculent dans la même release. Les analytics conservent l’identifiant de migration pour comparer les séries.
La fusion n’est pas un collage. Le responsable éditorial reconstruit une hiérarchie cohérente, supprime les répétitions et garde le CTA correspondant à l’intention. Le backend vérifie que la destination supporte le volume et les filtres nécessaires. Un canari sur une famille mesure statut, rendu, cache et conversion.
Spécialiser quand les parcours diffèrent
La spécialisation modifie promesse, preuves, structure et maillage. Une catégorie peut comparer un marché ; une fiche peut qualifier un acteur ; une agrégation peut répondre à une contrainte de disponibilité. Les ancres internes et les blocs recommandés reflètent ces rôles. Changer trois mots du H1 ne suffit pas.
Le test de substitution est rejoué après correction. Deux relecteurs doivent pouvoir expliquer sans voir l’URL pourquoi chaque page existe. Les clusters de requêtes attendus sont inscrits comme hypothèses, puis surveillés. Si l’alternance persiste malgré une frontière réelle, l’équipe cherche d’autres causes avant une nouvelle fusion.
Tester une correction sans confondre corrélation et causalité
Scénario A : spécialisation d’un template
Exemple concret. Sélectionner vingt paires comparables, modifier uniquement la promesse, les H2, les preuves et le maillage de dix paires, puis conserver dix témoins. La baseline couvre huit semaines minimum. Après release, comparer part d’impressions, alternance, CTR et conversion par segment. Un gain n’est attribué au changement que si la tendance diffère raisonnablement des témoins.
Les seuils opérationnels restent immédiats : aucun canonical contradictoire, aucune hausse des 4xx, rendu HTML complet et TTFB P95 sous la limite. Les signaux de recherche demandent davantage de temps. Le responsable du déploiement peut replier un défaut technique sans attendre la mesure SEO et sans annuler les données du test.
Scénario B : fusion et redirection
Choisir une famille avec une correspondance source-cible exacte. Avant bascule, crawler tous les liens entrants, enregistrer les couples requête-page et chauffer la cible. Après bascule, vérifier 301 en un saut, canonical auto-référent de la cible, absence de source dans le sitemap et transfert des liens internes. Le cache ne doit servir aucun ancien 200.
Le monitoring suit demandes sur anciennes URL, erreurs, indexation des cibles et conversion. Une cible qui retourne 200 mais ne contient plus la preuve attendue échoue au test. Le rollback restaure routes et liens depuis le même mapping ; il ne s’appuie pas sur une liste reconstruite pendant l’incident.
Surveiller la réapparition des collisions
Mettre à jour le graphe quotidiennement
Le pipeline collecte chaque jour les données finalisées disponibles, pagine, déduplique et enregistre la couverture. Il reconstruit les arêtes sur des fenêtres glissantes de 28 et 84 jours. Les nouvelles paires sont comparées au registre d’intention. Une alerte exige un volume minimal et plusieurs jours d’alternance pour éviter le bruit.
Les queues ont des retries idempotents, une limite de concurrence et des métriques de retard. Une journée manquante reste visible ; elle n’est pas assimilée à zéro. Le monitoring surveille quota, lignes, latence et écart entre agrégé et détaillé. Le responsable des données possède la procédure de reprise.
Connecter changements éditoriaux et données
Chaque publication envoie version de template, routes touchées et type de changement au journal. Le dashboard place ces événements sur les séries. Une collision apparue après l’ajout d’un composant partagé devient une hypothèse vérifiable. Les releases simultanées sont signalées pour limiter les conclusions causales.
Le score de priorité combine valeur métier, volume, instabilité et facilité d’arbitrage. Une paire à fort trafic sans baisse peut attendre une revue ; une paire sur une page de lead qui alterne et perd sa conversion passe devant. L’ordre sert le résultat commercial, pas la beauté du graphe.
Erreurs fréquentes dans l’analyse de cannibalisation
La plupart des faux diagnostics viennent d’une donnée incomplète ou d’une définition trop large. Cette liste sert de revue avant tout changement de canonical, contenu ou route.
- Déclarer une collision parce que deux pages apparaissent une fois sur la même requête.
- Additionner des pays, appareils et types de recherche qui portent des intentions différentes.
- Ignorer la perte de lignes lors du groupement page-requête.
- Normaliser les requêtes jusqu’à effacer marque, lieu ou modalité.
- Prendre un score de similarité pour une décision éditoriale automatique.
- Poser un canonical croisé sans aligner liens, sitemap et contenu.
- Fusionner deux parcours distincts dans une page longue qui ne décide plus rien.
- Mesurer immédiatement les positions et attribuer chaque variation à la release.
Plan d’action
Phase 1 : fiabiliser la donnée
Déployer une extraction quotidienne idempotente par type de recherche, avec pagination, métadonnées et contrôle de couverture. Normaliser les URL depuis un registre central. Enrichir chaque page avec template, canonical, statut, profondeur, conversion et version. Conserver les totaux agrégés à côté du détail.
Construire le graphe et remonter les paires selon des composantes visibles : partage, alternance, stabilité et valeur. Segmenter par pays et appareil. Exclure des verdicts automatiques. Le responsable data garantit le pipeline ; le responsable SEO garantit l’interprétation.
Phase 2 : arbitrer les promesses
Pour chaque paire prioritaire, rédiger les fiches d’intention, comparer le HTML rendu et inventorier liens, sitemap et canonicals. Choisir coexistence, spécialisation, fusion ou retrait. Documenter la preuve, la cible, le responsable et la date. Les exceptions expirent.
Préparer le changement comme un lot cohérent : contenu, maillage, redirection, canonical, cache et analytics. Les tests de contrat tournent en CI. Une cohorte canari couvre templates dominants, rares, langues et profondeur. Le rollback restaure le mapping complet.
Phase 3 : mesurer et maintenir
Rejouer les contrôles techniques immédiatement, puis observer le graphe sur une fenêtre adaptée. Conserver des témoins quand c’est possible. Annoter les autres releases et changements saisonniers. Une amélioration technique valide la livraison ; une amélioration SEO confirme l’hypothèse avec davantage de recul.
La revue mensuelle traite nouvelles collisions et anciennes exceptions. Le registre empêche un composant partagé de reprendre une intention réservée. Le dashboard montre aussi les paires résolues, afin que la dette diminue réellement au lieu de seulement changer de nom.
L’instrumentation associe les entrées Search Console, les sorties du graphe, les seuils d’alerte et les responsabilités. Le monitoring conserve la version du template et le rollback attendu ; cette traçabilité permet d’expliquer une variation sans perdre les dépendances de collecte.
La file quotidienne garantit idempotence et retries, tandis que la procédure d’exploitation nomme le responsable de reprise. Si le volume de lignes chute sous le seuil de couverture, le pipeline conserve la dernière sortie saine, journalise la dépendance fautive et bloque toute décision automatique.
- D’abord, bloquer tout canonical contradictoire et toute fusion sans mapping exact.
- Ensuite, arbitrer spécialisation ou consolidation à partir du graphe et du rendu.
- Enfin, valider la cohorte seulement si le scénario témoin et le scénario modifié restent comparables.
Approfondir QA et agrégations
Échantillonner les paires à risque
La QA par échantillon stratifié aide à sélectionner les templates rares, les profondeurs et les états de donnée sans prétendre qu’un tirage simple représente tout le parc. Les paires suspectes deviennent une cohorte ciblée séparée de l’estimation globale.
Les contrôles déterministes — canonical, statut, liens — restent exhaustifs. La revue humaine porte sur l’intention et la preuve. Cette division réduit le coût tout en gardant la décision explicable et reproductible.
Arbitrer catégorie et regroupement transversal
La frontière entre agrégation et catégorie traite un cas fréquent de collision structurelle. Elle formalise les états d’inventaire, les codes HTTP et les choix de consolidation lorsqu’un regroupement devient vide ou substituable.
Cette machine d’état complète le graphe requête-page. Une collision confirmée ne reste pas un ticket éditorial : elle se traduit en contrat de route, mapping de retrait, instrumentation et surveillance des anciennes URL.
Conclusion : attribuer chaque intention et aligner les signaux
La cannibalisation n’est ni une simple requête partagée ni un score de similarité. C’est une ambiguïté durable entre des destinations substituables, observable dans les données et confirmée par le rendu et le graphe. La segmentation et les limites de Search Console doivent rester visibles.
L’arbitrage précède le canonical. Coexistence, spécialisation, fusion et retrait répondent à des situations différentes. Une fois le choix fait, contenu, liens, sitemap, route et cache racontent la même décision.
Le test contrôlé et le monitoring quotidien ferment la boucle. Ils séparent récupération technique et évolution de la recherche, conservent les témoins et empêchent un composant partagé de réintroduire une collision déjà résolue.
Vous faire accompagner par un expert pour diagnostiquer les collisions de templates
