Vérificateur de préparation des agents

Free, no signup. Inventory the public files and headers that can describe an agent-capable site. Every signal keeps a visible state, and a failed fetch never becomes a negative verdict.

Built by Patrick Stox

Public website URL

Signal evidence

Next steps

Check AI crawler access
Test robots directives and crawler-specific access separately.
Build llms.txt
Create the optional discovery file when it fits the site.

Les contrôles sont exécutés depuis notre serveur ; nous récupérons l’URL saisie et ne conservons pas les résultats. Des compteurs anonymes de résultats par exécution peuvent servir à la recherche agrégée ; les URL, domaines, adresses IP et identifiants ne sont jamais inclus, et aucune statistique issue de moins de 100 exécutions n’est publiée.

Commentaires

À propos de cet outil

Vérifiez les signaux publics de découverte des agents et la présence récente dans Common Crawl, en distinguant l’absence des échecs de récupération.

Fonctionnalités

Cinq contrôles pondérés de chemins et d’en-têtes, complétés par des cartes de sensibilisation Common Crawl et RFC 9421.
États distincts pour l’absence, le contenu invalide et les preuves indisponibles.
Pondération visible et reproductible sur 7 points plutôt qu’un score de modèle caché.
Tests limités à la surface publique, sans compte ni intégration au site.

Fonctionnement

Le navigateur interroge la racine, les fichiers de découverte A2A, MCP, llms.txt et security.txt, puis consulte trois index Common Crawl pour l’URL exacte. Les JSON doivent être analysables, llms.txt ne doit pas produire d’erreur et Content-Signals doit apparaître dans un en-tête. Les signaux A2A et MCP valent deux points chacun ; les autres signaux valent un point. La présence dans Common Crawl reste informative.

Limites

L’outil inventorie des signaux de découverte ; il ne vérifie pas la conformité d’un protocole ni la visibilité future dans les réponses IA.
Une réponse JSON valide ne prouve ni le fonctionnement d’un agent, ni l’authentification, ni la disponibilité d’un endpoint.
Un CDN, un défi anti-bot ou un blocage régional peut empêcher l’évaluation d’une ressource pourtant accessible ailleurs.

Questions fréquentes

Que mesure le score de préparation aux agents ?

Il s’agit d’un inventaire pondéré élémentaire de cinq indices accessibles à tous : une carte d’agent `A2A`, un manifeste `MCP`, `llms.txt`, `security.txt` et l’en-tête de réponse `Content-Signals`. La présence récente dans `Common Crawl` apparaît séparément et ne modifie pas le score. Le rapport ne détermine pas si un système d’IA utilisera, citera ou classera le site.

Le fait de ne pas avoir de fichier `llms.txt` empêche-t-il les robots d’IA d’utiliser mon site ?

Non. `llms.txt` est un format proposé, et non un mécanisme de découverte obligatoire ni un dispositif de contrôle d’accès documenté pour les principaux robots. Cela signifie uniquement que ce fichier facultatif n’a pas été trouvé.

Pourquoi un indice est-il marqué comme non évalué ?

Le vérificateur n’a pas pu obtenir de réponse exploitable, par exemple parce que la requête a échoué ou a renvoyé un statut d’échec autre que 404. L’état « non évalué » n’est jamais traité comme absent, invalide ou réussi.

Qu’est-ce qui rend une carte d’agent ou un manifeste `MCP` valide ici ?

Ce contrôle léger confirme uniquement que le fichier accessible à tous renvoie une réponse réussie et peut être analysé comme `JSON`. Il ne certifie ni la conformité au protocole, ni les points de terminaison, ni l’authentification, ni la sécurité opérationnelle.

Chaque site web doit-il publier les cinq indices ?

Non. Les cartes d’agent et les manifestes `MCP` concernent les sites qui proposent intentionnellement des connexions destinées aux agents ou aux outils. Un site éditorial ou marchand ordinaire peut parfaitement fonctionner sans eux.

La carte `Web Bot Auth` prouve-t-elle que l’authentification des robots fonctionne ?

Non. Elle indique uniquement les preuves de `HTTP Message Signature RFC 9421` présentes dans la réponse. La récupération normale d’une page non signée ne peut pas démontrer que l’infrastructure en bordure exige ou vérifie les requêtes signées des robots d’IA ; faute de preuve observée, l’état affiché est « non évalué » plutôt que « non pris en charge ».

Étape suivanteServeur MCP pour le SEO — run the full end-to-end workflow. Des conseils sont disponibles en anglais.

Problèmes courants et solutions

Erreur Le fichier de découverte de l’agent est manquant Solution : Publiez la ressource A2A 1.0 /.well-known/agent-card.json sous forme de JSON valide et accessible à tous, décrivant le point d’accès de l’agent et ses capacités prises en charge.
Erreur Le JSON de découverte de l’agent est mal formé Solution : Corrigez la syntaxe JSON et la structure de découverte requise dans /.well-known/agent-card.json, puis vérifiez que le fichier renvoie un JSON analysable avec un statut 2xx.
Erreur Le fichier de découverte MCP est manquant Solution : Publiez /.well-known/mcp.json sous forme de JSON valide et accessible à tous, identifiant le point d’accès du serveur MCP et le mode de communication pris en charge.
Erreur MCP découverte JSON est mal formé Solution : Corrigez la syntaxe et les champs de découverte dans /.well-known/mcp.json, puis vérifiez que le fichier est analysable et que son point d’accès déclaré est joignable.
Erreur Le point d’accès de l’agent déclaré est injoignable Solution : Corrigez l’URL du point d’accès, le DNS/TLS, l’exposition de l’authentification ou la réponse du serveur afin qu’une application externe reçoive la poignée de main 2xx attendue.
Avertissement Le fichier de découverte omet des capacités attendues Solution : Ajoutez au fichier de découverte la capacité omise et réellement prise en charge, puis implémentez-la au point d’accès déclaré avant de l’annoncer.
Avertissement Les exigences d’authentification ne sont pas claires Solution : Indiquez dans le fichier de découverte le schéma d’authentification, l’emplacement du jeton, les portées requises et le comportement de la découverte sans authentification.