GitBook vs Docusaurus

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to GitBook
   GitBook✓fullprobed8/10

   GitBook publishes an official llms.txt (confirmed live via probe) plus llms-full.txt, a dedicated 'LLM-ready docs' guide, and even an 'agent-score' tool to check how well AI agents can parse docs, alongside MCP servers for published docs enabling agent access. This directly satisfies pointing an agent at llms.txt/agent-oriented docs for any GitBook-hosted site. Missing for 10: independent third-party validation that agents actually consume llms.txt effectively in practice, and docs.md endpoint returned 404 suggesting inconsistent markdown-mirroring coverage.

   • [probe] “PROBE llms.txt: HTTP 200 at https://gitbook.com/llms.txt # GitBook > GitBook is a collaborative platform for creating, publishing and manag…”
   • [claimed-docs] “LLM-ready docs”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [claimed-docs] “See how easily AI agents can reach, parse, and use your documentation.”
   • [claimed-docs] “MCP servers for published docs”
   • [probe] “PROBE docs-md: HTTP 404 at https://gitbook.com/docs.md”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Probes show Docusaurus's own site has no llms.txt (404) and no agent-oriented docs.md endpoint (404), and no docs evidence describes shipping llms.txt support for generated sites either.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Docusaurus
   GitBook~partialcommunity5/10

   GitBook offers a REST API (gitbook-docs-36), a CLI that can list orgs/inspect content/build integrations from the shell (gitbook-docs-28, gitbook-docs-34), and Git Sync for docs-as-code workflows (gitbook-docs-4, gitbook-docs-27) — all of which support scripted/automated use outside the UI. However, there is no explicit documentation of headless/CI-specific usage (e.g., CI pipeline examples, non-interactive auth flows, exit codes) and the CLI's OSS/self-hosted precursor was explicitly deprecated by the vendor per community evidence (gitbook-comm-17), raising doubt about current automation tooling maturity. Missing for 10: explicit CI/headless run documentation, examples of scripted pipelines, and confirmation the current CLI is actively maintained for automation use cases.

   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   proof ↗⚑ flag

   Docusaurus~partialprobed6/10

   Docusaurus ships a documented CLI (`npm run build`, `docusaurus serve`) that produces static files non-interactively, which is the basis for running it in CI/CD pipelines (e.g., building docs on every push and deploying to Vercel/Netlify/GitHub Pages), and this is a standard, well-documented workflow for static-site generators. However, there's no first-party CI-specific guide (e.g., GitHub Actions workflow) in the evidence, and community reports describe build performance problems severe enough to time out GitHub Actions runners on larger sites, which undercuts reliability for automation at scale. Missing for 10: explicit CI/automation documentation or example workflow, and independent confirmation of successful large-scale CI builds (contradicted in part by comm-10's report of CI timeouts).

   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”
   • [community] “I haven't used Starlight, but Docusaurus is very slow. The last time I used it, its performance on a large documentation site was terrible, …”
   • [community] “I tried migrating our markdown docs-as-code to use Docusaurus, we have somewhere around several hundred pages, and the build times seemed ve…”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round drawn
   GitBook✓fullclaimed7/10

   GitBook publishes an official CLI (gitbook-docs-28) documented to let users list organizations, inspect spaces/pages, ask questions against docs, and build/publish integrations 'without leaving the shell' (gitbook-docs-34), directly matching an AI-native CLI story alongside its MCP server for agent tooling. missing for 10: independent/hands-on verification of the CLI's current functionality and any AI-native workflow examples beyond first-party docs (the only community CLI comment found refers to the legacy, unrelated open-source book-building CLI, not this one).

   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”

   proof ↗⚑ flag

   Docusaurus✓fullprobed7/10

   Docusaurus ships a well-documented official CLI (create-docusaurus scaffolding, docusaurus start/build/serve, versioning and swizzle commands) confirmed by docs and a probe hit on /docs/cli, all scriptable via npm and usable non-interactively by automation/agents. Missing for 10: no explicit documentation or examples of AI-agent-specific usage/integration, and no independent hands-on confirmation of CLI reliability in automated/agentic pipelines.

   • [claimed-docs] “npx create-docusaurus@latest my-website classic”
   • [claimed-docs] “Builds and serves a preview of your site locally with Webpack Dev Server.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”

   proof ↗⚑ flag

4. ai-native userDrive the product through a documented public API

   weight 3 · round to GitBook
   GitBook✓fullprobed8/10

   GitBook documents a RESTful public API supporting standard HTTP methods (GET/POST/PATCH/DELETE) with a full API reference, plus a CLI and an MCP server that let agents create/configure sites, open change requests, draft and edit content programmatically — directly enabling AI-native users to drive the product outside the UI. Missing for 10: a discoverable machine-readable OpenAPI spec (probe-3 shows all common OpenAPI paths 404) and independent/hands-on corroboration of the API's robustness beyond vendor docs.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   proof ↗⚑ flag

   Docusaurus~partialprobed4/10

   Docusaurus exposes a documented CLI (build, serve, versioning commands) and a plugin/Node API that let a user or script drive site generation and customization programmatically, which is the closest analog to a public API for this static-site-generator category. However, probes confirm there is no REST/OpenAPI, no llms.txt, and no HTTP-callable interface for AI agents to interact with — only local CLI/build-time automation. Missing for 10: HTTP/REST or OpenAPI-documented API, AI-agent discovery file (llms.txt), and any remote/service-style programmatic interface beyond local CLI/plugin hooks.

   • [claimed-docs] “Builds and serves a preview of your site locally with Webpack Dev Server.”
   • [claimed-docs] “Builds and serves a preview of your site locally with [Webpack Dev Server]”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “A plugin is usually an npm package, so you install them like other npm packages using npm.”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

