Détecter la cannibalisation SEO entre vos pages avec n8n et Google Search Console

Deux articles du même blog, publiés à quelques mois d'écart, qui répondent en réalité à la même requête. Search Console montre les deux dans le rapport de performances, chacune récoltant une part d'impressions, aucune ne perçant durablement au-delà de la troisième page de résultats. C'est le symptôme classique de la cannibalisation SEO : au lieu de concentrer l'autorité du site sur une page unique et solide, deux URLs se neutralisent l'une l'autre sur la même intention de recherche. Le problème n'est pas visible d'un coup d'œil dans l'interface Search Console — il faut croiser requête et page sur plusieurs semaines pour le repérer, exactement le genre de tâche qu'un workflow n8n exécute en quelques secondes là où une revue manuelle prend une matinée entière par site suivi.

Pourquoi la cannibalisation abîme réellement le classement

Un moteur de recherche ne cherche pas à multiplier les pages d'un même site dans ses résultats pour une requête donnée : il cherche à couvrir la diversité des intentions derrière cette requête. Santos, Macdonald et Ounis (2011), Intent-Aware Search Result Diversification, publiée à SIGIR, formalise ce principe : un moteur de recherche répartit son classement pour couvrir un maximum d'intentions distinctes plutôt que d'empiler des résultats redondants sur la même intention. Quand deux pages d'un même site couvrent la même intention, elles n'apportent aucune diversité l'une par rapport à l'autre — le moteur n'a alors aucune raison de faire remonter les deux, et arbitre en alternant, ce qui se traduit exactement par l'instabilité de position observée dans Search Console.

Ce mécanisme d'arbitrage rejoint un problème plus ancien et plus étudié : celui des contenus quasi identiques. Manku, Jain et Das Sarma (2007), Detecting Near-Duplicates for Web Crawling, publiée à WWW et devenue une référence sur la détection de similarité à grande échelle (l'algorithme SimHash qui en est issu est toujours utilisé aujourd'hui), montre que les moteurs de recherche appliquent des mécanismes explicites pour repérer des documents dont le contenu se recoupe fortement, précisément pour éviter de saturer une page de résultats avec des variantes d'un même contenu. Deux pages qui ciblent la même requête avec un contenu proche tombent dans le même filet — sans qu'il s'agisse nécessairement de duplication au sens strict, le chevauchement d'intention suffit à déclencher le même type d'arbitrage.

Ce que Search Console montre — et ce qu'il ne montre pas directement

Le rapport de performances de Search Console, dans son interface, affiche les requêtes et les pages séparément ou combinées, mais ne signale jamais explicitement qu'une requête est disputée par plusieurs pages de votre propre site — ce croisement reste à faire soi-même. L'API searchanalytics.query, elle, expose exactement les données nécessaires dès qu'on interroge les deux dimensions query et page ensemble : chaque ligne renvoyée correspond à une paire requête-page unique, avec ses clics, impressions, CTR et position moyenne propres. C'est cette granularité qui permet de reconstruire, requête par requête, la liste des pages qui se la disputent.

Construire le détecteur dans n8n

1. Récupérer les données groupées par requête et par page

Un Schedule Trigger hebdomadaire déclenche un node HTTP Request en POST vers https://www.googleapis.com/webmasters/v3/sites/{siteUrl encodé}/searchAnalytics/query, authentifié par un credential Google OAuth2 API avec le scope webmasters.readonly — la configuration est identique à celle décrite dans notre guide du rapport SEO hebdomadaire avec Search Console. Le corps de la requête :

{
  "startDate": "2026-08-01",
  "endDate": "2026-08-28",
  "dimensions": ["query", "page"],
  "rowLimit": 5000
}

Une fenêtre de 28 jours lisse le bruit quotidien sans effacer les vraies tendances — une fenêtre plus courte fait ressortir trop de faux positifs sur des requêtes à faible volume.

2. Regrouper les lignes par requête dans un node Code

const parRequete = {};
for (const item of $input.all()) {
  const { keys, clicks, impressions, position } = item.json;
  const [query, page] = keys;
  parRequete[query] ??= [];
  parRequete[query].push({ page, clicks, impressions, position });
}

const candidats = Object.entries(parRequete)
  .filter(([, pages]) => pages.length >= 2)
  .map(([query, pages]) => ({ query, pages: pages.sort((a, b) => a.position - b.position) }));

