Une doc que crawlers et agents savent vraiment lire.
Une app rendue à l’exécution sous des routes à fragment est invisible pour les crawlers d’IA et ne fait qu’une page pour Google — la faiblesse structurelle de toute la catégorie. ApiGlow y répond deux fois : chaque route s’annonce pendant que l’app tourne, et apiglow bake écrit le miroir statique HTML et Markdown que moteurs et agents récupèrent sans exécuter une ligne de JavaScript.
docs.example.com/op/addPet.html · baké
CAPTURE RÉELLE, AFFICHÉE À 1:1
01
Chaque route s'annonce.
Dès la première installation, sans aucune configuration, l’app gère l’en-tête du document à chaque changement de route : un <title> par route (« addPet — Petstore »), une meta description dérivée du contenu de la route, et un bloc JSON-LD par page — APIReference sur les endpoints, TechArticle sur les guides et les scénarios, WebSite sur l’accueil. Les vues qu’aucun type ne décrit honnêtement n’émettent rien : un type faux est pire que le silence.
02
Une commande écrit la copie du crawler.
Les crawlers d’IA n’exécutent pas de JavaScript, et Google lit toutes les routes #/… comme une seule URL. apiglow bake — un CLI compagnon dans le même paquet npm — lit le config exact que votre page hôte inline et écrit ce dont les crawlers ont besoin : un instantané HTML et un miroir Markdown par opération, guide et scénario, un sitemap.xml, et llms.txt / llms-full.txt en fichiers servis. Déployez l’arbre à côté de la page de l’app ; l’installation du lecteur reste une balise script.
Chaque instantané est du vrai contenu statique : canonical vers lui-même, un lien alternate vers son jumeau Markdown, du JSON-LD, zéro script — et un lien bien visible vers l’app interactive. Pas de redirection, pas d’hydratation, pas de détection de user-agent. Ce n’est ni un prerender ni de la génération de site statique : c’est la couche d’export de l’app écrite sur disque, nourrie par les mêmes générateurs que le « Copy page » de l’app — le miroir ne peut pas dériver du produit.
04
Les agents reçoivent des fichiers récupérables.
Baké, llms.txt suit la convention llmstxt.org et pointe vers les miroirs Markdown servis ; chaque section de llms-full.txt porte une ligne Source: vers sa page ; et chaque scénario publie sa recette Arazzo — le fichier qu’un runner CI exécute tel quel. La génération dans le navigateur de la surface IA continue de fonctionner sans bake ; le bake est ce qui transforme ces téléchargements en URL.
05
Ou rester complètement hors de l'index.
Une documentation interne se retire avec une clé : seo: { index: false } injecte une meta robots noindex avant le premier rendu. La config énonce sa propre limite — c’est une requête adressée aux crawlers de bonne volonté, pas une protection ; une doc qui ne doit pas être lue exige un mur d’authentification. Et le bake refuse de tourner sur un config noindex : publier le miroir d’une page qui demande à ne pas être trouvée est une contradiction qu’il traite en erreur dure.
06
Le miroir dégrade là où Node n'a pas de DOM.
Le bake tourne dans Node (≥ 24) : le HTML brut dans la prose Markdown est échappé plutôt que rendu dans les instantanés, et une page de prose portée par un élément de la page hôte (contentId) ne peut pas être bakée du tout — elle est nommée dans les avertissements et retirée du sitemap plutôt que liée morte. Le sitemap ne porte pas de <lastmod>, et robots.txt reste le vôtre. Relancez le bake quand le schéma ou la prose change — en pratique, depuis le job de CI qui déploie déjà le site.