5. ai-native userBuild against official SDKs

   weight 2 · round to Docusaurus
   GitBook—none0/10

   Evidence shows GitBook has a REST API (gitbook-docs-36), a CLI (gitbook-docs-28/34), and an MCP server (gitbook-docs-14/15/33), but there is no mention anywhere of official client SDKs (e.g., JS/Python/Go libraries) for developers to build against. Missing for 10: any official SDK documentation, package registry listings, or language-specific client libraries.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “GitBook CLI”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”

   proof ↗⚑ flag

   Docusaurus~partialprobed5/10

   Docusaurus documents official developer-facing APIs to build against — a plugin architecture (docs-4, docs-8, docs-25), theme swizzling API (docs-10, docs-27), and a documented CLI (docusaurus-probe-4, docusaurus-docs-11) — which count as 'official SDKs' for extending/building sites. However, there is no AI-native machine-readable SDK surface: llms.txt and docs.md both 404, and no OpenAPI spec exists (docusaurus-probe-1, docusaurus-probe-2, docusaurus-probe-3), so an AI agent cannot discover or consume an official SDK spec automatically. Missing for 10: machine-readable API/SDK manifests (llms.txt, OpenAPI), any AI-specific SDK or agent-facing integration docs, and independent confirmation that the plugin/theme APIs are stable enough to be treated as a true SDK.

   • [claimed-docs] “Extend and customize your project's layout by writing React components. Leverage the pluggable architecture, and design your own site while …”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “swizzling permits to swap a theme component with your own implementation”
   • [claimed-docs] “A plugin is usually an npm package, so you install them like other npm packages using npm.”
   • [probe] “official CLI documented at https://docusaurus.io/docs/cli”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to GitBook
   GitBook✓fullclaimed7/10

   GitBook explicitly supports OpenAPI specs with interactive playgrounds that 'let your users test endpoints right on the page with interactive blocks,' plus a documented API reference, directly enabling runnable API docs. Missing for 10: independent/hands-on verification of the interactive playground working in practice, and more detail on the range of runnable example types beyond OpenAPI.

   • [claimed-docs] “Interactive API playgrounds”
   • [claimed-docs] “Add an OpenAPI specification”
   • [claimed-docs] “let your users test endpoints right on the page with interactive blocks”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus's evidence shows only generic MDX/React embedding, versioning, i18n, and search features—no built-in interactive API reference or runnable-example tooling (e.g., OpenAPI/Swagger integration) is documented, and probes for openapi.json/swagger.json all return 404. While MDX could theoretically host custom interactive widgets, there's no evidence of a first-party or documented capability for this specific story.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   GitBook—none0/10

   Probes explicitly show all candidate OpenAPI/spec endpoints (openapi.json, swagger.json, etc.) return 404, and there is no documentation link to download a machine-readable spec of GitBook's own API — the 'Add an OpenAPI specification' docs describe a feature for customers embedding specs in their own docs, not GitBook's own API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “Add an OpenAPI specification”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a documentation site generator, not an API service, but it could plausibly expose a machine-readable spec of its own CLI/config or plugin API; probes explicitly show no OpenAPI/swagger spec exists at any expected path, and no docs mention publishing one.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”

   proof ↗⚑ flag

3. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   GitBook—none0/10

   The evidence shows GitBook has a REST API (gitbook-docs-36) and features for versioning documentation content (gitbook-docs-24), but there is no mention of a versioning scheme or deprecation policy for GitBook's own platform API, and probes for a discoverable OpenAPI spec all returned 404s (gitbook-probe-3), giving no indication of documented API stability guarantees.

   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “Version control”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   proof ↗⚑ flag

   Docusaurus—none0/10

   The pack shows Docusaurus has a 'document versioning' feature for content (docs-6, docs-19, docs-23), but that is unrelated to the story's ask about the framework's own APIs (plugin API, config schema, npm package) being semantically versioned with a documented deprecation policy. No evidence of a changelog, semver policy, or deprecation notices for Docusaurus's own APIs is present; the only related note is that v2 was a 'total rewrite' from v1 (docusaurus-docs-16), which suggests breaking changes rather than a managed deprecation path.

   • [claimed-docs] “Docusaurus v2+ has been a total rewrite from Docusaurus v1, taking advantage of a completely modernized toolchain.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [claimed-docs] “Support users on all versions of your project. Document versioning helps you keep documentation in sync with project releases.”

   proof ↗⚑ flag

Agent access

1. ai-native userMy published docs site exposes its own MCP server that my users' agents can query for search and page content

   weight 3 · round to GitBook
   GitBook✓fullprobed7/10

   GitBook explicitly documents 'MCP servers for published docs' and a general MCP server that AI agents can connect to for querying docs, directly matching the story of published sites exposing an MCP endpoint for search/page content. Missing for 10: no independent/hands-on verification of the published-docs MCP server's search/content-query behavior, and no detail on the exact query capabilities exposed.

   • [claimed-docs] “New: The GitBook MCP server is here. Connect your AI agent”
   • [claimed-docs] “MCP servers for published docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   proof ↗⚑ flag

   Docusaurus—none0/10

   No evidence Docusaurus generates or exposes an MCP server for published docs sites; search is via Algolia DocSearch, not an agent-queryable MCP endpoint, and probes for llms.txt/docs.md/openapi all 404.

   • [claimed-docs] “Docusaurus provides first-class support for Algolia DocSearch.”
   • [claimed-docs] “Make it easy for your community to find what they need in your documentation. We proudly support Algolia documentation search.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

Agent output

