Vérification GEO : corrections et visibilité IA

Un correctif déployé et une meilleure réponse IA sont deux constats distincts

La vérification GEO commence par une distinction : prouver qu’une modification du site est en ligne ne revient pas à observer une évolution des réponses IA. Les deux comptent, mais demandent des preuves différentes. Un contrôle réussi peut établir qu’une condition est remplie sur le site ; il ne prouve pas que le modèle d’un tiers a lu la modification ou qu’il la citera.

Imaginons un produit fictif dont la page de tarifs omet une limite fonctionnelle. Un développeur ajoute la limite approuvée, déploie la page et vérifie la réponse publique. La correction du site est terminée. Une réponse IA ultérieure qui reprend l’ancienne limite constitue un autre constat. Elle peut s’appuyer sur une source plus ancienne, sur une autre page ou sur aucune source identifiable. La réponse seule ne permet pas de trancher.

La boucle de vérification relie ces observations sans les résumer à un statut vert unique. Partez du critère de validation du ticket, conservez les preuves du déploiement, puis recueillez des réponses comparables. Vous pouvez constater une correction validée sur le site sans évolution de la visibilité IA. Ce résultat reste utile.

Définir le critère de validation avant de modifier la page

Le critère doit être assez précis pour qu’une autre personne puisse le vérifier. « Rendre la page compatible avec l’IA » n’est pas testable. « La page de tarifs canonique affiche la limite approuvée sans exiger de connexion » l’est.

Notez l’URL exacte, le texte ou le comportement attendu, la source du fait approuvé et les éléments observés avant modification. Pour une correction de contenu, conservez le paragraphe concerné. Pour un problème d’accès, relevez la réponse reçue et la règle applicable. Une capture d’écran montre le rendu ; une capture de la réponse HTTP ou une inspection de la page permet d’examiner ce qui a été effectivement transmis.

Choisissez un contrôle adapté au défaut. Un statut HTTP 200 ne suffit pas à confirmer l’ajout d’une restriction d’abonnement. Si la page est bloquée, retrouver le bon texte dans une version locale ne prouve pas son accessibilité publique. Un badge « page validée » doit donc renvoyer à une explication plus précise.

Pour un site que vous gérez, voici un exemple d’inspection manuelle. Cette commande télécharge la réponse finale après redirections afin d’examiner la page déployée :

curl --location --silent --show-error \
  --dump-header /tmp/pricing-response-headers.txt \
  --output /tmp/pricing-response.html \
  --write-out 'HTTP %{http_code}\nFinal URL %{url_effective}\n' \
  https://example.com/pricing

Remplacez l’URL d’exemple par votre page publique et lisez le contenu téléchargé. Cette commande n’est pas l’implémentation du vérificateur CiteAura et ne simule pas tous les robots. Elle fournit la réponse reçue par un client. Si la restriction concerne un moteur précis, complétez l’examen avec sa documentation et les journaux de requêtes disponibles.

Un contrôle de robots.txt doit aussi tenir compte du groupe d’agent utilisateur et du chemin concernés. Chercher seulement le texte Disallow: / peut induire en erreur si un autre groupe s’applique au robot. La documentation des robots OpenAI distingue par exemple OAI-SearchBot de GPTBot. L’accès pour la recherche et un éventuel usage pour l’entraînement ne sont pas des critères de validation interchangeables.

Ce que vérifie réellement CiteAura

Lancez explicitement la vérification après avoir déployé les changements retenus. Dans Exécution → Vérification en boucle fermée, Lancer la vérification explore et audite à nouveau le site, puis évalue les tickets à partir du dernier audit et des fichiers de métriques existants. Passer un ticket à Terminé ne déclenche pas cette procédure à lui seul.

Le statut du ticket et le verdict du contrôle sont distincts. L’espace de travail propose des statuts opérationnels tels que À faire, En cours, Terminé, Bloqué et Ne sera pas corrigé. Le contrôle produit un verdict de réussite, d’échec ou d’examen manuel. Ce verdict décrit ce que le contrôle a établi, plutôt que l’appréciation de l’avancement par le responsable du projet.

Consultez la note du vérificateur et ses preuves, surtout lorsqu’une règle dépend de métriques. La vérification utilise les fichiers disponibles ; elle ne les remplace pas silencieusement par des réponses recueillies après déploiement. Un résultat dépendant de l’échantillonnage doit donc être lu avec la date et le périmètre de la collecte.

Certaines tâches demandent un jugement humain. Un contrôle peut établir l’existence d’un fichier sans établir l’exactitude de chaque phrase. Détecter des données structurées ne suffit pas non plus à confirmer leur cohérence avec la page visible. Les consignes de Google sur les données structurées exigent cette correspondance. Intégrez l’examen des faits à la validation, sans le reporter après l’apparition d’un badge vert.

Recueillir de nouvelles réponses dans une mesure distincte

