Docusaurus vs Fern

Agent access

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

   weight 2 · round to Fern
   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

   Fern✓fullprobed9/10

   Fern documents and probes confirm automatic llms.txt generation, clean Markdown pages via .md suffix, agent directives, and this is independently verified by a live probe returning HTTP 200 with agent instructions at /llms.txt. Fern also hosts an MCP server and analytics for llms.txt usage. Missing for 10: independent third-party (non-Fern-docs) confirmation of agent consumption in the wild beyond the one probe.

   • [claimed-docs] “Fern serves clean Markdown for any documentation page so agents can consume your content efficiently. Agents fetch the source by appending `…”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file so AI tools can discover and index your …”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file”
   • [claimed-docs] “To override the default, set a custom directive using the `agents` key in `docs.yml`”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [probe] “PROBE llms.txt: HTTP 200 at https://buildwithfern.com/llms.txt # Fern Documentation ## Instructions for AI Agents - For clean Markdown of …”
   • [probe] “PROBE docs-md: HTTP 404 at https://buildwithfern.com/learn.md”

   proof ↗⚑ flag

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

   weight 2 · round to Fern
   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

   Fern✓fullprobed7/10

   Fern's CLI is explicitly designed for automation: every command outputs JSON for piping/scripting, and it's distributed via installers (Homebrew, npm, curl) enabling CI installation and headless use for validating, generating SDKs, and publishing docs. Fern Agent can also run on a schedule to open PRs automatically, further supporting headless/CI workflows. Missing for 10: no explicit CI pipeline example (e.g., GitHub Actions snippet), no independent/community confirmation of headless CI usage.

   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern publishes signed binaries to Homebrew, npm, pnpm, Scoop, and a one-line curl installer on every release.”
   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [probe] “official CLI documented at https://buildwithfern.com/learn/cli-api-reference/cli-reference/overview”

   proof ↗⚑ flag

3. ai-native userUse an official CLI

   weight 2 · round to Fern
   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

   Fern✓fullprobed9/10

   Fern ships an official CLI (fern-docs-1) distributed via signed binaries on Homebrew, npm, pnpm, Scoop, and curl (fern-docs-35), with AI-native design explicitly called out: every command outputs JSON so coding agents can pipe calls (fern-docs-34), and probe confirms official CLI docs exist (fern-probe-5). Missing for 10: independent/hands-on community verification of CLI's agentic JSON behavior beyond vendor docs.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern publishes signed binaries to Homebrew, npm, pnpm, Scoop, and a one-line curl installer on every release.”
   • [probe] “official CLI documented at https://buildwithfern.com/learn/cli-api-reference/cli-reference/overview”

   proof ↗⚑ flag

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

   weight 3 · round to Fern
   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

   Fern~partialprobed6/10

   A probe confirms Fern publishes a public OpenAPI spec at buildwithfern.com/openapi.json, and the CLI is documented to emit JSON so 'coding agents can pipe one call into the next,' giving AI-native users a programmatic path to drive the product. However, there's no explicit first-party 'API reference' page for Fern's own platform API (only the raw spec) and no independent confirmation of usage. Missing for 10: a dedicated documented API reference page, independent/community corroboration of driving Fern via its API, and clearer distinction between Fern's own platform API vs. customer-generated SDKs.

   • [probe] “PROBE openapi: HTTP 200 at https://buildwithfern.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”

   proof ↗⚑ flag

5. ai-native userBuild against official SDKs

   weight 2 · round to Fern
   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

   Fern✓fullcommunity8/10

   Fern is explicitly a SDK generator platform producing type-safe, idiomatic client libraries in 9+ languages (TypeScript, Python, Java, Go, Ruby, PHP, C#) from a single API spec, with pagination helpers and other SDK-native features, positioning it squarely for AI-native developers to build against generated official SDKs; community corroboration (HN) confirms it delivers end-to-end SDK generation. missing for 10: independent hands-on verification of SDK quality/reliability across all languages, and clearer evidence of long-term maintenance/versioning guarantees for generated SDKs.

   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”
   • [claimed-docs] “Generate client libraries in multiple languages.”
   • [claimed-docs] “Fern generates SDKs in 9 languages from a single API specification”
   • [claimed-docs] “Pagination helpers. Cursor-based and offset-based pagination are first-class.”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Fern
   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

   Fern~partialclaimed5/10

   Fern generates full API reference documentation from OpenAPI specs (including GraphQL type pages) and produces SDKs in multiple languages with code snippets, which is the foundation for an interactive reference. However, the evidence never explicitly documents a 'try it now' / runnable request console or live execution feature within the API reference itself. missing for 10: explicit documentation of an interactive 'try it' console or live request execution, hands-on/independent confirmation of runnable examples.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “GraphQL API References now include a page for every named type in your schema, collected under a `Types` section at the API Reference root a…”
   • [claimed-docs] “Fern generates SDKs in 9 languages from a single API specification”
   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”

   proof ↗⚑ flag

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

   weight 2 · round to Fern
   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

   Fern✓fullprobed8/10

   Fern generates API references from OpenAPI specs (fern-docs-22) and the product's own site exposes a live, machine-readable openapi.json confirmed via probe (fern-probe-3), demonstrating the platform both consumes and can serve OpenAPI specs. Missing for 10: no explicit first-party doc describing a built-in 'download/export spec' button for end-customers' generated docs sites, and no independent third-party confirmation of that export UX beyond the self-probe.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [probe] “PROBE openapi: HTTP 200 at https://buildwithfern.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Fern—none0/10

   Fern documents a 'Versions' feature that lets customers add version dropdowns to their own docs/API references, but there is no evidence of Fern's own APIs, CLI, or SDK generator having a documented deprecation policy or semantic versioning guarantees that an AI-native user could rely on. missing for 10: evidence of Fern's own API/CLI versioning scheme, changelog of breaking-change policy, explicit deprecation timeline documentation.

   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content. Each version can contain its own tabs, sections, pages, and …”
   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content.”
   • [claimed-docs] “Add a dropdown version selector for multiple”

   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 Fern
   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

   Fern✓fullprobed9/10

   Fern documents that every documentation site with Ask Fern enabled gets an automatically generated, production-ready MCP server that connects AI clients (Claude Code, Cursor, Windsurf) to the docs as an external data source for search and page content, letting readers' agents get instant answers within their dev environment. This is corroborated by a dedicated docs page and probe confirming the feature is documented. Missing for 10: independent (non-vendor) hands-on verification that the MCP server works end-to-end in practice.

   • [claimed-docs] “Fern automatically generates and hosts a production-ready Model Context Protocol (MCP) server for every documentation site with Ask Fern ena…”
   • [claimed-docs] “The server connects AI clients like Claude Code, Cursor, and Windsurf to your documentation as an external data source, so your readers can …”
   • [probe] “official MCP server documented at https://buildwithfern.com/learn/docs/ai-features/mcp-server”

   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 Fern
   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

   Fern✓fullprobed9/10

   Fern documents automatic generation and maintenance of llms.txt (fern-docs-7/37), plus serving clean Markdown variants of pages via .md/.mdx suffix (fern-docs-6), and this is independently confirmed by a live probe returning HTTP 200 with correct llms.txt content and agent instructions (fern-probe-1). Analytics even track llms.txt usage by LLM provider (fern-docs-18). Missing for 10: independent third-party corroboration beyond the single probe, and the docs-md probe for a specific page returned 404 (fern-probe-2), suggesting some inconsistency in full-content variant availability across all pages.

   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file so AI tools can discover and index your …”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file”
   • [claimed-docs] “Fern serves clean Markdown for any documentation page so agents can consume your content efficiently. Agents fetch the source by appending `…”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [probe] “PROBE llms.txt: HTTP 200 at https://buildwithfern.com/llms.txt # Fern Documentation ## Instructions for AI Agents - For clean Markdown of …”
   • [probe] “PROBE docs-md: HTTP 404 at https://buildwithfern.com/learn.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 Fern
   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

   Fern!disputedcontradicted5/10

   Fern's docs explicitly claim every documentation page serves clean Markdown by appending `.md` to the URL (fern-docs-6) and the llms.txt probe confirms this pattern is advertised (fern-probe-1), but a hands-on probe against an actual Fern-hosted page (buildwithfern.com/learn.md) returned HTTP 404 instead of Markdown (fern-probe-2), directly contradicting the universal claim. missing for 10: a successful probe on an actual content page returning clean Markdown, and clarification on which paths the `.md` suffix reliably works for.

   • [claimed-docs] “Fern serves clean Markdown for any documentation page so agents can consume your content efficiently. Agents fetch the source by appending `…”
   • [claimed-docs] “Fern implements this standard, automatically generating and maintaining an `llms.txt` Markdown file so AI tools can discover and index your …”
   • [probe] “PROBE llms.txt: HTTP 200 at https://buildwithfern.com/llms.txt # Fern Documentation ## Instructions for AI Agents - For clean Markdown of …”
   • [probe] “PROBE docs-md: HTTP 404 at https://buildwithfern.com/learn.md”

   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 Fern
   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

   Fern✓fullclaimed8/10

   Ask Fern is a first-party embedded AI assistant that indexes documentation and answers reader questions with citations linking to source pages, directly matching the story. Missing for 10: independent/hands-on third-party corroboration of citation accuracy and no community validation of the feature's real-world quality.

   • [claimed-docs] “Ask Fern indexes your documentation and provides an interface for your end users to ask questions and get answers. Responses include citatio…”
   • [claimed-docs] “You can now replace the default Ask Fern disclaimer (“Responses are generated using AI and may contain mistakes.”) with your own wording.”

   proof ↗⚑ 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 Fern
   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

   Fern~partialclaimed5/10

   Fern's docs mention automations that can 'review your reader feedback, unanswered Ask Fern questions, search queries, or analytics' (fern-docs-8/25) and a Web Analytics/llms.txt usage tab tracking traffic by LLM provider (fern-docs-18/44), implying some page-view, search, and feedback signals exist. However there's no dedicated analytics dashboard walkthrough showing page views, search-term breakdowns, or reader feedback UI in one coherent place — missing for 10: a first-party analytics dashboard doc/screenshot showing page views, search term reports, and reader feedback aggregation, and independent/hands-on confirmation that these metrics are usable by a DevRel lead.

   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”
   • [claimed-docs] “Track usage in the [Web Analytics tab]”

   proof ↗⚑ flag

Playground

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

   weight 2 · round drawn
   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

   Fern—none0/10

   The evidence pack covers Fern's SDK generation, docs platform, AI/MCP features, CLI, and preview/versioning tools, but contains no mention of an interactive 'try it' playground for executing real API calls within the reference docs. Although this is a plausible feature for an API documentation platform, none of the docs, changelog entries, or community posts describe it.

   ⚑ 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 Fern
   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

   Fern✓fullclaimed7/10

   Fern's docs explicitly state it generates API Reference documentation from an OpenAPI specification (fern-docs-22, fern-docs-46), and the CLI supports validating and republishing docs from the spec (fern-docs-1, fern-docs-33), with generated GraphQL type pages reflecting schema changes (fern-docs-9), confirming spec-driven generation. missing for 10: explicit description of automatic re-sync/CI pipeline when the OpenAPI spec changes, and independent/hands-on confirmation that reference pages update without manual regeneration steps.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”
   • [claimed-docs] “GraphQL API References now include a page for every named type in your schema, collected under a `Types` section at the API Reference root a…”
   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”

   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 drawn
   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

   Fern~partialclaimed6/10

   Fern explicitly supports authoring pages in Markdown and generating API references from OpenAPI, which covers the base authoring workflow, but the evidence pack lacks direct documentation of specific rich components like tabs, callouts, code groups, and steps that a technical writer would use without custom HTML. missing for 10: explicit docs/examples of tabs, callouts, code-group, and step components in MDX, and independent/hands-on confirmation that these render without custom HTML.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Run a local preview server to view documentation changes instantly with hot reload. Offline access is available after the first online run.”

   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 Fern
   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

   Fern✓fullclaimed8/10

   Fern Editor is explicitly documented as a visual, no-code, no-Git editing interface for non-technical roles (content writers, PMs, marketers), and edits presumably sync back into the same docs source (git) that developers use. missing for 10: independent/hands-on confirmation that Editor changes actually commit into the same git source of truth without conflicts, and more detail on the sync/versioning workflow.

   • [claimed-docs] “Fern Editor lets team members such as content writers, product managers, and marketers update documentation without code, markdown, or Git.”

   proof ↗⚑ flag

Content reuse

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

   weight 1 · round to Docusaurus
   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

   Fern—none0/10

   No evidence in the pack mentions reusable content snippets, includes, or variable substitution for keeping repeated content in sync across pages; Fern's documented features cover Markdown authoring, versions, OpenAPI-based reference generation, and AI features but nothing about reusable snippets/variables.

   ⚑ flag

Quality

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

   weight 2 · round drawn
   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

   Fern—none0/10

   No evidence of any style-guide linting, vale/textlint-style content checks, or pre-publish content quality gates in Fern's docs or CLI; validation features mentioned (fern-docs-1) refer to API definition validation, not prose/style linting. Missing for 10: any mention of prose style-guide rules, linting integration, or automated content-quality checks before publish.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”

   proof ↗⚑ flag

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

   weight 2 · round to Fern
   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

   Fern~partialclaimed4/10

   Fern's CLI is scriptable and machine-readable (every command outputs JSON so it can be piped/chained, fern-docs-34) and generates SDKs in 9 languages from a single spec in one operation (fern-docs-32), and the scheduled Fern Agent can review large sets of reader feedback, unanswered questions, and search queries in a single automated pass (fern-docs-8/25). However, there is no explicit documentation of a bulk/batch API or CLI mode for operating across many discrete items (e.g., mass-editing pages, bulk API endpoint updates) — missing for 10: explicit bulk-edit/batch API commands, evidence of scale limits, and independent confirmation that agents can reliably chain many operations at once.

   • [claimed-docs] “Every command speaks JSON, so coding agents can pipe one call into the next.”
   • [claimed-docs] “Fern generates SDKs in 9 languages from a single API specification”
   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or analytics, report back what it found, and ope…”

   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
   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

   Fern—none0/10

   The evidence pack contains no mention of theme, font, layout, custom CSS/JS, or custom component capabilities for Fern docs — only custom domains, versions, preview, and AI features are documented. As a documentation platform, this axis clearly applies, but there is no evidence Fern supports deep visual/brand customization beyond domain routing.

   ⚑ flag

Git workflow

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

   weight 3 · round to Docusaurus
   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

   Fern~partialclaimed6/10

   Fern's CLI-driven workflow (init, validate, preview, publish) and Fern Agent explicitly 'reads your docs site's source repository and makes the changes you describe,' plus automations that 'open a pull request when the prompt asks for a change,' point to a git-backed, PR-driven docs pipeline. However, the evidence never explicitly documents a CI/CD-style trigger where merging a branch/PR automatically republishes docs, and Fern Editor is marketed as a non-git alternative for content editors, which cuts against a pure docs-as-code narrative. Missing for 10: explicit documentation of branch-based preview/staging tied to PRs, and a described merge-to-publish pipeline (e.g., GitHub Action or webhook) rather than manual CLI publish or Agent-initiated PRs.

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”
   • [claimed-docs] “Fern Agent reads your docs site’s source repository and makes the changes you describe.”
   • [claimed-docs] “You can now put Fern Agent on a schedule... Automations can review your reader feedback, unanswered Ask Fern questions, search queries, or a…”
   • [claimed-docs] “Fern Editor lets team members such as content writers, product managers, and marketers update documentation without code, markdown, or Git.”

   proof ↗⚑ flag

Quality gates

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

   weight 2 · round drawn
   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

   Fern—none0/10

   The CLI reference mentions validating API definitions, but there is no evidence of a CI/CD integration that catches broken links or invalid configuration before publishing (e.g., no GitHub Action, pre-publish link checker, or CI validation step documented).

   • [claimed-docs] “The Fern CLI lets you initialize projects, validate API definitions, preview changes locally, and publish documentation and SDKs.”

   proof ↗⚑ flag

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

   weight 3 · round to Docusaurus
   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

   Fern~partialcommunity5/10

   Fern's content model is built on open formats (Markdown pages, OpenAPI specs for API references, YAML docs.yml config) and the CLI validates/previews/publishes from your own source repo, implying content isn't locked in a proprietary format (fern-docs-22, fern-docs-33, fern-docs-46). However, there is no explicit 'export all your data' feature, no documented bulk-export/backup tool, and the optional 'Fern Definition' language is noted by a community reviewer as an added proprietary layer that doesn't map 1:1 to OpenAPI (fern-comm-2). Missing for 10: an explicit data-export/backup capability, confirmation that Fern Definition and Ask Fern indices/analytics can be exported, and independent evidence of migrating off Fern without friction.

   • [claimed-docs] “Fern supports writing pages in Markdown and generating API Reference documentation from an OpenAPI specification.”
   • [claimed-docs] “Generate a branded, idiomatic command-line interface from your OpenAPI spec.”
   • [claimed-docs] “Fern is an SDK generator and documentation platform that produces idiomatic, type-safe client libraries in nine languages and ke”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Fern✓fullcommunity7/10

   Fern's source is publicly hosted on GitHub (fern-api/fern), and independent community commentary explicitly confirms it is open-source (though commercially licensed/not free), satisfying the ability to read the source. Missing for 10: explicit license file/name (e.g., MIT/Apache) confirmation and first-party docs stating the license terms.

   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Docusaurus
   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

   Fern~partialcommunity5/10

   Fern's docs confirm a self-hosted container option for serving documentation (env var resolution 'on each request' in self-hosted deployments) and community commentary notes Fern is open-source, supporting self-hosting of the core product. However, there is no first-party deployment guide, infrastructure requirements, licensing terms, or independent hands-on confirmation of running the full SDK-generation/docs platform outside Fern's hosted service. Missing for 10: explicit self-hosting setup documentation, infra/licensing details, and independent verification of a full self-hosted deployment.

   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request... so one image serves deployments tha…”
   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request.”
   • [community] “Fern: Notable for being open-source, though not free. It provides a robust end-to-end Developer Experience, covering everything from SDKs an…”
   • [github] “Type-safe SDKs in multiple languages, including TypeScript, Python, Java, Go, Ruby, PHP, and C#”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Fern—none0/10

   No evidence in the pack addresses telemetry collection or an opt-out mechanism for Fern's CLI, docs platform, or SDKs; this is a fair privacy-posture question for a dev-tool/platform but no documentation or community source confirms or denies telemetry opt-out.

   ⚑ 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 Fern
   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

   Fern✓fullclaimed8/10

   Fern's pricing page explicitly lists password-protected docs and visitor authentication with JWT/SSO as features, directly matching the story's requirement for gating docs behind authentication for customers-only content. Missing for 10: no independent/hands-on corroboration or detailed docs page describing configuration steps for these auth methods beyond the pricing page mention.

   • [claimed-docs] “Password-protected docs”
   • [claimed-docs] “Visitor authentication (JWT, SSO)”

   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 Fern
   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

   Fern✓fullclaimed8/10

   Fern's docs explicitly document configuring custom domains as a subdomain (docs.mydomain.com), subpath (mydomain.com/docs), or root domain (mydomain.com), directly matching the story's requirements. Missing for 10: independent/hands-on corroboration beyond first-party docs, and no detail on DNS/setup complexity or edge cases.

   • [claimed-docs] “You can configure any of the following custom domain types: Subdomain: `docs.mydomain.com`, Subpath: `mydomain.com/docs`, Root domain: `mydo…”
   • [claimed-docs] “You can configure any of the following custom domain types: Subdomain... Subpath... Root domain”
   • [claimed-docs] “You can configure any of the following custom domain types”

   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
   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

   Fern~partialclaimed3/10

   Evidence only mentions a 'self-hosted container' that can serve pages with per-request environment variable resolution, implying some self-hosting flexibility, but there is no documentation of exporting the docs site as a plain static HTML/asset bundle deployable to arbitrary static hosts (e.g., S3, Netlify) without Fern's runtime. Missing for 10: an explicit static-export/build-to-static-files feature, confirmation that the exported bundle has no dependency on Fern's hosted infrastructure or container, and independent verification of successful self-hosting outside Fern's ecosystem.

   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request... so one image serves deployments tha…”
   • [claimed-docs] “A self-hosted container can now resolve environment variables in the pages it serves, on each request.”

   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 Docusaurus
   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

   Fern~partialclaimed4/10

   Fern's docs mention a 'search queries' analytics feature and a `search-metadata` frontmatter for customizing search grouping/filtering, implying a built-in site search exists, and Ask Fern provides an AI Q&A alternative with citations. However, there is no explicit claim about typo-tolerance, relevance ranking, or full-site coverage of the search feature itself. Missing for 10: explicit documentation of the underlying search engine's typo-tolerance, ranking algorithm, and independent/hands-on verification of search quality.

   • [claimed-docs] “You can now attach your own key-value metadata to a page with the `search-metadata` frontmatter object... so a custom search integration can…”
   • [claimed-docs] “Ask Fern indexes your documentation and provides an interface for your end users to ask questions and get answers. Responses include citatio…”
   • [claimed-docs] “The tab reports `llms.txt` usage including: Traffic by LLM provider (Claude, ChatGPT, Cursor, etc.)”
   • [claimed-docs] “Track usage in the [Web Analytics tab]”

   proof ↗⚑ flag

Localization

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

   weight 1 · round to Docusaurus
   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

   Fern—none0/10

   The evidence covers versioning (dropdown for multiple releases), custom domains, previews, and SDK/CLI generation, but there is no mention anywhere of localization, translated navigation, multi-language content, or i18n support for docs sites. missing for 10: any mention of localization/i18n, translated navigation menus, language switcher, or multi-locale content management.

   ⚑ flag

Versioning

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

   weight 3 · round to Docusaurus
   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

   Fern✓fullclaimed8/10

   Fern explicitly documents a Versions feature that adds a dropdown selector letting readers switch between multiple releases of the same docs/API content, with each version able to have its own pages, tabs, and API references. This directly matches the story's core need for per-product/version documentation with reader-facing version switching. Missing for 10: independent/hands-on corroboration beyond first-party docs, and no detail on version-specific URL structure or SEO handling.

   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content. Each version can contain its own tabs, sections, pages, and …”
   • [claimed-docs] “Versions add a dropdown to your docs for multiple releases of the same content.”
   • [claimed-docs] “Add a dropdown version selector for multiple”

   proof ↗⚑ flag