Vérifier que son llms.txt est servi en production

Vous avez créé un llms.txt, vous le voyez dans votre repo, et pourtant GPTBot ne le récupère pas. Le problème n'est presque jamais le contenu du fichier. C'est la couche de service : routing, dossier de build, redirections, Content-Type, casse. Ce guide est une checklist de diagnostic pour vérifier ce qui est réellement servi en production — pas ce que vous croyez avoir déployé.

Le piège : "le fichier existe" ≠ "le fichier est servi"

La majorité des guides s'arrêtent à "placez le fichier à la racine". En pratique, les régressions arrivent après, au déploiement. Quelques cas documentés et représentatifs :

• PrimeVue : llms.txt et llms-full.txt ont commencé à renvoyer des réponses 404 après la dernière release.
• Rank Math : une version qui retirait le trailing slash via une redirection, faisant tomber /llms.txt en 404.
• Yoast : après réactivation du plugin, le bouton "Voir le fichier llms.txt" pointe vers un 404 pendant les 5 minutes suivantes.

Dans les trois cas, le fichier "existe" côté CMS ou repo. C'est la chaîne de service qui casse. Votre validation doit donc porter sur la réponse HTTP réelle de l'URL publique, pas sur la présence du fichier source.

Étape 1 — Tester la réponse HTTP brute

Ne testez jamais dans le navigateur uniquement : le rendu masque les en-têtes. Utilisez curl contre l'URL de production.

curl -sSL -o /dev/null -w "code=%{http_code} type=%{content_type} url=%{url_effective}\n" \
  https://votredomaine.com/llms.txt

Ce que vous voulez voir : le fichier accessible à https://votredomaine.com/llms.txt, pas dans un sous-répertoire, pas derrière une authentification, avec un Content-Type text/plain (ou text/markdown) et un code HTTP 200.

Points de contrôle dans la sortie :

• code=200 — un 301/302 vers une autre URL est un signal d'alerte (voir étape 3).
• type=text/plain ou text/markdown — si vous voyez text/html, votre serveur sert une page (souvent un 404 déguisé en 200, ou la SPA de fallback).
• url= identique à l'URL demandée — sinon, une redirection a eu lieu.

Étape 2 — Vérifier le dossier de build (SSG / SPA)

Sur les frameworks statiques, le fichier doit être dans le bon dossier source pour être copié à la racine du build. C'est l'erreur la plus fréquente côté dev.

• Astro : placez le fichier dans public/llms.txt. Il est servi à la racine.
• Next.js : public/llms.txt, ou une route qui génère le fichier dynamiquement.
• Netlify / Cloudflare Pages : placer dans le répertoire public/ ou à la racine du répertoire de build.

Le test qui compte : après un build local, vérifiez que le fichier est présent dans le dossier de sortie (dist/, out/, build/), pas seulement dans les sources.

npm run build
test -f dist/llms.txt && echo "OK servi" || echo "ABSENT du build"

Si le fichier est dans vos sources mais absent du dossier de build, aucun crawler IA ne le verra jamais en prod. C'est la régression silencieuse type : le repo est correct, le déploiement non.

Étape 3 — Traquer redirections et trailing slash

Beaucoup de configs normalisent les URLs (suppression du slash final, redirection HTTP→HTTPS, www→apex). Une règle trop large peut transformer /llms.txt en redirection cassée, exactement comme dans l'incident Rank Math. Testez les deux variantes :

curl -sI https://votredomaine.com/llms.txt   | grep -i "^HTTP\|^location"
curl -sI https://votredomaine.com/llms.txt/  | grep -i "^HTTP\|^location"

Une 301 vers /llms.txt/ (ou l'inverse) qui aboutit à un 404 est un faux positif classique : le fichier "marche" dans un seul des deux cas. Les crawlers IA testent l'URL canonique sans slash. Servez un 200 direct sur /llms.txt.

Étape 4 — Vérifier la casse et le nom exact

Sur Linux, le nom de fichier est sensible à la casse. Enregistrez le fichier sous le nom exact llms.txt — minuscules, sans espace, avec l'extension .txt. Le nom est sensible à la casse sur les serveurs Linux. Un LLMs.txt committé sur macOS (insensible à la casse) passera en local et tombera en 404 en prod Linux. Vérifiez aussi la faute classique llms.txt vs llm.txt : une erreur dans le nom casse la fonctionnalité.

Étape 5 — Confirmer l'accès côté serveur, pas côté front

Pour les fichiers générés à la volée (plugins CMS, routes API), l'échec se produit au niveau du serveur web. Dans un cas WordPress documenté, les fichiers markdown se généraient correctement mais le llms.txt, lui, ne se générait pas. La piste habituelle : vérifier la config Nginx et s'assurer qu'aucune directive ne bloque le llms.txt ou ne sert pas les fichiers .txt manquants.

Pour les sites fortement dépendants de JavaScript, le risque est double : si votre site nécessite fortement JavaScript pour générer le contenu, les robots des chatbots IA pourraient ne pas y accéder car ils n'utilisent pas JavaScript. Un llms.txt statique servi en HTTP brut contourne ce problème — à condition qu'il soit réellement servi en text/plain, et pas intercepté par le router de votre SPA qui renvoie l'index.html.

Étape 6 — Auditer et surveiller dans la durée

Côté audit ponctuel, Lighthouse intègre désormais une vérification : Lighthouse signale les pages si une erreur serveur survient lors de la récupération du llms.txt ; si le fichier renvoie un 404, l'audit est marqué Not Applicable, car le fichier reste optionnel pour l'instant. Utile en one-shot, mais un audit manuel ne détecte pas une régression survenue le mardi après un déploiement du lundi soir.

Le vrai risque, c'est la disparition silencieuse : le fichier était là, un refactor de routing ou un changement de plan d'hébergement l'a fait sauter, et personne ne le remarque pendant des semaines. Les crawlers IA n'aident pas à le détecter vite, car les bots IA ne visitent pas votre site quotidiennement : l'absence de visite dans les jours suivant un déploiement ne signifie pas que votre fichier est mal configuré. Vous ne voyez donc pas immédiatement l'impact dans les logs.

C'est précisément ce que surveille Seogard. La règle llms_txt_removed compare chaque déploiement à l'état précédent et alerte quand un llms.txt qui renvoyait 200 se met à renvoyer 404, une redirection, ou un Content-Type HTML. Branchée en CI/CD, elle peut bloquer un déploiement régressif avant qu'il n'atteigne la prod, sur le même principe que la détection d'un noindex en production avant Google. Vous n'attendez plus la prochaine visite de GPTBot pour découvrir le problème. Le monitoring continu est détaillé sur la page d'accueil Seogard.

Checklist de validation rapide

À passer après chaque déploiement, idéalement automatisé :

1. GET /llms.txt → 200 (pas 301, pas 404).
2. Content-Type → text/plain ou text/markdown (jamais text/html).
3. URL effective identique à l'URL demandée (aucune redirection silencieuse).
4. Fichier présent dans le dossier de build, pas seulement dans les sources.
5. Nom exact llms.txt, minuscules, racine du domaine.
6. Comparaison avec le déploiement précédent : alerte si le statut change.

Un llms.txt n'a de valeur que s'il est servi. Tant que vous ne validez pas la réponse HTTP réelle en production à chaque déploiement, vous opérez en aveugle.