Cet article fait suite à la première partie dans laquelle nous vous présentions un starter kit pour prendre en main le serveur MCP d’Oncrawl.
En moins de 20 minutes, vous étiez en mesure d’instancier un agent /auditeur capable de produire un audit exhaustif et actionnable de votre structure, mais aussi de générer des requêtes OQL en langage naturel à exécuter dans le Data Explorer, sans compétence technique préalable.
Ce second article s’adresse aux utilisateurs déjà à l’aise avec le MCP et matures sur Oncrawl. Nous allons plus loin : quatre cas d’usage avancés qui étendent ce que vous pouvez faire nativement dans la plateforme.
- Cas d’usage 1 : Croiser le dataset des pages et celui des liens. Une jointure que l’interface ne permet pas aujourd’hui.
- Cas d’usage 2 : Construire des alertes sur logs autour du comportement des bots.
- Cas d’usage 3 : Déclencher des alertes Slack sur les variations crawl-over-crawl, avec des seuils que vous contrôlez.
- Cas d’usage 4 : Combiner le MCP Oncrawl avec d’autres MCP (comme celui de l’URL Inspection API de Google Search Console) pour répondre à des questions qu’aucun outil seul ne peut couvrir.
Une remarque avant de commencer. Les LLMs raisonnent mieux sur des datasets resserrés que sur des structures de plusieurs millions d’URLs.
Nous recommandons de travailler sur une structure d’environ 100K URLs avec une source de liens qui n’excède pas le million. Au-delà, les coûts en tokens et le temps de calcul grimpent vite.
Cas d’usage 1 : Réaliser des jointures entre le dataset des pages et celui des liens
Au moment où nous écrivons ces lignes, l’interface ne permet pas de réaliser une jointure in-app entre le dataset des pages et celui des liens en utilisant l’URL comme clé. Ces deux datasets sont accessibles via un bouton radio en haut à gauche du Data Explorer, qui permet de basculer de l’un à l’autre, mais pas de les croiser.
Si la jointure était disponible nativement, vous obtiendriez un tableau unifié, requêtable depuis le Data Explorer, qui croiserait les métriques du dataset des pages (inrank, profondeur) avec celles du dataset des liens (origin position, anchor text, etc.).
Vous pourriez alors poser des questions du type :
« Quelles sont les pages qui portent des liens dont l’origine est le body et qui pointent vers des pages ayant un inrank compris entre 1 et 5 ? »
Le MCP comble cette limite. Voici trois prompts utiles à fournir à un LLM connecté au MCP d’Oncrawl.
Croiser inlinks et performance Google Search Console
Si vous avez le connecteur GSC activé, demandez de retourner les inlinks qui proviennent des sections éditoriales (origin main) et qui pointent vers des pages situées dans le 4ᵉ quartile d’impressions le plus bas (75 % des pages du site ont plus d’impressions que celles-ci).
Ce prompt identifie les pages qui reçoivent du jus interne sans le convertir en visibilité organique. C’est un signal classique d’opportunité éditoriale sous-exploitée.
Détecter le gaspillage de jus SEO
Quels sont les liens internes qui gaspillent du jus SEO au sein de la structure, c’est-à-dire ceux qui pointent vers des pages non indexables, 4XX, 5XX ou 3XX ?
Le résultat vous donne une liste exploitable directement par votre équipe dev pour corriger ou rediriger en lot.
Cibler les redirections en impasse
Quelles sont les pages avec un status code 3XX dont la final target est en 4XX ou 5XX ? Génère un tableau avec les colonnes : URL source | Status code (origin) | Final redirect target | Final redirect target status code.
Ce sont les redirections les plus pernicieuses : elles consomment du budget de crawl sans rien servir, et ne sont pas visibles dans un audit classique.
Visualiser les résultats
Les résultats peuvent s’afficher sous forme de tableau. Pour une lecture plus agréable sur des datasets volumineux, vous pouvez aussi connecter à votre LLM un skill de visualisation, c’est-à-dire un module qui transforme automatiquement les données en charts. Le repo open source chart-visualization-skills en propose plusieurs gratuits et compatibles avec Claude Code.
Cas d’usage 2 : Alertes sur logs
L’un de nos utilisateurs a récemment passé six jours à investiguer pourquoi des sections entières de son site avaient disparu de sa structure.
La cause : une mise à jour de leur rendu JS avait rendu certains groupes de pages totalement invisibles dans leur structure, sans déclencher d’alerte côté monitoring. Avec le bon setup MCP, ils auraient été alertés en quelques heures.
Ce type de défaillance silencieuse est fréquent, et la mise en place d’alertes sur logs reste l’un des points sur lesquels beaucoup de nos utilisateurs butent. Le MCP simplifie cette mise en place : une fois connecté, vous écrivez votre logique d’alerte en langage naturel, sans coder un système au-dessus des exports.
Pour ce cas d’usage, votre LLM doit être connecté à la fois au MCP Slack et au MCP Oncrawl.
Vérifiez en amont que vos logs sont correctement collectés par Oncrawl.
Pages vs events : choisir le bon objet
Le MCP d’Oncrawl expose un outil get_data_search_logs qui permet de requêter les logs projet sur deux types d’objets :
pagesevents
Utilisez pages quand vous voulez agréger des hits par URL (par exemple, suivre quelles pages sont crawlées et à quelle fréquence). Utilisez events quand vous avez besoin de lignes de logs brutes plutôt que de métriques agrégées.
Lorsque vous requêtez les pages, une granularité est obligatoire : days, weeks ou months.
Prompt prêt à l’emploi
Agrège les hits par bot et par jour pour obtenir une série quotidienne complète par bot sur 14 jours — pas une comparaison période vs période. Filtre uniquement sur les hits de bots. Bots à surveiller : [liste séparée par des virgules, ex. "claude_bot, openai_gpt_bot, google_smartphone, bing_web_search" — ou écris "all available bots" pour tracker tous les bots détectés par Oncrawl]. Pour chaque bot, examine sa courbe quotidienne sur 14 jours et flag : - Pic soudain : une journée nettement au-dessus du niveau normal du bot - Chute soudaine : une journée nettement en dessous du niveau normal - Baisse lente mais régulière : tendance descendante sur plusieurs jours - Bot silencieux : 2+ jours consécutifs à zéro après une période active Envoie une alerte Slack à [#CHANNEL ou @USER] résumant tes constats : le bot concerné, le type de variation, les jours impactés, et le volume affecté comparé à la moyenne quotidienne du bot sur 14 jours. Si rien d'anormal ne ressort, envoie une note courte "tous les bots sont stables sur les 14 derniers jours". Exécute ce check [quotidiennement | hebdomadairement].
Cas d’usage 3 : Alertes crawl-over-crawl
Là où le cas d’usage précédent surveille le comportement des bots dans vos logs, celui-ci surveille les variations dans votre propre structure. Trois besoins reviennent systématiquement chez nos utilisateurs avancés :
1. « Dis-moi ce qui a changé depuis le dernier crawl. »
Une vue différentielle, pas seulement des métriques absolues. Idéalement avec un baseline statistique (écart-type) pour distinguer une variation normale d’une anomalie.
2. « Alerte-moi sur le bon canal, à une cadence raisonnable, avec un seuil que je contrôle »
Slack et Teams plutôt que l’email, quotidien sur les URLs critiques, variation en pourcentage plutôt qu’en valeur absolue sur les gros sites.
3. « Ne me force pas à recoder un système d’alerting au-dessus des exports. »
Aujourd’hui beaucoup de utilisateurs tournent avec du cron, des scripts et Data Studio pour combler ce manque.
Le template de prompt ci-dessous couvre ces trois besoins. Il combine comparaison crawl-over-crawl, seuils paramétrables (absolu, pourcentage, écart-type) et delivery Slack.
À propos de CronCreate
Le template ci-dessous peut être utilisé de manière ponctuelle ou récurrente. Lorsqu’une exécution récurrente est demandée, il s’appuie sur CronCreate, un outil de planification exposé par le serveur MCP.
CronCreate permet d’enregistrer une tâche afin qu’elle soit exécutée automatiquement selon une cadence définie (quotidienne, hebdomadaire, etc.). Dans l’implémentation visée par ce template, la planification est persistée et continue de fonctionner même après un redémarrage de session.
Vous n’avez donc pas besoin de relancer le prompt manuellement à chaque exécution. C’est ce qui transforme une analyse crawl-over-crawl ponctuelle en système d’alerte automatisé et récurrent.
Template (contenu recommandé)
Lance une analyse crawl-over-crawl Oncrawl sur le projet
[NOM DU PROJET ou PROJECT ID — à retrouver via list_projects si inconnu].
Compare le dernier crawl avec [le crawl précédent | le crawl ID X].
Traque les changements suivants :
[choisis-en un ou plusieurs :
- nouvelles pages ajoutées depuis le dernier crawl ← cas "rogue content"
- pages supprimées depuis le dernier crawl
- transitions de status code (ex. 200→404, 200→301, 4xx→2xx)
- nouvelles pages orphelines (pages ayant perdu tous leurs inlinks)
- décalage de profondeur supérieur à [N] niveaux
- chute d'inrank supérieure à [X%] sur les pages du [page group]
- chute de trafic sur les pages indexables : gsc_clicks en baisse >[X%]
- filtre OQL custom : [colle ton OQL JSON ou ton filtre en français]
]
Scope :
- segmenter par [page group | langue | pays | bucket de profondeur | aucun]
- restreindre aux pages où [OQL optionnel : ex. status_code equals 200
AND indexable equals true AND page_group equals "/products/"]
Déclenche l'alerte uniquement si :
- le nombre de pages modifiées dépasse [N en absolu]
OU
- le changement dépasse [X%] de toutes les pages du scope ← seuil mega-site
OU
- le compte du jour est à plus de [Z=2] écarts-types au-dessus de
la moyenne quotidienne [sur 14 jours] pour ce type de changement
← baseline écart-type
Pour chaque changement flaggé, retourne :
- le type de changement
- le compte + % du scope
- le top [10] des URL affectées (triées par [inlinks desc | gsc_clicks
desc | inrank desc])
- les valeurs précédentes vs actuelles côte à côte
- la requête OQL utilisée (pour pouvoir la rejouer dans l'UI)
Poste le résultat sur Slack :
- canal ou DM : [#CHANNEL ou @USER]
- format : résumé exécutif court en tête, puis un bullet par changement
flaggé, puis un bloc dépliable avec les URL affectées
- si rien ne franchit le seuil : envoie une ligne "all stable" sur le
même canal (ou skip — à toi de choisir : [send | skip])
- delivery : [draft à réviser avant envoi | envoi direct]
Cadence :
- exécute [chaque jour à 09:00 Europe/Paris | chaque lundi à 09:00 |
one-shot]
- jours ouvrés uniquement : [yes | no]
- si récurrent, enregistre la planification via CronCreate pour qu'elle
survive aux redémarrages de session ; rappelle-moi dans la première
réponse comment l'annuler.Cas d’usage 4 : Combiner plusieurs MCP pour répondre à des questions qu’aucun outil seul ne peut couvrir
Les trois cas d’usage précédents exploitaient un seul MCP, celui d’Oncrawl, parfois combiné à celui de Slack pour la livraison d’alertes. Mais certaines questions SEO vivent à l’intersection de plusieurs sources de données : la structure crawlée, les performances Search Console, l’état d’indexation côté Google.
Brancher plusieurs MCP au même LLM permet d’y répondre sans rebasculer entre cinq outils.
L’exemple qui suit illustre ce principe avec un cas concret : croiser les données d’Oncrawl avec celles de l’URL Inspection API de Google Search Console.
Brancher le MCP GSC en complément du MCP Oncrawl
Un cas d’usage régulièrement remonté par nos utilisateurs consiste à brancher le MCP de la Google Search Console à votre LLM, en complément du MCP Oncrawl. Un projet open source de la communauté expose les outils GSC en MCP. Il permet de fusionner les données Search Console avec celles d’Oncrawl directement dans la conversation.
Note de sécurité : Il ne s’agit pas d’un MCP officiel de Google. Le projet est open source et maintenu par la communauté. Nous vous invitons à conduire un audit de sécurité avant de l’exécuter sur votre machine, en particulier si vous travaillez sur des projets clients.
Lien du projet : https://github.com/AminForou/mcp-gsc
Le projet met à disposition plusieurs outils, notamment :
inspect_url_enhanced: retourne le status crawl/index détaillé d’une URLcheck_indexing_issues: vérifie les problèmes d’indexation sur une liste d’URLs
Ce que vous gagnez en croisant les deux sources
L’intérêt principal de ce MCP est de croiser des données GSC qui ne sont pas exposées dans Oncrawl, et de les confronter à votre structure crawlée.
Notamment :
- les pages effectivement indexées dans Google
- la date de la dernière visite de Googlebot
- les indexing issues remontés dans la GSC
Vous obtenez ainsi un tableau d’actionnabilité qui répond à des questions concrètes :
- Combien de pages sont indexées dans Google mais considérées comme orphelines par Oncrawl ?
- Combien de pages ne sont pas fetchées par Oncrawl alors qu’elles sont crawlées et indexées par Google ?
- Combien de pages sont exclues de l’index de Google malgré leur présence dans la structure ?
Trois buckets de diagnostic
Le prompt ci-dessous structure l’analyse en trois buckets, chacun correspondant à un mode de défaillance distinct :
- Bucket A : pages présentes dans la structure mais qu’Oncrawl ne peut pas fetcher. Signal d’un blocage technique (robots.txt, erreur serveur intermittente, ressources bloquées).
- Bucket B : pages orphelines hors structure qui présentent pourtant des signaux de découverte côté GSC (clicks, présence en sitemap). Signal d’un problème de maillage interne.
- Bucket C : pages crawlées par Oncrawl mais non indexables. Signal de configuration on-page à arbitrer (canonical, noindex, redirections).
Note sur le quota GSC : L’URL Inspection Tool est soumise à un taux limité de 2 000 URLs par jour. Tenez-en compte dans votre échantillonnage.
Prompt prêt à l’emploi
Croise les données d'inspection URL de la Google Search Console avec
les données de crawl Oncrawl pour {{GSC:property}} (projet
{{Project_IID}}, dernier crawl).
Objectif : comprendre pourquoi certaines pages sont non crawlées,
moins crawlées, ou non indexées.
Utilise le MCP Oncrawl et le MCP GSC. Construis trois buckets de
diagnostic :
- Bucket A : pages in-structure qu'Oncrawl ne peut pas fetcher
(`depth has_value AND fetched=false`)
- Bucket B : orphelines out-of-structure avec signaux de découverte
(pas de depth, mais GSC clicks / SEO visits / présence sitemap)
- Bucket C : crawlées mais non indexables
(`fetched=true AND indexable=false`)
Pour chaque bucket, échantillonne les URL via l'API URL Inspection de
la GSC, puis assigne un label diagnostic par paire (état Oncrawl ×
verdict GSC). Respecte le quota GSC (10 URL par batch, 2 000 par jour).
Livrable : un document de plan structuré avec :
- objectif
- prérequis
- approche
- findings (counts, top orphelines par trafic SEO, matrice de
diagnostic)
- actions priorisées (P0 → P4)
- questions ouvertes
- dépendances.Conclusion
Ces quatre cas d’usage ne sont pas figés, et chacun gagne à être adapté à votre contexte. Deux principes valent la peine d’être gardés en tête avant de les déployer.
Cadrez votre périmètre
Les LLMs raisonnent mieux sur des datasets resserrés que sur des structures de plusieurs millions d’URLs. Échantillonnez, segmentez par page group, ou restreignez par filtre OQL avant de lancer l’analyse. Vous y gagnerez en précision et en coût de tokens.
Vérifiez avant d’industrialiser
Un prompt qui tourne en one-shot pour explorer une hypothèse n’a pas les mêmes exigences qu’un prompt programmé en récurrent via CronCreate.
Avant de pousser une alerte Slack quotidienne en production, faites tourner le prompt manuellement sur une ou deux semaines, vérifiez les seuils, et confirmez que les requêtes OQL générées correspondent à ce que vous attendez dans le Data Explorer.
Pensez multi-MCP pour toutes metrics qui ne peuvent être produites par Oncrawl
Les questions SEO les plus intéressantes vivent à l’intersection de plusieurs sources : structure crawlée, performance GSC, comportement des bots dans les logs, état d’indexation côté Google. Brancher plusieurs MCP au même LLM, c’est ce qui vous permet de répondre à ces questions sans rebasculer entre cinq outils.
Si vous mettez en place vos propres prompts au-dessus du MCP Oncrawl et que vous identifiez des schémas récurrents qui méritent d’être partagés, faites-nous signe.
C’est souvent à partir des workflows que vous construisez sur le terrain que naissent les prochaines fonctionnalités natives de la plateforme.
