Les robots n’exécutent pas JavaScript : une commande leur écrit une copie.
Une application rendue à l’exécution sous des routes à dièse, c’est une seule URL pour Google et l’invisibilité pour les robots d’IA — la faiblesse structurelle de toute la catégorie. ApiGlow y répond deux fois : chaque route s’annonce pendant que l’application tourne, et une commande écrit le miroir statique, depuis votre machine, sans aucun serveur.
Une commande côté auteur, dessinée — ce qu’elle écrit, et un instantané sans rien à exécuter.
Chaque route s’annonce.
Dès la première installation, sans configuration, l’application gère l’en-tête du document à chaque changement de route : un<title> par route (« addPet — Petstore »), une méta description tiré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 la vue d’accueil. Les vues qu’aucun type ne décrit honnêtement n’en émettent aucun : un type faux vaut moins que le silence.Une commande écrit la copie des robots.
apiglow bake est un utilitaire livré dans le même paquet npm. Il lit la configuration exacte que votre page hôte inline et écrit ce dont les robots 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’arborescence à côté de la page — l’installation du lecteur reste une balise script.apiglow bake --config apidoc.config.json \
--site-url https://docs.example.com/ --out public/
Des pages honnêtes, pas du cloaking.
Chaque instantané est du vrai contenu statique : canonique vers lui-même, un lien alternatif vers son jumeau Markdown, du JSON-LD, zéro script — et un lien bien visible qui ramène dans l’application interactive. Pas de redirection, pas d’hydratation, pas de reniflage d’agent utilisateur.
Ce n’est ni du prerender ni de la génération de site statique. C’est la couche d’export de l’application écrite sur disque, alimentée par les mêmes générateurs que le « Copier la page » interne : le miroir ne peut donc pas dériver du produit.
La différence, c’est où ça tourne.
D’autres ont une réponse ici, et elle coûte un processus. Scalar pré-rend avec un paquet qui exige un serveur JS/TS en fonctionnement. Redoc CE produit un unique fichier HTML autonome — pas de miroir par route, pas de sitemap, pas de llms.txt. Swagger UI, Stoplight Elements et RapiDoc ne documentent rien.
Le miroir d’ApiGlow sort d’un utilitaire côté auteur, dans le job qui déploie déjà votre doc, et il n’y a aucun serveur dans le résultat. C’est là qu’est l’axe, pas dans l’existence de la fonction. (Concurrents revérifiés sur leur documentation publique, août 2026.)
Ou rester hors de l’index.
Une documentation interne se retire avec une clé —seo.index: false injecte une méta robots noindex avant le premier rendu. La configuration énonce sa propre limite : c’est une demande adressée aux robots bien élevés, pas une protection. Une documentation qui ne doit pas être lue a besoin d’un mur d’authentification.{ "seo": { "index": false } }
Le miroir se dégrade là où Node n’a pas de DOM.
Le bake tourne dans Node (≥ 24) : le HTML brut inséré dans la prose Markdown est donc échappé plutôt que rendu dans les instantanés, et une page de doc portée par un élément de la page hôte (contentId) ne peut pas être générée du tout — elle est nommée dans les avertissements et retirée du sitemap plutôt que liée dans le vide.
Le sitemap ne porte pas de <lastmod>, et robots.txt reste le vôtre. Relancez le bake quand le schéma ou la prose changent — en pratique, depuis le job CI qui déploie déjà le site.