LLMs.txt et WordPress : vérifier, corriger et publier pour agents d’IA

Choisir l’emplacement et le format adapté

Emplacement : racine du site ou /.well-known/

La découverte la plus directe se fait souvent depuis la racine du site : elle évite une recherche additionnelle et correspond au comportement de certains agents. La norme RFC5785 recommande l’usage de /.well-known/ pour les métadonnées partagées, ce qui organise mieux plusieurs fichiers de découverte. Avant de décider, consultez la documentation de l’agent destinataire : certains outils cherchent d’abord à la racine, d’autres dans /.well-known/. Si plusieurs intégrateurs sont concernés, choisissez l’emplacement compatible avec le plus grand nombre ou publiez les deux emplacements si vous pouvez les maintenir synchronisés.

Format : texte simple vs JSON / JSON‑LD

Adaptez le format au consommateur. Pour des métadonnées légères et faciles à éditer par des équipes non techniques, un fichier TXT en paires clé:valeur est lisible et robuste. Pour des métadonnées structurées, pour inclure un schéma ou pour faciliter le parsing automatique, publiez du JSON ou du JSON‑LD et envoyez le Content‑Type adéquat (application/json ou application/ld+json). Dans tous les cas, la priorité est la conformité au format attendu : vérifiez la spécification du destinataire avant d’adopter un format.

Conception minimale d’un fichier lisible

Définissez un jeu de clés stable et documenté. Par exemple, des clés simples comme issuer, version, endpoints et contact permettent de tracer la provenance et la portée des données. Pour un fichier TXT, limitez les valeurs aux URL et identifiants sans sauts de ligne complexes. Pour du JSON, ajoutez explicitement un champ version et veillez à la validité syntaxique. Maintenez un README interne qui décrit chaque clé et les règles de mise à jour pour éviter les ambiguïtés entre équipes marketing et technique.

Agrandir

Déployer le fichier sur WordPress (procédure rapide)

Publier un fichier physique à la racine ou dans /.well-known/ exige l’accès au système de fichiers de l’hébergement : téléversement via FTP/SFTP ou via le gestionnaire de fichiers du panneau d’hébergement, ou création dans le répertoire public_html (ou www). Évitez les solutions qui n’écrivent pas le fichier sur le disque et qui se contentent de règles de réécriture : WordPress génère par défaut certains fichiers virtuels (robots.txt, par exemple) si aucun fichier physique n’existe, et un fichier placé physiquement doit remplacer la version virtuelle. Si vous gérez depuis l’interface WordPress, utilisez un plug‑in qui garantit l’écriture réelle sur le disque ; vérifiez cette écriture en listant le répertoire via FTP. Après mise en place, testez immédiatement l’URL publique (statut 200) avant toute communication aux intégrateurs, et documentez l’emplacement exact et le propriétaire de la ressource pour les mises à jour ultérieures.

Vérifier, corriger, versionner et tester en continu

Contrôles techniques essentiels

Commencez par une vérification brute de l’URL publique avec curl ou HTTPie : le fichier doit renvoyer un code 200 et le Content‑Type approprié (text/plain, application/json ou application/ld+json). Vérifiez l’absence de redirections non souhaitées vers la page d’accueil ou vers une page de maintenance. Si l’agent réalise des requêtes cross‑origin, testez la présence et la valeur des en‑têtes CORS (Access‑Control‑Allow‑Origin) nécessaires au flux prévu.

Cas courants et corrections rapides

Erreur 404 : contrôlez le chemin et la présence physique du fichier sur le serveur ; vérifiez les permissions de fichier et le répertoire. Erreur 403 : examinez les permissions, les règles de sécurité (mod_security) et les ACL fournies par l’hébergeur. Content‑Type incorrect : corrigez la configuration serveur, ajoutez une règle .htaccess ou ajustez les paramètres de l’hébergeur pour servir le type MIME attendu. Redirections WordPress : désactivez ou adaptez les règles de rewrite pour créer une exception sur l’URL ciblée, ou placez un fichier physique qui prend priorité sur la logique de réécriture.

Versionner et indiquer la provenance

Incluez un champ version et un champ issuer/contact dans le fichier pour permettre l’identification et le suivi des changements par les agrégateurs. Conservez une copie du fichier dans votre dépôt de site ou dans le gestionnaire de versions de l’agence, et reliez chaque modification à un commit ou à un changelog simple accessible aux équipes concernées.

Tests automatisés et intégration continue

Automatisez les contrôles via un script qui effectue des requêtes et valide statut, Content‑Type, en‑têtes CORS et présence de clés obligatoires. Intégrez ce script à votre pipeline CI/CD ou à une tâche planifiée post‑déploiement pour détecter les régressions après mises à jour WordPress, thèmes ou migrations d’hébergement. Ces tests permettent d’alerter rapidement une équipe technique avant que des intégrateurs externes n’exploitent une donnée erronée.

Validation côté agent destinataire

Si le fournisseur de l’agent propose un validateur public, soumettez l’URL pour obtenir un retour formel sur la conformité. À défaut, partagez l’URL avec le contact technique du destinataire pour des tests en condition réelle : cette étape révèle rapidement les écarts de format, les clés manquantes ou les contraintes CORS non anticipées et facilite une mise en production coordonnée.

Conclusion : checklist d’action et précautions finales

Avant de publier un fichier destiné aux agents d’IA, suivez une checklist simple pour réduire les risques d’erreur et faciliter les intégrations.

• Choisir l’emplacement (racine ou /.well-known/) en se référant à la documentation du destinataire.
• Sélectionner le format adapté : TXT pour léger et lisible, JSON/JSON‑LD pour données structurées.
• Publier effectivement le fichier sur le système de fichiers (FTP/gestionnaire ou plug‑in qui écrit) et vérifier l’accès direct.
• Tester immédiatement avec curl/HTTPie pour statut, Content‑Type et CORS, puis automatiser ces contrôles.
• Versionner le fichier et inclure des champs issuer/contact/version pour tracer l’origine.
• Valider la publication auprès de l’agent destinataire ou de son outil de validation avant diffusion large.

Ces étapes évitent les mauvaises surprises liées aux fichiers virtuels générés par WordPress, limitent les reprises d’informations erronées et donnent aux équipes marketing et aux agences un cadre opérationnel pour publier des métadonnées lisibles par des automates en toute sécurité.