return candidats.map((c) => ({ json: c }));

À ce stade, candidats contient toutes les requêtes où au moins deux pages du site ont généré des impressions — beaucoup trop large pour une alerte utile en l'état, comme le confirme l'observation empirique que la plupart des cas de classement multiple sur un même site ne posent en réalité aucun problème.

3. Filtrer les vrais cas de cannibalisation

Le filtre qui sépare le signal du bruit repose sur deux critères combinés, appliqués dans le même node Code ou dans un node IF juste après :

• Écart de position resserré : les deux meilleures pages classées sur la requête ont un écart de position inférieur à 10 — deux pages en position 4 et 6 se disputent réellement le même terrain ; une page en position 3 et une autre en position 47 ne se cannibalisent pas, la seconde est simplement une correspondance marginale ignorable.
• Répartition significative des impressions : chaque page dépasse un plancher minimal (par exemple 20 impressions sur la période) — élimine les requêtes anecdotiques où la seconde page n'a été vue qu'une poignée de fois par hasard.

Pour un signal encore plus fiable, comparez deux fenêtres consécutives de 28 jours : si la page en tête change d'une période à l'autre pour la même requête, c'est la signature la plus nette d'une cannibalisation active plutôt que d'une coexistence stable.

4. Diagnostiquer avec un AI Agent avant d'alerter

Un AI Agent reçoit les URLs des pages en concurrence, leur titre et leur méta-description (récupérés via un node HTTP Request simple sur chaque page), et rend un diagnostic structuré grâce à un Structured Output Parser : sujet réellement identique à fusionner, intentions distinctes à mieux différencier, ou cas ambigu nécessitant une revue manuelle. Ce diagnostic évite d'envoyer à l'équipe éditoriale une liste brute de paires d'URLs sans contexte exploitable.

5. Alerter sans agir automatiquement

Le résultat part en message Slack ou email — jamais en action automatique. Fusionner deux pages ou poser une redirection 301 change durablement la structure du site ; c'est une décision éditoriale, pas une tâche à déléguer entièrement à un workflow. Le Schedule Trigger avec gestion des fuseaux horaires permet de caler cette alerte hebdomadaire un lundi matin, en même temps que la revue SEO habituelle.

Cas d'usage concrets

• Blog volumineux à publication régulière. Passé 200-300 articles, il devient courant qu'un nouveau sujet recoupe partiellement un article publié un an plus tôt sans que la rédaction s'en souvienne — le détecteur remonte ces recoupements avant qu'ils ne s'installent durablement.
• Site e-commerce avec pages catégorie et pages produit proches. Une catégorie générique et une sous-catégorie très proche ciblent parfois la même requête commerciale sans intention de le faire.
• Agence gérant plusieurs sites clients. Le même workflow, paramétré par un node Loop Over Items sur une liste de propriétés Search Console, produit un rapport consolidé multi-sites sans dupliquer la logique.

Pièges fréquents

• Alerter sur toute requête à plusieurs pages sans filtrer sur l'écart de position : la majorité des cas de classement multiple sont bénins, et noyer l'équipe éditoriale sous de faux positifs tue l'utilité de l'alerte en quelques semaines.
• Comparer une fenêtre trop courte (7 jours) : le bruit de position sur des requêtes à faible volume produit des faux signaux qu'une fenêtre de 28 jours élimine presque entièrement.
• Fusionner automatiquement sans relecture humaine : la décision de fusionner deux pages engage l'architecture du site et le maillage interne existant ; le workflow doit s'arrêter au diagnostic.
• Oublier de vérifier la dimension page : une requête interrogée sans la dimension page ne renvoie qu'un total agrégé et masque complètement le phénomène — c'est la combinaison query + page qui rend la cannibalisation visible.

Pour aller plus loin

Ce détecteur complète naturellement le rapport SEO hebdomadaire Search Console et le suivi du déclin de trafic par page : les trois workflows interrogent la même API avec le même credential OAuth2, et peuvent tourner dans le même dossier n8n comme une suite d'audit SEO cohérente. Cette logique de collecte structurée, diagnostic par IA et rapport livré sans action automatique est exactement celle du Pack Conformité & Audit (149 €) — conçu pour transformer des données brutes en rapport exploitable, avec la validation humaine qui reste à la bonne place.