1. ai-native userMy published docs site automatically serves llms.txt (and a full-content variant) so agents can index it

   weight 3 · round to GitBook
   GitBook✓fullprobed8/10

   GitBook has a dedicated 'LLM-ready docs' feature page and references an llms-full.txt variant in docs, and a live probe confirms https://gitbook.com/llms.txt actually returns 200 with real content, corroborating the vendor claim. Missing for 10: direct probe confirmation of the llms-full.txt variant and evidence it's automatically enabled across arbitrary customer-published sites, not just gitbook.com itself.

   • [claimed-docs] “LLM-ready docs”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://gitbook.com/llms.txt # GitBook > GitBook is a collaborative platform for creating, publishing and manag…”

   proof ↗⚑ flag

   Docusaurus—none0/10

   No evidence Docusaurus core ships automatic llms.txt or full-content markdown variant generation; direct probes of the Docusaurus own site show 404 for both llms.txt and docs.md, and no docs mention this feature.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”

   proof ↗⚑ flag

2. ai-native userEvery published page serves clean markdown at its URL (e.g. appending .md) so agents skip the HTML

   weight 3 · round to GitBook
   GitBook✓fullprobed7/10

   GitBook explicitly documents an 'LLM-ready docs' feature and the evidence pack itself cites numerous live GitBook docs pages at .md-suffixed URLs (e.g. gitbook-mcp.md, ai-insights.md, customization.md), strongly implying published pages do serve raw markdown when .md is appended; llms.txt is also confirmed live via probe. The one 404 probe (gitbook.com/docs.md) tested a non-page root path rather than an actual content page, so it doesn't concretely contradict the pattern seen elsewhere. Missing for 10: a controlled hands-on test appending .md to an actual customer-published site page (not gitbook.com's own docs) and independent third-party confirmation beyond the vendor's own citations.

   • [claimed-docs] “LLM-ready docs”
   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://gitbook.com/llms.txt # GitBook > GitBook is a collaborative platform for creating, publishing and manag…”
   • [probe] “PROBE docs-md: HTTP 404 at https://gitbook.com/docs.md”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus builds static HTML from Markdown/MDX but there is no evidence of a per-page clean-markdown endpoint (e.g. .md suffix) or llms.txt-style output; direct probes confirm llms.txt and docs.md both 404, indicating this capability is not shipped.

   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”

   proof ↗⚑ flag

Assistant

1. ai-native userAn embedded AI assistant on my docs site answers reader questions with citations into my content

   weight 2 · round to GitBook
   GitBook✓fullclaimed8/10

   GitBook documents a first-party AI Assistant embeddable on published docs sites that answers reader questions grounded in the site's own content, plus AI insights analytics showing what visitors ask and how the assistant responds using that content. missing for 10: explicit confirmation/example that assistant answers include inline citations/links to source pages, and independent (non-vendor) hands-on validation of citation accuracy.

   • [claimed-docs] “AI Assistant”
   • [claimed-docs] “I'm here to help you with the docs.”
   • [claimed-docs] “Add it to your product, website, or docs to give every user accurate, contextual answers.”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”
   • [claimed-docs] “AI search”

   proof ↗⚑ flag

   Docusaurus—none0/10

   No evidence of an embedded AI assistant or Q&A-with-citations feature; Docusaurus documentation covers search (Algolia DocSearch), MDX, plugins, versioning, i18n, etc., but nothing about an AI chat/assistant answering reader questions with citations into content.

   ⚑ flag

Analytics

1. devrel leadI see page views, search terms, and reader feedback so I know which docs work and which fail

   weight 2 · round to GitBook
   GitBook~partialcommunity5/10

   GitBook's pricing/docs pages claim 'Analytics & user feedback' and 'AI insights' that show 'what your visitors are asking and how effectively GitBook Assistant responds,' plus a search feature; one HN reviewer separately praised GitBook's search as 'fast & accurate.' However, page-view analytics accuracy is called into question by a hands-on community report that 'traffic stats are not realistic (counts page loads, off by 2-3x vs Google Analytics), country demographics clearly wrong,' and no evidence documents an explicit reader-feedback widget/mechanism beyond the pricing bullet. Missing for 10: dedicated documentation of a feedback-collection UI, independent corroboration of analytics accuracy, and confirmation the cited stats complaint doesn't still apply to the current platform.

   • [claimed-docs] “Analytics & user feedback”
   • [claimed-docs] “AI insights”
   • [claimed-docs] “AI insights shows what your visitors are asking and how effectively GitBook Assistant responds using your content.”
   • [claimed-docs] “Searching internal content”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”
   • [community] “'GoCD moved its user & developer docs to GitBook... and its been great so far! The best feature by far is fast & accurate search.'”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a static site generator; evidence shows search (Algolia DocSearch) support but nothing about built-in analytics dashboards, page-view tracking, search-term analytics, or reader feedback collection. No evidence of any such capability exists in the pack.

   ⚑ flag

Playground

1. developerReaders can try real API calls from an interactive playground embedded in the reference docs

   weight 2 · round to GitBook
   GitBook✓fullclaimed7/10

   GitBook's docs explicitly advertise 'Interactive API playgrounds' as a pricing feature and describe OpenAPI integration that lets users 'test endpoints right on the page with interactive blocks,' directly matching the story. Missing for 10: independent/hands-on third-party confirmation of the playground actually executing live API calls, and more detail on auth/response handling within the playground.

   • [claimed-docs] “Interactive API playgrounds”
   • [claimed-docs] “Add an OpenAPI specification”
   • [claimed-docs] “let your users test endpoints right on the page with interactive blocks”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a static-site/documentation generator supporting MDX, React embeds, versioning, i18n, and search, but nothing in the evidence pack shows a built-in interactive API playground/try-it-out console for making real API calls; probes for OpenAPI support also failed (404s). Developers could theoretically embed a custom React component for this via MDX, but no evidence shows an out-of-the-box or officially supported playground feature.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

Spec driven

