Documentation AX Protocol — installer et configurer un site WordPress prêt pour les agentsAX Protocol — Documentation

Cohabiter avec votre SEO, votre cache et votre CDN

Presque tous les sites qui installent AX Protocol font déjà tourner une extension SEO, une couche de cache et souvent un CDN. Ces trois éléments touchent précisément les fichiers que le protocole génère : il vaut donc mieux fixer l’ordre des opérations avant de commencer plutôt que de le déboguer ensuite. Votre extension SEO reste propriétaire de sitemap.xml et des balises canoniques. AX Protocol ne remplace ni l’un ni l’autre ; il ajoute une couche de manifeste au-dessus. Lorsque deux composants écrivent au même chemin, c’est le dernier de la chaîne qui l’emporte : vérifiez toujours le fichier en ligne plutôt que de vous fier à l’écran de réglages.

Le cache est de loin la première source de problèmes qui ressemblent à des bogues du protocole. Un manifeste mis en cache avant un changement de réglage continuera d’être servi aux agents pendant des heures, et le site déclarera alors une structure qui ne correspond plus à son contenu. La règle est simple : après toute modification, videz l’intégralité du cache et vérifiez le fichier en ligne dans une fenêtre privée. Si vous utilisez un CDN, ajoutez une purge en périphérie, sinon l’origine sert la nouvelle version pendant que visiteurs et agents reçoivent encore l’ancienne.

Le troisième composant est votre pare-feu applicatif. Plusieurs fournisseurs bloquent par défaut les requêtes dépourvues d’empreinte de navigateur reconnue, et les agents IA entrent pleinement dans cette catégorie. Si les vérifications locales passent mais que la même requête depuis l’internet ouvert renvoie un 403, soupçonnez une règle de blocage avant de soupçonner l’extension. Commencez par ajouter les chemins du manifeste à la liste d’autorisation.

Vérifications manuelles

Le tableau de bord rapporte ce que l’extension pense avoir publié. Ce n’est pas la même chose que ce qu’un agent reçoit, et l’écart est plus fréquent qu’on ne l’imagine. Quatre vérifications prennent environ cinq minutes et détectent la majorité des défaillances réelles.

D’abord, demandez le manifeste avec un client HTTP simple plutôt qu’avec un navigateur et confirmez que vous obtenez un 200 et du JSON valide, et non une page de défi HTML. Ensuite, récupérez de la même manière une page de contenu importante et vérifiez que le texte de fond est présent dans la réponse brute — si le corps arrive vide, votre contenu est injecté par JavaScript et les agents ne le verront jamais. Troisièmement, suivez chaque URL déclarée dans le manifeste et confirmez qu’aucune ne redirige ni ne renvoie un 404, car un manifeste qui pointe vers des chemins morts est pire que pas de manifeste du tout. Quatrièmement, répétez la première vérification depuis l’extérieur de votre réseau, idéalement sur une connexion mobile, afin d’écarter une liste d’autorisation par IP qui ne rend sain que votre bureau.

Consignez les résultats quelque part. Quand quelque chose cassera dans trois mois, le chemin le plus rapide vers le diagnostic sera la trace de ce à quoi ressemblait un état qui fonctionnait.

Mises à jour, migrations et compatibilité dans la durée

Changer d’hébergeur, de domaine ou passer à un sous-domaine sont les événements les plus susceptibles de casser la configuration du protocole, car les URL absolues stockées dans les réglages continuent de pointer vers l’ancien emplacement. Documentez votre configuration avant une migration et parcourez ensuite chaque chemin du manifeste pour confirmer qu’il se résout à la nouvelle adresse. Si le site est aussi passé de HTTP à HTTPS, surveillez les redirections en double au passage : une longue chaîne de redirections pousse certains agents à abandonner la requête en cours de route.

Les mises à jour de l’extension sont moins risquées, mais pas sans risque. La spécification est versionnée, et un changement de version majeure peut modifier les noms de champs du manifeste. Lisez la note de version avant une mise à niveau majeure et, si vous avez construit quoi que ce soit qui consomme votre propre manifeste, testez-le contre la nouvelle sortie avant de le déployer en production.

Si vous n’avez le temps que pour trois choses

S’il s’agit d’une première mise en œuvre et que vous ne pouvez pas traiter chaque section, trois éléments apportent l’essentiel de la valeur : un manifeste valide qui se résout au chemin attendu, une description de l’organisation en une ligne, précise, qui dit ce que fait le site et pour qui, et un catalogue de services contenant les pages que vous voulez réellement voir citées. Tout le reste — points d’accès étendus, réglages de permissions, découverte avancée — peut s’ajouter progressivement. Un site doté de ces trois éléments est déjà raisonnablement lisible pour les agents, et vous pourrez l’améliorer à partir de ce que montrent les journaux du serveur plutôt qu’au jugé.

La place d’AX Protocol dans un site multilingue

Si le site tourne en plusieurs langues, décidez tôt quelle langue le manifeste décrit. Le protocole émet un manifeste par variante linguistique, et les agents suivent les mêmes signaux hreflang que les moteurs de recherche : un ensemble de traductions correctement câblé signifie qu’un agent qui interroge en espagnol atteint la page espagnole plutôt que l’anglaise. Un ensemble de traductions cassé signifie que chaque langue retombe sur la langue par défaut, ce qui est pire que de n’avoir aucune traduction.

La vérification est rapide : récupérez la racine de chaque langue et confirmez que les liens alternates listent toutes les variantes plus x-default, et que chaque variante pointe vers une URL qui renvoie un 200 dans cette langue. Les sites construits en clonant des pages d’une langue à l’autre échouent souvent à ce test, parce que les copies n’ont jamais été liées dans un groupe de traduction et que chacune se présente aux agents comme un document sans rapport.