Relier observations des robots IA, citations et trafic référent

Chaque page qui présente des occurrences de robots sans citation observée pose une question : le problème relève-t-il de l’équipe technique, de l’équipe éditoriale ou de personne pour le moment ? Ce workflow sépare quatre couches de données, puis répond à cette question pour chaque page avec une règle qui s’arrête au premier critère correspondant.

Le problème GEO résolu

Le raccourci se produit deux fois : observé donc traité, cité donc cliqué. get_crawler_activity repose sur un état synthétique borné des robots, et non sur des événements HTTP conservés, ce qu’il précise : chaque robot est accompagné des dates de première et dernière observation, d’un nombre d’occurrences sur tout l’historique et d’une note explicite indiquant que les événements bruts ne sont pas disponibles. Aucun code de statut, aucun corps de réponse, aucune ligne par page, aucun paramètre de période. Et une session issue d’une IA n’identifie jamais la citation à l’origine du clic.

Les périodes diffèrent aussi par construction, source discrète de calculs erronés. get_referrer_analytics termine sa plage un jour avant aujourd’hui, car les données GA4 ont du retard, tandis que get_search_console_metrics et get_bing_metrics la terminent aujourd’hui.

Les étapes du workflow

1. Lisez d’abord l’état de connexion. get_crawler_activity fournit l’indicateur de connexion et chaque robot observé avec ses dates de première et dernière observation, ainsi que son nombre d’occurrences sur tout l’historique. Un robot dont la dernière observation précède votre période n’a aucune observation sur la période courante dans cette couche, quel que soit le contenu du tableau des pages.

2. Classez les pages par activité de robots observée. get_page_performance renvoie les occurrences par chemin avec jusqu’à cinq robots principaux par chemin, ainsi qu’un groupe explicite pour la longue traîne. La limite de lignes est plafonnée à 100 : comparez donc les lignes renvoyées au nombre total de groupes de pages avant d’interpréter une absence comme un zéro.

3. Ajoutez l’état technique de chaque page. get_site_diagnostics renvoie les scores technique, de contenu, AEO et de performance par page suivie, le nombre de problèmes ouverts par gravité et la date du dernier audit, en commençant par les moins bons scores. Il ne lit que les pages suivies : un chemin exploré qui n’a jamais été enregistré n’apparaît donc jamais.

4. Ajoutez les preuves de citation et de trafic référent. get_page_presence fournit le statut et le nombre de citations par page, get_source_urls récupère les URL exactes citées et get_referrer_analytics renvoie les sessions issues des IA avec leurs principales pages de destination. Transmettez la même période de preuve de 30 jours aux deux outils de citation ; la plage analytique peut malgré tout se terminer un jour plus tôt en raison du retard de GA4.

5. Rapprochez les données et attribuez les actions. Effectuez le rapprochement sur une clé normalisée composée de l’hôte et du chemin, et qualifiez précisément chaque absence : non renvoyée, non observée, explicitement non citée ou non auditée.

Ce qu’une exécution renvoie réellement

Une exécution valide renvoie quatre populations distinctes : observations de robots, diagnostics des pages suivies, preuves de citation des pages sur la période demandée et sessions issues des IA sur la plage analytique. Leurs nombres de lignes peuvent différer même lorsque chaque appel fonctionne correctement.

Lire ces lignes comme un entonnoir resterait incorrect. Une page suivie peut ne pas être citée sans pour autant être éligible à une citation, et une session de trafic référent n’identifie jamais la citation qui l’a précédée. La ligne exploitable est une URL observée dans une couche et absente de l’inventaire opérationnel suivant, avec une qualification précise de cette absence.

Comment exploiter les résultats

Une condition préalable, puis une règle d’attribution.

La condition : si un indicateur connected est renvoyé à false, le backlog contient exactement une tâche, connecter cette intégration. Un tableau vide provenant d’une surface déconnectée ne constitue pas un constat. Deux autres absences ne sont pas non plus des zéros : une page absente des principales pages de destination se trouve en dehors d’une liste tronquée, et une page absente du tableau des robots peut appartenir au groupe de longue traîne. Ne divisez jamais les citations par les occurrences de robots, même lorsque les périodes demandées correspondent : leurs populations et leurs systèmes de collecte diffèrent.

La règle d’attribution s’applique ensuite à chaque page présentant des occurrences de robots sans citation. Arrêtez-vous au premier critère correspondant. Une absence totale dans get_site_diagnostics signifie qu’il ne s’agit pas d’une page suivie : enregistrez-la et relancez l’analyse, car vous avez une URL non gérée, pas un diagnostic. Une date de dernier audit null et des scores null signifient qu’elle n’a jamais été auditée : mettez l’audit en attente et arrêtez-vous. Un ou plusieurs problèmes CRITICAL ouverts en font un ticket technique, pas un brief de rédaction. Des scores présents sans problème CRITICAL ouvert en font une question de contenu et d’autorité, confiée à l’équipe éditoriale.

Le prompt complet

Je veux un audit d’observabilité IA par page. Si je suis plusieurs marques, demande laquelle utiliser. Garde les requêtes des robots, l’état technique, les citations et le trafic référent IA en quatre couches distinctes, jamais sous forme d’entonnoir. Utilise les 30 derniers jours. Demande-moi d’abord mon hôte canonique et mes alias d’URL, car aucun outil ne sait quels hôtes m’appartiennent.

1. Exécute get_crawler_activity. Indique l’indicateur connected et chaque robot avec firstSeen, lastSeen et ses occurrences sur tout l’historique. Décris ce résultat comme une vue de l’état des robots sur tout l’historique, sans événements bruts ni codes de statut, et signale tout robot dont lastSeen précède la période.
2. Exécute get_page_performance sur 30 jours. Indique l’indicateur connected, la plage de dates renvoyée, les lignes de pages avec leurs occurrences et principaux robots, ainsi que le groupe de longue traîne. Compare les lignes renvoyées au nombre total de groupes de pages et signale toute troncature. Si la connexion est active mais qu’aucune ligne de page n’est renvoyée, indique-le plutôt que d’en déduire une absence d’exploration.
3. Exécute get_site_diagnostics. Renvoie chaque page suivie avec ses quatre scores, ses nombres de problèmes par gravité et la date du dernier audit. Traite un score null comme non audité, jamais comme zéro.
4. Exécute get_page_presence avec period 30, puis get_source_urls avec period 30 lorsqu’une URL exacte citée est nécessaire. Conserve tout périmètre de sujet, tag, fournisseur ou étape du parcours d’achat dans les deux appels. Utilise NOT_CITED uniquement lorsque l’outil le renvoie, et ne divise jamais les citations par les occurrences de robots.
5. Exécute get_referrer_analytics sur 30 jours, puis get_search_console_metrics et get_bing_metrics par page si les connexions sont actives. Affiche chaque plage de dates renvoyée et précise que la plage GA4 se termine un jour plus tôt.

Si un indicateur connected est false, arrête-toi et renvoie une seule tâche : connecter cette intégration.

Sinon, construis la matrice sur l’hôte canonique et le chemin normalisé, puis attribue une action à chaque page explorée sans citation, en t’arrêtant au premier critère correspondant. Une absence des diagnostics du site signifie qu’il faut l’enregistrer comme page suivie. Une date de dernier audit null et des scores null signifient qu’il faut mettre l’audit en attente. Un problème CRITICAL ouvert signifie qu’il faut créer un ticket technique. Sinon, il s’agit d’un travail éditorial. Donne à chaque ligne ses preuves et son responsable.