1. developerMy API reference pages are generated from an OpenAPI spec and stay in sync when the spec changes

   weight 3 · round to GitBook
   GitBook~partialclaimed6/10

   GitBook explicitly supports adding an OpenAPI specification to generate API reference pages with interactive playgrounds (gitbook-docs-23, gitbook-docs-5, gitbook-docs-35), and it has Git-sync/version-control features that could keep specs updated (gitbook-docs-27, gitbook-docs-24). However, no evidence explicitly confirms automatic re-sync/regeneration of reference pages when the underlying OpenAPI spec file changes (e.g. webhook-triggered refresh), only general 'flags outdated content' branding (gitbook-docs-1) without specifics tied to OpenAPI. Missing for 10: explicit documentation of automatic spec-change detection/refresh workflow, and independent/hands-on confirmation that the sync actually works reliably.

   • [claimed-docs] “Add an OpenAPI specification”
   • [claimed-docs] “Interactive API playgrounds”
   • [claimed-docs] “let your users test endpoints right on the page with interactive blocks”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Version control”
   • [claimed-docs] “The docs platform that flags outdated content. Then fixes it.”

   proof ↗⚑ flag

   Docusaurus—none0/10

   No evidence pack item mentions OpenAPI spec import, API reference page generation, or spec-sync capability; Docusaurus core is described as a Markdown/MDX static-site generator with docs/blog/pages plugins, not an OpenAPI-driven doc generator. The OpenAPI probe explicitly found no such endpoints/support.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “All features are delegated to individual plugins: the [docs](/docs/docs-introduction) feature provided by the [docs plugin]”

   proof ↗⚑ flag

Authoring

1. technical writerI author pages in Markdown/MDX with rich components — tabs, callouts, code groups, steps — without writing custom HTML

   weight 3 · round to GitBook
   GitBook~partialcommunity7/10

   GitBook's docs confirm a block-based visual editor with custom blocks and Markdown/MDX authoring (gitbook-docs-3, gitbook-docs-46), plus a concrete example of a rich block (the 'updates' changelog block with auto RSS) showing the block system is real (gitbook-docs-44). Community reviews independently praise the web editor and Markdown support (gitbook-comm-3, gitbook-comm-5). However, the pack never explicitly names tabs, callouts, code-groups, or step components, so the exact component set the story cites isn't directly confirmed. Missing for 10: explicit documentation/screenshots naming tabs/callouts/code-group/step blocks, and independent hands-on confirmation of those specific components.

   • [claimed-docs] “Block-based visual editor & custom blocks”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [claimed-docs] “An updates block lets you add a changelog to any page... Any page with an updates block automatically gets an RSS feed”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”
   • [community] “'I've been using GitBook since the early days, and it has improved significantly... The web-based book editor is phenomenal, and it is perfe…”

   proof ↗⚑ flag

   Docusaurus~partialcommunity6/10

   Docusaurus docs confirm built-in MDX/JSX support letting writers embed and import React components directly in Markdown without hand-writing HTML (docusaurus-docs-3, docusaurus-docs-17, docusaurus-docs-31, docusaurus-docs-32), and community users confirm using Markdown+React together happily (docusaurus-comm-13, docusaurus-comm-20). However, the evidence never explicitly names or documents the specific built-in rich components the story calls out (Tabs, admonitions/callouts, code-block groups, Steps) — it only shows general MDX/component-embedding capability. missing for 10: explicit docs citing built-in Tabs/Admonition/CodeBlock-group/Steps components, and hands-on confirmation that writers use them without custom code.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served. You can even embed React co…”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [claimed-docs] “You can even embed React components in your Markdown thanks to MDX.”
   • [community] “Long time user of (and contributor to) Docusaurus. I use it to build my markdown powered tech blog. It is very much a Goldilocks product for…”
   • [community] “I moved from 11ty / eleventy to docusaurus... Very active project. Nice theme out of the box / configuration. Better than any static site ge…”

   proof ↗⚑ flag

2. technical writerNon-technical teammates can edit docs in a visual web editor without touching git, and their changes flow into the same source of truth

   weight 2 · round to GitBook
   GitBook✓fullcommunity8/10

   GitBook's visual block-based editor is explicitly designed for non-git users, with real-time collaboration and version control built in, and the same content syncs bidirectionally with Git ('Write in the editor, drive it from your agent, or sync from Git'), keeping one source of truth. Community reviews independently corroborate the web editor experience as 'phenomenal' and suited for non-developers writing docs with version control. Missing for 10: no independent evidence specifically confirming non-technical teammates' edits merge cleanly with git-synced changes without conflicts, and no hands-on account from a non-technical user's perspective.

   • [claimed-docs] “Block-based visual editor & custom blocks”
   • [claimed-docs] “Invite your team to collaborate”
   • [claimed-docs] “Change requests”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [claimed-docs] “Write in the editor, drive it from your agent, or sync from Git.”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [community] “'I've been using GitBook since the early days, and it has improved significantly... The web-based book editor is phenomenal, and it is perfe…”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a git-based, MDX/React static site generator with no visual web editor for non-technical users — all editing happens via markdown files and git workflows; no evidence of a WYSIWYG editor or non-git content sync.

   ⚑ flag

Content reuse

1. technical writerReusable snippets and variables keep repeated content in sync across pages

   weight 1 · round to GitBook
   GitBook✓fullclaimed8/10

   GitBook's docs explicitly document a 'Reusable content' feature for defining reusable snippets/blocks that sync across pages, plus 'Content variants' for variable-driven content reuse, directly matching the story. missing for 10: independent/hands-on community corroboration specifically about snippet/variable syncing (community evidence in the pack covers other features, not this one).

   • [claimed-docs] “Reusable content”
   • [claimed-docs] “Content variants”

   proof ↗⚑ flag

   Docusaurus~partialclaimed6/10

   Docusaurus's MDX support lets writers define partial files and import them as reusable components across pages (docs-3, docs-31), which is the documented mechanism for reusable snippets, but the evidence pack never explicitly mentions a dedicated 'variables' or site-wide constants feature (e.g. customFields) or admonition-style snippet reuse guidance. missing for 10: explicit docs on site-wide variables/customFields, dedicated partials/snippets guide, independent hands-on confirmation that content stays in sync across pages.

   • [claimed-docs] “Docusaurus has built-in support for MDX, which allows you to write JSX within your Markdown files and render them as React components.”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served. You can even embed React co…”

   proof ↗⚑ flag