Après la vérification du site, lancez une nouvelle collecte si vous voulez observer le comportement des réponses. Reprenez les questions initiales avec des paramètres fournisseur, un marché, un mode de collecte et des conditions de conversation comparables. Consignez les différences que vous ne maîtrisez pas, notamment un changement visible de version du modèle.

Passer d’une réponse API sans recherche à une conversation dans l’application grand public avec recherche activée change la mesure. Cette nouvelle observation peut être utile, mais ne constitue pas une comparaison avant/après homogène. La documentation de l’API de recherche web OpenAI décrit les réponses sourcées et les annotations de citation. Ces données sont plus informatives que l’hypothèse selon laquelle toute URL présente dans un texte généré correspond à une source effectivement consultée.

Séparez les réponses obtenues des requêtes en échec. Vérifiez l’exactitude de la mention de marque, les URL citées et leur capacité à étayer l’affirmation concernée. Examinez les questions avant de calculer une moyenne : un gain sur une question de découverte secondaire peut masquer une mauvaise réponse sur une limite commercialement importante.

Des observations répétées aident à repérer la variabilité, sans la supprimer. Si le modèle ou les sources ont changé pendant la même période que votre site, plusieurs causes peuvent expliquer l’écart. Conserver une page ou un groupe de questions inchangé peut fournir un point de comparaison lorsque c’est possible. Cela ne transforme pas une campagne d’observation en expérience randomisée.

Présenter l’écart sans lui faire dire davantage

Voici un calcul volontairement simple et hypothétique, qui ne décrit pas un résultat client de CiteAura. Lors de chaque collecte, les mêmes questions produisent 40 réponses obtenues et admissibles au calcul, pour un même fournisseur et un même mode :

• Avant la modification : 10 réponses mentionnent la marque, soit un taux de mention de 25 %.
• Après la modification : 14 réponses la mentionnent, soit un taux de 35 %.
• L’écart observé est de 10 points de pourcentage. La hausse relative est de 40 %, ce qui exprime une autre grandeur.

Aucun de ces calculs ne prouve que la modification a causé le changement. L’échantillon est limité, les réponses varient et les deux collectes ont pu rencontrer des sources différentes. Un rapport rigoureux donne les effectifs et les conditions de collecte, puis présente la hausse comme une observation à examiner au moyen de nouvelles mesures comparables.

Ne confondez pas ce dénominateur avec celui de la part d’un domaine parmi les sources. La vue Sources de citations de CiteAura regroupe par domaine les URL distinctes capturées dans une collecte terminée avec recherche web. La part du domaine décrit cet ensemble de sources, pas la proportion de toutes les réponses IA sur Internet qui citent votre site. Un pourcentage n’est interprétable que si son dénominateur est connu.

La même rigueur s’applique à un résultat stable. Si la limite approuvée est visible sur la page de tarifs mais que les réponses n’ont pas changé, rapportez les deux faits. Ne réécrivez pas continuellement une page exacte à cause d’une seule réponse ultérieure différente. Vérifiez d’abord ses sources et déterminez si la question porte réellement sur le fait corrigé.

Clôturer le travail sans masquer les points ouverts

Le dossier remis doit permettre à une personne extérieure au projet de reconstituer la décision. Incluez le ticket, l’URL publique, la date ou la révision du déploiement, le résultat de validation et la période de toute nouvelle collecte. Donnez accès aux preuves brutes plutôt qu’à un graphique dont les réponses sous-jacentes seraient introuvables.

Pour la correction tarifaire fictive, un bilan fidèle pourrait être : « La limite approuvée figure sur la page publique et le contrôle du site a réussi. Un échantillon comparable recueilli ensuite contient encore deux descriptions périmées. Nous avons conservé ces réponses et leurs citations pour examiner les sources. » Le même compte rendu décrit ainsi le travail terminé et le problème de qualité restant.

CiteAura peut réunir le diagnostic actuel, les tickets, les preuves et les ressources dans un pack de livraison. Vérifiez s’il est destiné à la revue, au diagnostic ou à l’implémentation. Un ZIP généré peut contenir des travaux inachevés et des limites explicites ; sa création ne certifie pas que toutes les ressources sont déployables. La documentation de vérification et de livraison décrit le processus actuel.

Le suivi programmé peut actualiser l’exploration, les échantillons et les rapports, tandis que la vérification reste une étape explicite. Reprenez les contrôles concernés après des mises en production importantes et examinez les changements répétés sur des ensembles comparables. Les consignes de Google sur ses fonctionnalités IA précisent aussi que le respect des exigences ne garantit ni l’indexation ni l’affichage. Aucun délai général ne transforme un contrôle du site réussi en citation garantie.

Si le constat initial reste vague, revenez au diagnostic de marque avant d’ajouter de l’automatisation. La boucle est complète lorsque le dossier explique la modification, le contrôle effectué, le résultat observé et la décision qui en découle.