https://docs.paymo.ru

les agents (comme les humains qui découvrent un site) ont besoin d'un index unique et prévisible indiquant où se trouve la documentation. /llms.txt est la convention proposée par Anthropic et la communauté llmstxt.org : un seul fichier Markdown à la racine du domaine, contenant la carte de la documentation.

Notation. 2 = un H1 + ≥1 H2 + ≥3 liens + tous aboutissent · 1 = tout fichier comportant un H1 (rétrogradé depuis le niveau 2 si les liens n'aboutissent pas) · 0 = absent ou coquille HTML.

Correction. Publiez /llms.txt à la racine du domaine avec un titre `# H1`, des en-têtes de section `## H2`, et au moins trois liens Markdown à puces pointant vers des pages de documentation concrètes. Voir https://llmstxt.org pour la spec.

Preuve. https://docs.paymo.ru/llms.txt

/rubric#a1 · article

/llms-full.txt est l'export en texte intégral de votre documentation en un seul endroit — les agents fondés sur de grands modèles de langage le préfèrent à l'exploration de 200 pages HTML. Les variantes par section (/llms-api.txt, etc.) conviennent aussi.

Notation. 3 = /llms-full.txt à la racine du domaine, >1 Ko · 2 = agrégat par section trouvé via llms.txt · 0 = ni l'un ni l'autre, ou coquille SPA à /llms-full.txt.

Correction. Générez /llms-full.txt au moment du build (des plugins mkdocs/docusaurus existent) et servez-le en text/plain. Gardez-le sous 100 Mo pour que les agents puissent le récupérer sans streaming.

Preuve. https://docs.paymo.ru/llms-full.txt

/rubric#a2 · article

tout crawler d'IA (GPTBot, ClaudeBot, Google-Extended, PerplexityBot, CCBot) lit /robots.txt avant d'explorer. Une directive Allow/Disallow explicite par UA, plus une directive `Sitemap:` absolue, lèvent toute ambiguïté sur l'indexation et sur ce qu'il faut indexer.

Notation. 3 = directive UA explicite pour un bot d'IA ET ligne Sitemap: absolue · 2 = directive bot d'IA seule · 1 = Sitemap absolu seul · 0 = ni l'un ni l'autre, ou 404.

Correction. Ajoutez `User-agent: GPTBot\nAllow: /` (ou Disallow selon votre politique) pour chaque grand bot LLM, plus une ligne `Sitemap: https://example.com/sitemap.xml`. La directive `Content-Signal:` de Cloudflare compte également.

Preuve. https://docs.paymo.ru/robots.txt

/rubric#a3 · article

les sitemaps indiquent aux crawlers quoi indexer et à quelle fréquence cela change. Un `<urlset>` bien formé avec des URL `<loc>` absolues réparties sur de nombreuses pages distinctes signale une vraie couverture ; un stub avec une seule URL (ou un sitemap composé à 70 % et plus de bruit /tag/ /category/) n'apporte aucun signal.

Notation. 3 = bien formé + ≥3 chemins distincts + <30 % de bruit de taxonomie · 2 = maigre (<3 chemins) ou 30-70 % de bruit · 1 = bien formé seulement · 0 = 404 ou erreur d'analyse.

Correction. Générez /sitemap.xml au moment du build, incluez chaque page de documentation avec un `<loc>` en URL absolue, et excluez les variantes /tag/, /category/, /author/, /page=. Référencez-le depuis robots.txt avec une ligne `Sitemap:` absolue.

Preuve. https://docs.paymo.ru/sitemap.xml

/rubric#a4 · article

les balises de découverte permettent aux agents de trouver la version markdown d'une page sans requête supplémentaire, et OpenGraph transforme les liens de documentation partagés en aperçus enrichis sur Slack/Discord/Twitter. Les deux témoignent d'une prise en compte des consommateurs machine.

Notation. 2 = `<link rel=alternate type=text/markdown>` + ≥3 propriétés `og:` distinctes · 1 = alternative markdown seule OU OpenGraph seul · 0 = ni l'un ni l'autre.

Correction. Ajoutez `<link rel="alternate" type="text/markdown" href="/page.md">` à côté de votre lien canonical, et assurez-vous que `og:title`, `og:description`, `og:image` (au minimum 3 propriétés) sont définis sur la page d'accueil.

Preuve. https://docs.paymo.ru — homepage not parsed

/rubric#a5 · article

parcourir 200 pages HTML pour lire votre documentation convient aux humains ; pour les agents, c'est un coût de tokenisation d'un ordre de grandeur supérieur. Un jumeau markdown par page permet aux agents de n'extraire que le texte.

Notation. 7 = 3/3 des pages échantillonnées ont un jumeau .md fonctionnel · 4 = 2/3 · 2 = 1/3 · 0 = 0/3.

Correction. Servez `{page}.md` (ou `{page}/index.md`) à côté de chaque page HTML, OU prenez en charge la négociation de contenu `Accept: text/markdown` renvoyant `Content-Type: text/markdown`. mkdocs-material et docusaurus disposent tous deux de plugins.

Preuve. https://docs.paymo.ru — no sitemap samples available

/rubric#b1 · article

le JSON-LD est la façon compatible schema.org de déclarer « cette page est un Article » / « ce produit est une SoftwareApplication ». Moteurs de recherche, agents et extracteurs de données structurées s'appuient tous dessus.

Notation. 4 = JSON-LD analysable avec `@type` à la fois sur l'accueil ET sur une page de documentation échantillon · 3 = l'un des deux · 0 = aucun.

Correction. Intégrez `<script type="application/ld+json">{"@context":"https://schema.org","@type":"TechArticle",...}</script>` sur chaque page de documentation. Le type `WebApplication` convient bien à la page d'accueil.

Preuve. https://docs.paymo.ru — no parsed pages available

/rubric#b2 · article

les liens canonical tranchent de manière déterministe la question « est-ce la version http ou https, avec ou sans slash final, avec ou sans paramètre de requête ? ». Sans eux, les agents peuvent indexer le même contenu sous plusieurs URL.

Notation. 3 = canonical absolu à la fois sur l'accueil ET sur une page échantillon · 2 = accueil seulement · 1 = présent mais relatif · 0 = absent.

Correction. Ajoutez `<link rel="canonical" href="https://example.com/page">` dans le `<head>` de chaque page. L'URL doit inclure le schéma et l'hôte (les canonical relatifs sont du HTML valide mais perdent leur intérêt pour les agents inter-hôtes).

Preuve. https://docs.paymo.ru — no parsed pages available

/rubric#b3 · article

les agents (comme les moteurs de recherche) accordent moins de confiance à une documentation qui ne déclare pas sa dernière mise à jour. Une page de documentation de 2019 sans signal de fraîcheur est indiscernable d'une page mise à jour hier.

Notation. 2 = `dateModified` JSON-LD OU en-tête HTTP `Last-Modified` présent · 0 = ni l'un ni l'autre.

Correction. Incluez soit `"dateModified": "2026-05-28"` dans votre bloc JSON-LD, soit faites émettre un en-tête HTTP `Last-Modified` par votre CDN/serveur. Le templating au moment du build le fait gratuitement dans la plupart des générateurs de sites statiques.

Preuve. https://docs.paymo.ru — no page metadata available

/rubric#b4 · article

une documentation taguée aide les agents à filtrer (« montre-moi les pages liées à l'authentification ») sans analyser tout le texte. `<meta name="keywords">`, le `keywords` JSON-LD, ou des URL de type `/tags/` comptent tous.

Notation. 2 = au moins un signal de taxonomie présent (meta keywords, keywords JSON-LD, ou motifs de liens /tags|/categories|/topics/) · 0 = aucun.

Correction. Ajoutez `<meta name="keywords" content="api,auth,oauth">` à chaque page, OU incluez un tableau `keywords` dans votre JSON-LD, OU organisez le contenu sous des préfixes d'URL `/topics/` ou `/tags/`.

Preuve. https://docs.paymo.ru — no parsed pages available

/rubric#b5 · article

les conteneurs sémantiques HTML5 permettent aux agents (et aux lecteurs d'écran) d'écarter navigation/pied de page/barres latérales pour ne lire que le texte de la documentation. Une page dont le corps n'est que `<div>` impose des conjectures.

Notation. 2 = texte de `<main>` >200 caractères ET texte d'`<article>` >100 caractères · 1 = `<main>` seul OU `<article>` seul · 0 = ni l'un ni l'autre.

Correction. Englobez le texte principal de votre page dans `<main>` (ou `<article>` pour les pages de documentation individuelles). Évitez d'utiliser ces balises pour les barres latérales ou la navigation — elles sont destinées au contenu réel.

Preuve. https://docs.paymo.ru — no parsed pages available

/rubric#b6 · article

une spec OpenAPI est LE contrat lisible par machine de référence pour une API REST. Les agents qui la trouvent peuvent générer des clients, des cas de test et une documentation exacte sans lire aucun HTML.

Notation. 8 = trouvée à un chemin de sondage standard (/openapi.json, /swagger.yaml, /v1/openapi.json, etc.) · 5 = trouvée uniquement via la découverte de liens HTML · 0 = rien trouvé.

Correction. Publiez votre spec à `/openapi.json` ou `/openapi.yaml` à la racine du domaine (ou sous le chemin de votre documentation — la Phase 53 sonde les deux). Pour les projets OpenAPI-first, votre outil de build la produit déjà — il suffit de l'exposer.

Preuve. https://docs.paymo.ru — homepage pre-fetch failed; spec discovery skipped

/rubric#c1a · article

trouver une spec (C1a) n'est que la moitié du chemin ; la spec doit aussi être un 3.x valide ET décrire les schémas de réponse pour que les agents sachent ce qu'ils vont récupérer. Une spec qui liste des paths sans forme de réponse n'est qu'un demi-contrat.

Notation. 7 = OpenAPI 3.x + info valide + paths + ≥30 % des opérations ont des schémas de contenu de réponse · 6 = +paths mais peu de schémas · 3 = repli Swagger 2.0 · 0 = erreur d'analyse.

Correction. Faites passer votre spec à OpenAPI 3.0 ou 3.1 si vous êtes encore en Swagger 2.0. Ajoutez `responses: { '200': { content: { 'application/json': { schema: ... } } } }` à chaque opération — ce sont les schémas qui rendent une spec utile aux clients.

Preuve. https://docs.paymo.ru — C1a did not find a spec body

/rubric#c1b · article

une spec OpenAPI permet aux agents de générer un client ; une collection Postman soignée ou un SDK prêt à l'emploi permet aux HUMAINS d'essayer l'API en 30 secondes. Les deux témoignent d'un investissement dans l'expérience développeur.

Notation. 4 = lien de collection Postman ET ≥1 lien vers un registre de SDK · 3 = Postman OU ≥2 liens de SDK · 2 = 1 lien de SDK · 0 = rien.

Correction. Publiez un bouton « Run in Postman » pointant vers god.gw.postman.com/run-collection, et liez au moins un SDK officiel depuis npm/PyPI/RubyGems/etc. directement depuis la page d'accueil de votre documentation.

Preuve. https://docs.paymo.ru — no parsed pages available

/rubric#c2 · article

une page de documentation qui se contente de dire « appelez /users » est inutile sans la méthode, les types de paramètres, les champs requis et un exemple de requête/réponse. Les agents (comme les humains) ont besoin de ces cinq éléments pour faire un appel qui fonctionne.

Notation. 5 = la majorité des pages échantillonnées classées `complete` par le modèle de ML · 3 = majorité `partial` (ou 2 complete + 1 absent) · 1 = majorité `absent` · 0 = aucune page candidate trouvée.

Correction. Sur chaque page d'endpoint, incluez : méthode HTTP + chemin, un tableau de paramètres avec types et indicateurs « requis », un exemple curl, et un exemple de réponse JSON avec code de statut. Les tableaux de paramètres en style Markdown et les blocs JSON `<pre>` se classent proprement.

Preuve. https://docs.paymo.ru — no pages fetched; ML/heuristic skipped

/rubric#c3 · article

les exemples curl sont testables universellement ; les exemples SDK montrent un usage idiomatique. Ensemble, ils répondent au besoin « puis-je essayer ça rapidement ? » et au besoin « comment intégrer ? ».

Notation. 4 = curl ET un bloc de code SDK dans un langage sur ≥1 page · 2 = curl seul · 1 = SDK seul · 0 = ni l'un ni l'autre.

Correction. Ajoutez un bloc de code à onglets par endpoint, avec au moins curl + le langage de SDK le plus utilisé (Python ou JavaScript). Utilisez `<code class="language-python">` ou `language-bash` pour que les outils de coloration syntaxique et notre classifieur le repèrent tous deux.

Preuve. https://docs.paymo.ru — no sample pages available

/rubric#d1 · article

`/users/{id}` avec `id = 1` et `email = [email protected]` oblige le lecteur à imaginer à quoi ressemblent de vraies données. Des placeholders réalistes (`[email protected]`, `org_2N5x...`) réduisent la friction et évitent les accidents de copier-coller depuis la documentation.

Notation. 4 = le modèle de ML estime que <20 % des blocs de code sont saturés de placeholders · 3 = 20-40 % · 2 = 40-60 % · 1 = 60-80 % · 0 = >80 % ou aucun bloc de code.

Correction. Remplacez `foo`/`bar`/`example.com`/`your_api_key`/`<string>` par des valeurs d'allure réaliste (le `pk_test_51N5...` de Stripe, le `+14155552671` de Twilio). N'utilisez pas de vraies données client — mais imitez-en la forme.

Preuve. https://docs.paymo.ru — no sample pages available; ML/regex path skipped

/rubric#d2 · article

quand une intégration casse à 3 h du matin, le développeur a besoin de savoir ce que `403 - resource_not_owned` signifie réellement sans ouvrir un ticket. Une page de référence des erreurs dédiée fait la différence entre une correction en 5 minutes et un débogage d'une demi-heure.

Notation. 3 = page d'erreurs dédiée (≥3 codes avec explications) · 1 = codes d'erreur documentés au fil des pages · 0 = aucun.

Correction. Publiez `/errors` (ou `/reference/errors`) listant chaque statut HTTP que vous renvoyez + les codes d'erreur applicatifs + une cause en une phrase pour chacun. Les tableaux fonctionnent bien ; les listes de définitions `<dl>` aussi.

Preuve. https://docs.paymo.ru — no homepage / sitemap available

/rubric#d3 · article

l'authentification est un prérequis ; les limites de débit indiquent au développeur si son intégration survivra à la charge de production. Les deux ont leur place sur une page de documentation de premier niveau, découvrable depuis l'accueil.

Notation. 3 = authentification et limites de débit documentées · 2 = authentification seule · 1 = limites de débit seules · 0 = ni l'une ni l'autre.

Correction. Ajoutez des pages `/authentication` (flux bearer / clé API / OAuth) et `/rate-limits` (req/min, en-têtes comme `X-RateLimit-Remaining`, sémantique de réessai 429). Chacune doit comporter au moins 200 caractères de contexte — pas seulement un extrait de code.

Preuve. https://docs.paymo.ru — no pages available

/rubric#d4 · article

est-ce un « workspace », une « team » ou une « organisation » ? Choisir un terme et s'y tenir dans toute la documentation évite une catégorie de tickets de support « que veut dire X ici ? ». Un glossaire dédié est l'idéal ; un usage cohérent est acceptable.

Notation. 3 = un /glossary dédié avec ≥3 paires terme/définition structurées · 2 = pas de glossaire mais terminologie cohérente entre les pages (≥80 % de variante dominante) · 1 = lien de glossaire présent mais contenu maigre · 0 = ni l'un ni l'autre.

Correction. Publiez `/glossary` sous forme de `<dl>` avec des paires `<dt>terme</dt><dd>définition</dd>` (ou un tableau à 2 colonnes avec des définitions de ≥50 caractères). Utilisez la même casse/orthographe pour chaque terme sur toutes les pages.

Preuve. https://docs.paymo.ru — homepage unreachable; glossary probes skipped

/rubric#d5 · article

un développeur qui colle votre exemple de code de 2022 dans un projet de 2026 ne devrait pas découvrir à l'exécution que l'endpoint est déprécié. Des marqueurs `deprecated` / `beta` / `sunset` explicites dans la documentation épargnent bien des migrations douloureuses.

Notation. 2 = `deprecated` dans la spec OpenAPI OU dans ≥2 pages échantillons près des titres d'endpoint · 1 = mots-clés beta/experimental trouvés mais aucune dépréciation · 0 = aucun.

Correction. Marquez chaque endpoint déprécié avec `deprecated: true` dans OpenAPI ET un badge ou un encart visible dans la documentation HTML (le `<Warning>` de Mintlify, la syntaxe d'encart de Docusaurus, etc.). Idem pour les endpoints bêta — visibles dans le texte, pas seulement dans la spec.

Preuve. https://docs.paymo.ru — no pages available

/rubric#d6 · article

c'est le critère BLOQUANT. Si votre documentation ne s'affiche qu'après exécution de JavaScript (coquille de single-page-app), les agents qui récupèrent le HTML brut ne voient rien. Les web crawlers, les scrapers, curl et la plupart des récupérateurs d'IA n'exécutent pas le JS.

Notation. 6 = texte du corps >500 caractères sur au moins l'une des pages parmi l'accueil ou 2 sous-pages, dans les différents modes UA · 3 = l'accueil passe mais les sous-pages sont en SPA · 0 = coquille SPA partout, ou piège VK (3 URL et plus renvoient un corps identique).

Correction. Servez du HTML pré-rendu à des URL statiques. Si vous utilisez Next.js/Nuxt/SvelteKit, activez le SSG ou le SSR pour la section documentation. Les coquilles de single-page-app (SPA React, SPA Vue sans SSR) échouent à ce critère et font chuter en cascade beaucoup d'autres critères à zéro.

Preuve. https://docs.paymo.ru — all UA probes failed to reach target

/rubric#e1 · article

quand vous réorganisez la documentation, les anciens liens ne devraient pas renvoyer 404 — ils devraient faire une 301 vers la nouvelle URL. Des URL stables permettent aux liens internes provenant de blogs, de Stack Overflow et de favoris de survivre à votre refonte.

Notation. 2 = redirection 301/308 stable sur ≥1 des 2 variantes d'URL échantillonnées · 1 = motif canonical-alias (200 avec `<link rel=canonical>`) · 0 = 302 (non permanente), 404, ou aucune redirection.

Correction. Quand vous changez l'URL d'une page de documentation, ajoutez une redirection 301 de l'ancien chemin vers le nouveau. Les générateurs de sites statiques gèrent cela via `_redirects` (Netlify) ou les `redirects:` de `vercel.json` (Vercel).

Preuve. https://docs.paymo.ru — no sitemap samples available

/rubric#e2 · article

`/v1/users` contre `/v2/users` est la manière économique de versionner une API ET de la rendre évidente pour les agents. Une métadonnée de version uniquement présente dans un en-tête (et ni dans le chemin ni dans un titre de documentation) est invisible pour les crawlers.

Notation. 2 = version dans la structure d'URL propre à la doc (URL du sitemap ou de la spec OpenAPI : `/v1/`, `/2024-01-15/`) · 1 = version dans l'URL d'un endpoint documenté (exemples curl/code), dans `info.version` OpenAPI, ou dans un titre `<h1>`/`<h2>`/pied de page · 0 = aucune.

Correction. Préfixez vos chemins d'API par `/v1/`, `/v2/` et affichez-les dans vos exemples curl/code ; ou définissez un `info.version` non vide dans votre spec OpenAPI. Les API versionnées par date (`/2024-01-15/users`) comptent également.

Preuve. https://docs.paymo.ru — no input source (homepage, sitemap, or OpenAPI URL)

/rubric#e3 · article

les liens internes pourris sont le mode de défaillance le plus courant des documentations après des années de remaniements. Un contrôle ponctuel de 5 liens attrape les pires cas (4xx/5xx sur des liens présents en page d'accueil) sans tenter d'explorer chaque lien.

Notation. 2 = 5/5 des liens échantillonnés du même hôte renvoient 200 · 1 = 4/5 · 0 = ≤3/5, OU moins de 5 liens distincts du même hôte trouvés sur l'accueil.

Correction. Lancez un vérificateur de liens dans votre CI (lychee, htmltest, linkinator). Pour les liens les plus fréquentés de l'accueil, corrigez les 404 avant de livrer. Cinq liens fonctionnels depuis la page d'accueil est le strict minimum.

Preuve. https://docs.paymo.ru — homepage not parsed

/rubric#e4 · article

sans CGU ni politique d'usage par l'IA explicites, chaque scraper de LLM doit deviner votre position. Ajouter une page `/terms` ou `/license` substantielle — surtout une contenant des mots-clés IA/ML — rend la politique lisible par machine.

Notation. 2 = page de CGU trouvée ET contenant des mots-clés de politique IA/ML dans le contenu principal · 1 = CGU trouvées (substantielles mais sans mots-clés IA, ou lien présent mais page 404/maigre) · 0 = aucun lien de CGU.

Correction. Publiez `/terms` (ou `/legal`, `/license`) avec au moins 1000 caractères de texte de politique. Incluez un libellé explicite sur le scraping par l'IA, l'entraînement de modèles et l'accès automatisé — même si vous autorisez tout, le dire est déjà le signal.

Preuve. https://docs.paymo.ru

/rubric#e5 · article

un agent trouve votre site par plusieurs surfaces ; F1 récompense le fait d'en exposer plus d'une — un llms.txt joignable, un flux llms-full.txt en contenu intégral, et un endpoint MCP/agent annoncé. Il complète A1/A2 (qui jugent la qualité de chaque surface) en comptant combien un agent peut en découvrir.

Notation. 2 = ≥2 parmi {llms.txt joignable, llms-full.txt existant, endpoint MCP/agent annoncé} · 1 = l'un d'eux · 0 = aucun · error si le site n'a pas pu être récupéré.

Correction. Publiez `/llms.txt` et `/llms-full.txt` à la racine du domaine, et référencez votre serveur MCP ou un endpoint de découverte `.well-known/` à l'intérieur de `/llms.txt` pour que les agents puissent le trouver.

Preuve. https://docs.paymo.ru/llms.txt

/rubric#f1 · article

WebMCP permet à une page d'exposer des outils appelables aux agents en navigateur via un balisage déclaratif `<form toolname tooldescription>`. F2 récompense une surface WebMCP présente et propre au regard du schéma, pour qu'un agent puisse invoquer les outils sans deviner.

Notation. 2 = WebMCP détecté, 0 erreur de schéma + 0 avertissement · 1 = détecté avec des problèmes de schéma (erreurs ou avertissements) · 0 = non détecté · error si la page d'accueil n'a pas pu être analysée.

Correction. Ajoutez des formulaires d'outils déclaratifs WebMCP — chacun avec `toolname` + `tooldescription`, et `name`+`toolparamdescription` sur chaque champ. Corrigez d'abord les erreurs toolname-manquant / paramètre-requis-sans-name ; ce sont les échecs bloquants.

Preuve. homepage unreachable or unscannable

/rubric#f2 · article

un serveur MCP permet aux agents d'appeler votre API comme des outils encadrés. F3 récompense l'annonce d'un endpoint MCP découvrable et protégé par OAuth via les métadonnées standard `.well-known`, pour qu'un agent puisse s'authentifier et se connecter sans configuration sur mesure.

Notation. 3 = oauth-mcp complet (protected-resource RFC 9728 + métadonnées de serveur d'autorisation RFC 8414 + PKCE S256) · 2 = partiel · 1 = endpoint seul · 0 = aucun · error si le site était injoignable.

Correction. Servez `/.well-known/oauth-protected-resource` pointant vers votre endpoint MCP, ainsi qu'un document de métadonnées de serveur d'autorisation RFC 8414 sur le même hôte, annonçant le PKCE `S256`.

Preuve. site unreachable — MCP probe inconclusive

/rubric#f3 · article

un agent d'IA pilote une page via son arbre d'accessibilité — il faut que chaque bouton, lien, champ et image porte un nom qu'il puisse cibler. Des noms accessibles manquants, un ARIA invalide et des tabindex positifs cassent tout cela, laissant des contrôles qu'un agent voit mais ne peut ni nommer ni actionner de façon fiable.

Notation. 3 = 0 violation (et ≥1 élément à vérifier) · 2 = 1–2 · 1 = 3–5 · 0 = ≥6 · not_applicable si la page n'a rien de nommable · error si la page d'accueil n'a pas pu être analysée. Heuristique statique (sans axe-core/headless) : uniquement les règles de nom + validité ARIA.

Correction. Donnez à chaque `<button>`/`<a>`/icône un nom accessible (texte, `aria-label`, ou un enfant `<img alt>` libellé) ; associez les `<label>` aux champs/listes ; ajoutez `alt` aux images et `<title>` aux SVG en ligne ; supprimez les tabindex positifs ; corrigez les attributs et rôles `aria-*` mal orthographiés.

Preuve. homepage unreachable or unscannable

/rubric#f4 · article