Quality

1. technical writerAutomated checks lint my content against a style guide and flag issues before they publish

   weight 2 · round drawn
   GitBook—none0/10

   GitBook's AI features (agent, assistant, AI insights) focus on flagging outdated/missing content and answering reader questions, not on linting prose against a style guide before publishing. No evidence of style-guide rules, vale-like linting, or pre-publish content-quality checks tied to a style guide.

   ⚑ flag

   Docusaurus—none0/10

   No evidence of any built-in or first-party linting/style-guide checking feature for content; Docusaurus docs cover MDX authoring, versioning, i18n, search, deployment, but nothing about automated prose/style linting before publish.

   ⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to GitBook
   GitBook~partialprobed5/10

   GitBook exposes a REST API (GET/POST/PATCH/DELETE) and an MCP server/CLI that agents can use to create/configure sites, open change requests, draft content, edit pages, and restructure docs, which enables scripted bulk-style operations across many pages/spaces programmatically. However, there's no first-party bulk-operations UI or documented batch endpoints (e.g., bulk update/delete/move across many items in one call), and no independent evidence of bulk workflows being used at scale. missing for 10: dedicated bulk-edit/batch API endpoints, documented bulk UI actions, and independent confirmation of large-scale automation use.

   • [claimed-docs] “Tools like Claude Code, Codex, Cursor, and other MCP clients can use it to create and configure sites, open change requests, draft content, …”
   • [claimed-docs] “list organizations, inspect spaces and pages, ask questions against your docs, and build and publish integrations — all without leaving the …”
   • [claimed-docs] “This API is RESTful and supports standard HTTP methods like GET, POST, PATCH, and DELETE.”
   • [claimed-docs] “GitBook CLI”
   • [probe] “official MCP server documented at https://gitbook.com/docs/docs-as-code/gitbook-mcp”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a static site generator with a CLI for building/serving sites, but there is no evidence of any bulk operation capability across many content items (e.g., bulk editing, batch content transformation, mass metadata updates) beyond a single site build/version command; probes for machine-readable APIs (llms.txt, docs.md, openapi) all returned 404, showing no programmatic bulk-automation surface. Missing for 10: any documented bulk-edit/batch-processing feature, API or CLI subcommand for operating across many items at once, and evidence of AI-native automation tooling.

   • [claimed-docs] “Builds and serves a preview of your site locally with Webpack Dev Server.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://docusaurus.io/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://docusaurus.io/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docusaurus.io/openapi.json, https://docusaurus.io/swagger.json, https://docusaurus.io/api/op…”

   proof ↗⚑ flag

Theming

1. devrel leadI customize themes, fonts, and layout — down to custom CSS/JS or my own components — so the docs match my brand

   weight 2 · round to Docusaurus
   GitBook~partialcommunity4/10

   GitBook advertises 'Site customization', 'Advanced branding options', and a 'block-based visual editor & custom blocks' plus custom domain support, showing some theme/branding controls (gitbook-docs-3, -11, -30, -47). However, none of the evidence explicitly confirms custom CSS/JS injection or embedding of fully custom React/UI components, and a community reviewer explicitly called landing-page customization 'limited' (gitbook-comm-3), directly cutting against a full brand-matching claim. missing for 10: explicit docs on custom CSS/JS support, custom component/embed capability, and independent confirmation that deep branding (beyond logo/colors/domain) is achievable.

   • [claimed-docs] “Block-based visual editor & custom blocks”
   • [claimed-docs] “Advanced branding options”
   • [claimed-docs] “Site customization”
   • [claimed-docs] “You can customize the appearance of your published documentation, match the user interface to the language of your content, and more.”
   • [community] “'I'm using gitbook to write a book currently... its an excellent platform for writers. Most of the product is open-source... Version control…”

   proof ↗⚑ flag

   Docusaurus✓fullcommunity9/10

   Docusaurus provides multiple documented layers of theming/branding: custom CSS import via classic theme (docusaurus-docs-9/26/41), full React component customization and MDX embedding (docusaurus-docs-4/31/33), and swizzling to override/replace built-in theme components entirely (docusaurus-docs-10/27), plus a plugin architecture for deeper extension (docusaurus-docs-8/40). Community testimonials corroborate real-world use of React/TypeScript/CSS customization (docusaurus-comm-13/20). Missing for 10: independent hands-on verification specifically of brand-level theming (fonts/logo/full rebrand) rather than general customization mentions.

   • [claimed-docs] “you can create your own CSS files (e.g. /src/css/custom.css) and import them globally by passing them as an option of the classic theme.”
   • [claimed-docs] “If you're using `@docusaurus/preset-classic`, you can create your own CSS files (e.g. `/src/css/custom.css`) and import them globally”
   • [claimed-docs] “swizzling permits to swap a theme component with your own implementation”
   • [claimed-docs] “swizzling permits to **swap a theme component with your own implementation**”
   • [claimed-docs] “Extend and customize your project's layout by writing React components. Leverage the pluggable architecture, and design your own site while …”
   • [claimed-docs] “You can also import your own components defined in other files or third-party components installed via npm.”
   • [claimed-docs] “Extend and customize your project's layout by writing React components.”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [community] “Long time user of (and contributor to) Docusaurus. I use it to build my markdown powered tech blog. It is very much a Goldilocks product for…”
   • [community] “I moved from 11ty / eleventy to docusaurus... Very active project. Nice theme out of the box / configuration. Better than any static site ge…”

   proof ↗⚑ flag

Git workflow

