Les agents IA peuvent-ils utiliser votre site Web ? Un test d’acceptation pratique

Un assistant demandé à comparer votre service avec un autre a besoin de preuves utilisables : ce que vous offrez, à qui il s’adresse, ce que signifient les termes et où aller ensuite. Un assistant demandé à réserver une démo a également besoin d’une action fonctionnelle. Une page peut fournir la première et échouer la seconde. La question utile est précise : l’assistant prévu peut-il accomplir la tâche prévue sur la page publique ? Notre guide de préparation à la recherche IA aborde les obstacles techniques à la découverte. Ce test d’acceptation étend ce travail à la personne qui souhaite qu’un assistant utilise le site.

Définissez une tâche avec un résultat vérifiable

Choisissez une tâche qu’un client réel effectue déjà. Pour une entreprise de services, un point de départ utile est : « Trouvez si ce service prend en charge ma localisation, identifiez la page de service pertinente et montrez-moi comment demander une consultation. » Exécutez le test sur les informations publiques sans soumettre de formulaire ou modifier les données client. Écrivez la réponse attendue avant de tester. Enregistrez les localisations prises en charge, le service actuel URL et l’action de consultation réelle. Cela vous donne un moyen de distinguer une réponse convaincante d’une réponse correcte. Utilisez un enregistrement simple :

Il s’agit d’un enregistrement illustratif, pas d’un résultat client. Conservez l’assistant, la date de test et le début URL avec l’enregistrement afin que la prochaine exécution puisse être comparée équitablement.

Séparez l’accès, la lecture et l’action

Commencez par ce que l’assistant a réellement reçu. Une page de connexion, un interstitiel de consentement ou un défi bot peut remplacer la page que vous voyez dans votre propre navigateur. Un code de statut réussi seul ne peut pas prouver que la description du service a été livrée. Enregistrez la réponse observée ou une capture d’écran redacted et identifiez quel contenu prévu manque. Ensuite, comparez l’offre visible avec le contenu disponible pour l’assistant. Certains outils récupèrent du texte ; d’autres exécutent un navigateur et inspectent la page. Testez l’outil que vos clients utilisent. Google décrit les agents de navigateur capables d’inspecter la sortie visuelle, le DOM et l’arbre d’accessibilité dans ses guidelines sur les expériences agentiques. Une page JavaScript nécessite donc un test observé, pas une déclaration générale que chaque assistant peut ou ne peut pas la lire. Enfin, suivez l’action. Un lien clairement nommé doit mener à la destination prévue. Un formulaire doit exposer des libellés compréhensibles et des retours de validation. Si une tâche nécessite une authentification, un paiement ou une permission, enregistrez cette frontière. Une tâche qui s’arrête correctement pour approbation se comporte différemment d’une qui perd le bouton ou invente une confirmation. Notre JavaScript guide de rendu est utile lorsque le contenu qu’une personne voit et le contenu qu’un outil de récupération reçoit divergent.

Choisissez les politiques d’accès par objectif

La recherche, la formation de modèle et l’activité dirigée par l’utilisateur ont des contrôles différents. OpenAI documente des paramètres indépendants pour OAI-SearchBot et GPTBot : les propriétaires de sites peuvent autoriser la recherche tout en refusant la formation. Son agent ChatGPT-User a un rôle dirigé par l’utilisateur distinct. Utilisez la documentation du crawler du fournisseur lors de la décision de politique. Anthropic distingue également Claude-SearchBot, ClaudeBot et Claude-User dans ses guidelines de crawler. Vérifiez l’objectif prévu, la politique du site et le résultat d’accès observé ensemble. Une opt-out d’entraînement n’est pas, en soi, une preuve que l’accès à la recherche est cassé. Examinez l’hébergement et les contrôles CDN ainsi que robots.txt. Déclarer une permission dans un fichier ne permet pas de réussir une requête réseau bloquée. Pour un trafic légitime, vérifiez le fournisseur via son processus d’identification documenté avant de modifier une règle. Copier une chaîne d’agent utilisateur dans une requête teste comment cette requête est traitée ; elle ne reproduit pas une requête fournisseur vérifiée.

Rendez l’étape suivante découvrable

Conservez les faits produits importants sur des pages stables et liées. Indiquez les capacités en langage courant et placez les qualifications à côté de la revendication qu’elles limitent. Une page qui dit « intègre votre flux de travail » doit lier à la documentation expliquant l’opération supportée et ses exigences d’accès. Pour les sites qui offrent un API public ou une intégration MCP, publiez l’interface supportée et les exigences d’authentification. L’intégration d’agent de SEOReport permet aux assistants compatibles de demander des rapports via l’interface produit documentée. C’est une capacité distincte d’un assistant découvrant SEOReport dans une réponse de recherche. Un fichier de navigation lisible par machine peut aider un outil qui le consomme explicitement. Vérifiez son utilisation avant de traiter le fichier comme faisant partie de vos critères d’acceptation. Les liens fonctionnels et la documentation publique utile restent précieux pour les gens également.

Répétez la même tâche après la réparation

Conservez l’enregistrement de test original. Répétez après le changement en utilisant le même URL de départ et la même tâche, puis inspectez la preuve de destination ou de réponse réelle. Enregistrez tout changement dans l’assistant ou son mode de récupération qui limite la comparaison. La réussite de la tâche établit que cette interaction testée a fonctionné. Les citations de recherche, les visites de référence et les décisions client ont besoin de leur propre mesure. Ensemble, ces observations vous indiquent si le site est devenu plus facile à découvrir, plus facile à utiliser, ou les deux.