1. developerMy docs live in my own git repository — branches, pull requests, and merges drive what gets published

   weight 3 · round drawn
   GitBook✓fullcommunity8/10

   GitBook documents GitHub/GitLab Sync as a core docs-as-code workflow, with version control, change requests, and branch/PR-driven publishing explicitly covered in official docs (gitbook-docs-4, gitbook-docs-24, gitbook-docs-27, gitbook-docs-29, gitbook-docs-46). Community evidence corroborates the platform's version-control and Git-based editing heritage, though some users note GitBook has shifted away from pure open-source/CLI git workflows toward its SaaS platform (gitbook-comm-13, gitbook-comm-17). missing for 10: independent hands-on confirmation that PR merges directly trigger publishing (vs. GitBook's own change-request review flow), and more detail on conflict handling between Git-sync and in-app edits.

   • [claimed-docs] “Sync with GitHub or GitLab”
   • [claimed-docs] “Version control”
   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Change requests”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   proof ↗⚑ flag

   Docusaurus✓fullcommunity8/10

   Docusaurus is fundamentally a static-site generator that builds from Markdown/MDX files stored in your own repo, and its docs plugin explicitly reads content from a `docs` directory that you version-control (versioning CLI operates on `docs` directory content), with localization also handled 'via git' or other translation managers. It deploys to static hosts like GitHub Pages, Netlify, Vercel that are commonly wired to git push/PR/merge triggers, and community users confirm using it for markdown-based docs-as-code workflows (migrating docs, contributing via git). Missing for 10: no explicit documentation of PR-preview builds, branch-based deploy previews, or CI/CD pipeline configuration specifics.

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “All features are delegated to individual plugins: the docs feature provided by the docs plugin; the blog feature provided by the blog plugin…”
   • [claimed-docs] “Localization comes out-of-the-box. Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the `docs` directory.”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [community] “Long time user of (and contributor to) Docusaurus. I use it to build my markdown powered tech blog. It is very much a Goldilocks product for…”
   • [community] “I moved from 11ty / eleventy to docusaurus... Very active project. Nice theme out of the box / configuration. Better than any static site ge…”

   proof ↗⚑ flag

Quality gates

1. developerCI validation catches broken links and invalid configuration before the site publishes

   weight 2 · round drawn
   GitBook—none0/10

   No evidence of CI-integrated link/config validation (e.g., a check that runs in pull requests or build pipelines to catch broken links or invalid config before publish). GitBook's docs-as-code features cover Git sync, change requests, and preview deployments, but nothing describes automated CI validation for links/config prior to publishing.

   ⚑ flag

   Docusaurus—none0/10

   No evidence pack items mention broken-link checking, config validation, or CI integration/build-failure behavior for invalid content; only build/serve/deploy CLI commands are documented. This is a fair axis for a docs-as-code SSG (Docusaurus does have onBrokenLinks options in reality, but nothing in the evidence pack supports it).

   ⚑ flag

1. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Docusaurus
   GitBook~partialcommunity5/10

   GitBook supports two-way Git Sync with GitHub/GitLab, storing content as Markdown with version control, which gives a real open-format export/exit path (gitbook-docs-27, gitbook-docs-24, gitbook-docs-46). However, there's no documented full-data export (analytics, users, integrations) and community feedback explicitly criticizes GitBook for moving away from open-source/self-hosted use and locking features behind its SaaS ('non open source behavior to only support their monthly service', 'abandoned open source spirit') (gitbook-comm-13, gitbook-comm-15). Missing for 10: a documented one-click full-account export, confirmation that all site/analytics/config data (not just page content) is portable, and resolution of community concerns about SaaS lock-in.

   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “Version control”
   • [claimed-docs] “GitBook’s AI-native visual editor makes it easy to write, review, and publish technical content — with Markdown, real-time collaboration, ve…”
   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”

   proof ↗⚑ flag

   Docusaurus✓fullcommunity8/10

   Docusaurus content is authored as plain Markdown/MDX files stored in the user's own git repo and compiled to static HTML, meaning there is no proprietary data store to 'export from' — the source of truth is already an open, portable format the user fully owns, reinforced by MIT licensing and git/Crowdin-based translation workflows. missing for 10: no explicit vendor documentation framing this as a 'data export/exit' guarantee, and no independent report confirming users successfully migrated away with zero data loss (only anecdotal mentions of switching to other SSGs).

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served. You can even embed React co…”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “Localization comes out-of-the-box. Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [community] “It's probably also a good thing that Facebook dogfoods Docusaurus in some places, while keeping it MIT licensed so the community can fork it…”
   • [community] “For writing technical styled documentation, I've found fumadocs to be amazing... We just moved to it from Docusaurus and couldn't be happier…”

   proof ↗⚑ flag

2. ai-native userRead the product's source under an open license

   weight 2 · round to Docusaurus
   GitBook—none0/10

   No first-party evidence that GitBook publishes its source under an open license; recent community reports explicitly state GitBook moved away from open source and no longer actively develops its once-open CLI, confirming the product is closed-source SaaS today.

   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   proof ↗⚑ flag

   Docusaurus✓fullcommunity7/10

   Community evidence confirms Docusaurus is open source and MIT licensed, with users noting they can read, fork, and contribute to the source code (docusaurus-comm-16, docusaurus-comm-1). No evidence contradicts open licensing. missing for 10: first-party documentation or GitHub repo citation explicitly stating the MIT license, and no direct link to the source repository in the evidence pack.

   • [community] “It's probably also a good thing that Facebook dogfoods Docusaurus in some places, while keeping it MIT licensed so the community can fork it…”
   • [community] “So happy to see Docusaurus hit the big 2.0! I use it to power my blog and it's a tremendous tool. The DX is fantastic and it's open source! …”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Docusaurus
   GitBook—none0/10

   GitBook is documented and confirmed by community evidence as a SaaS-only platform; multiple users explicitly note GitBook 'moved everything to their SaaS with artificial barriers to just using the software' and abandoned its open-source spirit, with the CLI 'no longer under active development.' No vendor documentation anywhere offers a self-hosted deployment option for the core product.

   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”

   proof ↗⚑ flag

   Docusaurus✓fullcommunity9/10

   Docusaurus is a static-site generator that builds fully self-hostable static HTML output via `npm run build`, deployable to any static host (Vercel, Netlify, GitHub Pages, or self-managed servers) with no vendor lock-in, and is MIT licensed so it can be forked/self-maintained indefinitely. Community evidence corroborates real-world self-hosting and even forking concerns being addressed by its open license. Missing for 10: no first-party Docker/container self-hosting guide or independent benchmark of a fully self-hosted deployment pipeline.

   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [community] “It's probably also a good thing that Facebook dogfoods Docusaurus in some places, while keeping it MIT licensed so the community can fork it…”
   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”

   proof ↗⚑ flag

1. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   GitBook—none0/10

   No evidence in the pack addresses telemetry, analytics opt-out, or usage tracking controls for AI-native users; the closest items (Analytics & user feedback, AI insights) describe collecting data, not opting out of it.

   ⚑ flag

   Docusaurus—none0/10

   The evidence pack contains no mention of telemetry, analytics collection, or an opt-out mechanism for Docusaurus's CLI or build process; while such a capability is plausible for a CLI-driven static site generator, there is no documentation or community evidence confirming it exists.

   ⚑ flag

Access control

1. devrel leadI gate some or all docs behind authentication — password, JWT, or SSO — for customers-only content

   weight 1 · round to GitBook
   GitBook~partialclaimed6/10

   GitBook's official docs include a dedicated 'Authenticated access' page under Publish > Site Audience, directly matching the gating-content-behind-auth use case, but the evidence pack gives only the page title with no detail on which auth mechanisms (password vs JWT vs SSO) are actually supported or how they're configured, and there's no independent/community corroboration of this specific feature working in practice. Missing for 10: documented specifics on password/JWT/SSO configuration options, plan-tier restrictions, and independent verification that authenticated access works as described.

   • [claimed-docs] “Authenticated access”

   proof ↗⚑ flag

   Docusaurus—none0/10

   Docusaurus is a static site generator; the evidence pack contains no mention of built-in authentication, password protection, JWT, or SSO gating features. Since Docusaurus builds static HTML files meant to be publicly served (docs-2, docs-13), auth-gating is a plausible but unaddressed capability for a docs publishing tool, making this 'none' rather than 'na'.

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”

   proof ↗⚑ flag

Domains

1. devrel leadI serve docs on my own custom domain or as a /docs subpath of my main site

   weight 2 · round to GitBook
   GitBook✓fullclaimed8/10

   GitBook explicitly documents custom domain support ('You can customize this by setting a custom domain, meaning your audience can access your documentation on a chosen domain') and lists 'Use a custom domain' as a pricing feature. This directly satisfies the core ask of serving docs on a custom domain. missing for 10: no explicit documentation or example of a /docs subpath deployment on the main site's domain, and no independent/hands-on confirmation of custom domain setup beyond vendor docs.

   • [claimed-docs] “Use a custom domain”
   • [claimed-docs] “You can customize this by setting a custom domain, meaning your audience can access your documentation on a chosen domain.”

   proof ↗⚑ flag

   Docusaurus~partialclaimed5/10

   Docusaurus docs confirm it builds static files deployable to common static hosts (Vercel, GitHub Pages, Netlify, etc.) and provides a `docusaurus serve` command, which implicitly supports custom domains via those hosts. However, the evidence pack never explicitly documents the `baseUrl` config for subpath deployment or custom-domain setup instructions (e.g., CNAME files), leaving the core of the story only inferred rather than directly evidenced. Missing for 10: explicit docs on baseUrl/subpath configuration, explicit custom-domain setup guidance, and independent confirmation of successful custom-domain/subpath deployments.

   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”

   proof ↗⚑ flag

Portability

1. developerExport my entire docs site as a static bundle and host it anywhere, so my content is never locked in

   weight 2 · round to Docusaurus
   GitBook—none0/10

   GitBook offers Git sync of markdown source content but no documented feature for exporting the full rendered site (theme, navigation, assets) as a static bundle for self-hosting elsewhere; probes for such export endpoints return 404. Community commentary explicitly describes lock-in concerns ('artificial barriers to just using the software... non open source behavior to only support their monthly service', 'abandoned open source spirit') and the CLI being deprecated, reinforcing that no portable static-export path exists.

   • [claimed-docs] “GitHub & GitLab Sync”
   • [claimed-docs] “GitBook CLI”
   • [community] “'Gitbook was a great project, but they really moved everything to their SaaS with artificial barriers to just using the software... such a n…”
   • [community] “'This is much needed as GitBook moved away from Book publishing and abandoned open source spirit.'”
   • [community] “GitBook README cited as reason for community fork: 'As the efforts of the GitBook team are focused on the GitBook.com platform, the CLI is n…”
   • [probe] “PROBE docs-md: HTTP 404 at https://gitbook.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://gitbook.com/openapi.json, https://gitbook.com/swagger.json, https://gitbook.com/api/openapi.…”

   proof ↗⚑ flag

   Docusaurus✓fullclaimed9/10

   Docusaurus builds static HTML files via `npm run build` into a `build` directory, which can be hosted on any static host (Vercel, GitHub Pages, Netlify, Render, Surge) or served locally via `docusaurus serve`, confirming no vendor lock-in. Community comments corroborate real-world deployment and migration flexibility. Missing for 10: no independent hands-on verification of exporting/re-hosting a site across multiple providers beyond docs claims.

   • [claimed-docs] “Simply write docs and blog posts with MDX, and Docusaurus builds them into static HTML files ready to be served.”
   • [claimed-docs] “To build the static files of your website for production, run: npm run build”
   • [claimed-docs] “Once it finishes, the static files will be generated within the `build` directory.”
   • [claimed-docs] “You can deploy your site to static site hosting services such as [Vercel](https://vercel.com/), [GitHub Pages](https://pages.github.com/), […”
   • [claimed-docs] “Docusaurus provides a [`docusaurus serve`](/docs/cli#docusaurus-serve-sitedir) command for that”

   proof ↗⚑ flag

Search

1. developerReaders get fast, typo-tolerant, relevance-ranked search over the whole docs site out of the box

   weight 3 · round to GitBook
   GitBook~partialcommunity6/10

   GitBook documents a built-in 'AI search' feature and a dedicated 'Searching internal content' doc, and independent community feedback praises GitBook's search as 'fast & accurate' out of the box. However, no evidence explicitly confirms typo-tolerance or details on relevance-ranking algorithms, so the specific claims in the story are only partially substantiated. Missing for 10: explicit documentation of typo-tolerant/fuzzy matching, technical detail on relevance ranking, and independent hands-on testing of search quality across a full site.

   • [claimed-docs] “AI search”
   • [claimed-docs] “Searching internal content”
   • [community] “'GoCD moved its user & developer docs to GitBook... and its been great so far! The best feature by far is fast & accurate search.'”

   proof ↗⚑ flag

   Docusaurus~partialclaimed5/10

   Docusaurus does not ship its own out-of-the-box search index; it relies on integrating third-party Algolia DocSearch, which requires a separate application/setup and free-tier approval, and there's a migration note suggesting the infra has changed over time. Typo-tolerant, relevance-ranked search is achieved via Algolia (once configured), not built-in by default. missing for 10: evidence of a zero-config/built-in local search out of the box, independent confirmation of Algolia's typo-tolerance/ranking quality in practice, and details on setup friction or fallback for sites not approved for free DocSearch.

   • [claimed-docs] “Docusaurus provides first-class support for Algolia DocSearch.”
   • [claimed-docs] “You can read more about migration from the legacy DocSearch infra in our blog post”
   • [claimed-docs] “Make it easy for your community to find what they need in your documentation. We proudly support Algolia documentation search.”
   • [claimed-docs] “The service is **free** for any developer documentation or technical blog: just make sure to read the [checklist]”
   • [claimed-docs] “We proudly support Algolia documentation search.”

   proof ↗⚑ flag

Localization

1. technical writerI publish my docs in multiple languages with translated navigation and content

   weight 1 · round to Docusaurus
   GitBook~partialcommunity6/10

   GitBook docs describe auto-translation features to keep content updated across languages with minimal effort, and site customization docs note the UI can match the language of the content (implying localized navigation elements). However, there's no explicit first-party documentation detailing translated navigation menus/labels specifically, and the only independent corroboration of multi-language support is from a much older version of the product (pre-SaaS book publishing era). Missing for 10: explicit documentation of translated navigation trees/menus, current independent/hands-on verification of multi-language site publishing.

   • [claimed-docs] “Auto translations make it easy to keep your documentation up-to-date in multiple languages, with minimal manual effort.”
   • [claimed-docs] “You can customize the appearance of your published documentation, match the user interface to the language of your content, and more.”
   • [community] “GitBook co-founder: 'We have a lot of non-english books actually... over a thousand in chinese alone. In the upcoming 2.0.0 release, we've f…”

   proof ↗⚑ flag

   Docusaurus✓fullclaimed9/10

   Docusaurus has built-in i18n support explicitly designed for translating docs and navigation, with support for git/Crowdin translation workflows and RTL locales, plus versioning to keep translated docs in sync with releases. Missing for 10: independent hands-on verification of translated navigation specifically (community evidence focuses on other features, not i18n workflows).

   • [claimed-docs] “It is easy to translate a Docusaurus website with its internationalization (i18n) support.”
   • [claimed-docs] “Localization comes out-of-the-box. Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “It is **easy to translate a Docusaurus website** with its internationalization ([i18n](https://en.wikipedia.org/wiki/Internationalization_an…”
   • [claimed-docs] “Use git, Crowdin, or any other translation manager to translate your docs and deploy them individually.”
   • [claimed-docs] “**RTL support**: locales reading right-to-left (Arabic, Hebrew, etc.) are supported and easy to implement”

   proof ↗⚑ flag

Versioning

1. developerI publish versioned documentation per product or API version, and readers switch versions from the site

   weight 3 · round to Docusaurus
   GitBook~partialclaimed6/10

   GitBook documents a 'Content variants' feature explicitly for maintaining multiple versions of a site (e.g., per product/API version) and separate 'Version control' docs-as-code capability, which together support the story of versioned docs with reader-facing switching. However, all evidence is vendor documentation with no independent hands-on confirmation of the version-switcher UI/UX or how seamless the reader experience is. Missing for 10: independent/community verification of the version switcher working well in practice, and more detail on how readers navigate between variants.

   • [claimed-docs] “Content variants”
   • [claimed-docs] “Version control”
   • [claimed-docs] “each site is made up of sections — the pages you write and edit live inside a section. Related sections can be organized into groups to shap…”

   proof ↗⚑ flag

   Docusaurus✓fullclaimed9/10

   Docusaurus has built-in, well-documented versioning support (versioning CLI to snapshot docs directory into a version, version dropdown for readers to switch) and dedicated docs on this exact workflow, plus i18n for localization. No independent hands-on corroboration specifically for the versioning UX is present, and no evidence of a version-switcher dropdown being explicitly named, so missing for 10: independent/community confirmation of the version-switch UI in practice, edge-case coverage for large numbers of versions.

   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the docs directory.”
   • [claimed-docs] “Support users on all versions of your project. Document versioning helps you keep documentation in sync with project releases.”
   • [claimed-docs] “You can use the versioning CLI to create a new documentation version based on the latest content in the `docs` directory.”
   • [claimed-docs] “It is **easy to translate a Docusaurus website** with its internationalization ([i18n](https://en.wikipedia.org/wiki/Internationalization_an…”

   proof ↗⚑ flag