Which docs platforms are AI-friendly? We scored seven.
Jamdesk Team
We wanted a measurable number on which docs platforms are AI-friendly, and honestly to see how Jamdesk stacks up against the competition. So we wrote a small Node.js script that probes a documentation software docs site for the things AI crawlers and agents actually care about: server-rendered HTML, a content-to-chrome ratio, discovery files like llms.txt, a .md-endpoint convention, robots.txt posture, and the ratio of repeated boilerplate between pages. Then we layered a manual answer-quality rubric on top, graded by Claude Opus 4.8 against the rendered page text.
Why are these metrics important? The discovery world is changing, with people frequently using AI chat like ChatGPT or Gemini to do their searches. Your docs can't rely on organic Google search alone anymore.
We ran it against seven platforms, including our own. And before the results, we owe you the story of the bug.
We found a bug in our own scorer, and it had us winning
Our first internal draft put Jamdesk tied for first. Hip, hip, hooray! Then one of us actually re-read the script.
The discovery check looked for llms.txt at the bare origin root, https://example.com/llms.txt. That quietly rewards any platform that mirrors its llms.txt to the apex domain and penalizes any platform that serves it from a subpath like /docs/llms.txt. Jamdesk publishes llms.txt at the root and the subpath, so we passed. Mintlify publishes a perfectly good llms.txt (43 KB of it, plus a 1.1 MB llms-full.txt) at mintlify.com/docs/llms.txt. Our script asked mintlify.com/llms.txt, got a 404, and recorded "no llms.txt."
That one false negative cost Mintlify 10 points and dropped them from first to fourth. It's the difference between the draft we almost published and the truth.
So we fixed the probe. It now checks the root and every path segment down to the page it's testing, follows redirects, and verifies the file is real markdown rather than an SPA shell. We re-ran everything on 2026-06-01. The corrected result: Mintlify won, 87 out of 100. Jamdesk tied ReadMe.com for second at 85.
We build Jamdesk, documentation software designed around AI-readable output, and the honest version of this comparison is we don't win today. The mechanical signals come from a single open-source Node.js script at github.com/jamdesk/docs-ai-scorer (the fixed version). The point weighting is the mapping described in the next section, and Answer Quality is a manual grade by Claude Opus 4.8 against the rendered page text. The raw signals are below, not just the rankings. If your numbers come out different, the README has a one-click way to submit a counter-run.
The lesson for anyone building a benchmark: the first time your own tool says you're winning, that's exactly when to go re-read the code and re-check everything.
What we measured
The scoring formula has five dimensions, weighted to a 100-point total:
- Crawlability (25). Does the page server-render its content?
ssrPassis worth 15 points: a non-empty<h1>, at least two visible headings, and more than 500 characters of stripped text. The remaining 10 come fromtextRatio(stripped text bytes ÷ total HTML bytes) on a tiered scale. - AI Discovery (25).
llms.txtworth 10 (eitherllms.txtorllms-full.txtpresent, found at the root or a subpath; we count them as one signal because shipping one is essentially the same architectural decision as shipping the other), a per-page.mdcompanion endpoint worth 12,sitemap.xmlworth 3. - Robots Policy (10). Fraction of the major AI crawlers (GPTBot, ClaudeBot, Claude-Web, PerplexityBot, Google-Extended, CCBot) not explicitly disallowed at root.
- Context Noise (15).
(1 − page1NoiseRatio) × 15. Noise ratio is the byte overlap between two pages on the same site, chunked at 200 bytes. High overlap means most of the page is sidebar, header, and footer rather than content. - Answer Quality (25). Five questions from a developer onboarding flow, graded 0-3 each: what is the product, how do I get started, do I need an account, where's the feature/command list, where do I get help. The grader (Claude Opus 4.8) saw only the rendered page text, no follow-up fetches, no web search.
These five dimensions are basically a proxy for one question: can an agent fetch, parse, and trust your docs without executing the page's JavaScript?
The full script is at the bottom of this article. It's about 200 lines with no dependencies, and runs on plain Node 20+. It emits the raw signals; the point values above are how we map those signals to a score, and Answer Quality is the one manual step.
Results
Listed alphabetically. Totals are in the rightmost column. Tested 2026-06-01 against each platform's own docs site.
| Platform | Crawl /25 | Discovery /25 | Robots /10 | Noise /15 | Answer /25 | Total /100 |
|---|---|---|---|---|---|---|
| Document360 | 0 | 10 | 10 | 12 | 10 | 42 |
| Docusaurus | 22 | 3 | 10 | 15 | 15 | 65 |
| GitBook | 15 | 25 | 10 | 14 | 18 | 82 |
| Jamdesk | 15 | 25 | 10 | 15 | 20 | 85 |
| Mintlify | 15 | 25 | 10 | 15 | 22 | 87 |
| ReadMe.com | 15 | 25 | 10 | 15 | 20 | 85 |
| Stripe (raw MD on GitHub) † | 10 | 0 | 10 | 15 | 7 | 42 |
† Stripe's ARCHITECTURE.md is a contributor-facing internals doc served raw from GitHub. We include it as a "raw markdown, no platform" baseline, not as a fair comparison to the user-facing onboarding pages used for the other six. Rerunning against README.md would lift its answer-quality score.
Top of the table: Mintlify at 87, then Jamdesk and ReadMe.com tied at 85, then GitBook at 82. Four platforms sit within five points of each other. Mintlify wins on the best content in the test. More on that below.
Raw signals (for audit)
| Platform | ssrPass | textRatio | llms.txt | location | .md | sitemap | noiseRatio | answerQ /15 |
|---|---|---|---|---|---|---|---|---|
| Document360 | false | 0.001 | yes | subdomain root | no | no | 0.203 | 6 |
| Docusaurus | true | 0.132 | no | — | no | yes | 0.003 | 9 |
| GitBook | true | 0.016 | yes | subdomain root | yes | yes | 0.038 | 11 |
| Jamdesk | true | 0.030 | yes | root + subpath | yes | yes | 0.005 | 12 |
| Mintlify | true | 0.008 | yes | subpath (/docs/) | yes | yes | 0.015 | 13 |
| ReadMe.com | true | 0.016 | yes | subdomain root | yes | yes | 0.004 | 12 |
| Stripe (raw MD on GitHub) | false | 0.996 | no | — | no | no | 0.000 | 4 |
The location column is the thing the bug was hiding. Five of the seven ship llms.txt. All five are real, spec-compliant files. The only difference is where they live.
Mintlify earned first place on content
Mintlify scored 13 out of 15 on answer quality, the highest in the test. Its quickstart explains what the product is, how to deploy, and how to authenticate, with explicit instructions and numbered steps. The writing is good, and it's why Mintlify tops the table even though it's tied with three other platforms on every mechanical signal.
It also ships everything an AI crawler wants: server-rendered HTML, a .md endpoint, a sitemap, and both llms.txt and llms-full.txt. Our broken draft said the opposite.
The top four are separated by content, not infrastructure
The corrected table tells a plainer story. GitBook, Jamdesk, Mintlify, and ReadMe.com all ship the full discovery picture (llms.txt, llms-full.txt, and a per-page .md companion endpoint) on server-rendered HTML, with every AI bot allowed. The infrastructure layer is settled among the leaders. What separates them is answer quality, measured in single rubric points.
That makes the gaps small and a little fragile. Jamdesk and ReadMe.com tie at 85 because they match bit-for-bit on Crawlability, Discovery, Robots, and Noise, and land on the same answer-quality score (12/15). Mintlify pulls ahead by one rubric point on a single onboarding question. A one-point swing on the 15-point rubric is a 1.67-point swing on the 100-point total, small enough that a different set of grading questions could reorder the top four.
Update, 2026-06-01: Jamdesk shipped a clearer support pathway into the quickstart after an earlier run flagged it as our weakest answer. We're noting that rather than re-grading inline, because re-running a rubric on a fix made by the team that owns the rubric isn't cool. The next full re-run re-grades every platform, not just ours.
Where Jamdesk does have an edge
Tied for second isn't first, and we won't dress it up. But two of Jamdesk's signals are the best in the field, and both matter to an agent.
Leanest HTML of the hosted leaders. Among the four platforms at the top, Jamdesk's textRatio of 0.030 is the highest: 0.016 for GitBook and ReadMe, 0.008 for Mintlify, roughly 3.7× more content per byte than Mintlify. (Docusaurus and the raw GitHub file score higher still on this one signal, but they're a static-site generator and a single markdown file, not hosted platforms, and they pay for it elsewhere.) When an agent fetches the HTML version of a Jamdesk page, about 3% of what it downloads is content; for Mintlify it's 0.8%. The .md endpoint sidesteps this. Fetching jamdesk.com/docs/quickstart.md returns about 6 KB of clean markdown instead of roughly 200 KB of HTML. Not every agent asks for the .md view, though, and the ones that fall back to HTML pay the token bill.
llms.txt where an agent guesses it. Jamdesk serves llms.txt at the root path /llms.txt (the location the llms.txt spec names first) and at the docs subpath. Mintlify serves a great file, but only at /docs/llms.txt; an agent that requests the bare mintlify.com/llms.txt gets a 404. The spec explicitly permits subpaths, so this is a discoverability nuance, not a deficiency. It's a real one, though, and it's one redirect away from being closed.
Neither edge earns points the rubric currently awards: the textRatio tier doesn't separate 0.030 from 0.008, and we score llms.txt on presence, not location. We're flagging them as honest observations, not a thumb on the scale. Re-weighting the rubric now, after seeing the results, to turn these into a Jamdesk win would be exactly the move this whole post is the opposite of.
About the weights
We picked the weights, and we tried to be fair. Discovery at 25 and Answer Quality at 25 reflects our judgment that AI agents need both a way to find canonical content and content that actually answers things. If you disagree, you can change the weights in the script and run again.
One adjustment we made up front: llms.txt and llms-full.txt count as a single 10-point signal, not two. They're highly correlated (every platform that ships one ships the other), so counting them separately would double-count one architectural decision. We ship both and like them both; we don't think we should be rewarded twice for that.
The same signals under a few other schemes:
| Scheme | Crawl | Disc | Robots | Noise | Answer | Top platform |
|---|---|---|---|---|---|---|
| Current (ours) | 25 | 25 | 10 | 15 | 25 | Mintlify (87) |
| Content-heavy | 20 | 15 | 5 | 10 | 50 | Mintlify (wider lead) |
| Extractability-heavy | 40 | 20 | 5 | 20 | 15 | Docusaurus closes on the leaders |
Mintlify wins our default and the content-heavy view; Docusaurus closes the gap if you mostly care about raw extractability. Pick the weighting that matches what you need. The script outputs the raw signals, and re-weighting just means changing the point values listed above.
Document360 served 1.05 MB of HTML for 1.3 KB of text
This is the strongest negative finding in the test, and the bug fix didn't touch it. We requested docs.document360.com/docs/getting-started. The response was 1,049,919 bytes of HTML. The stripped-text content was 1,279 bytes. That's a textRatio of 0.001, the worst we measured.
The reason is client-side rendering. The HTML is a thin SPA shell that defers all content to JavaScript. The body of the article isn't in the response at all. An AI crawler reading this URL with plain HTTP sees navigation chrome and a loading spinner, nothing more.
Document360 does ship an llms.txt (credited with 10 points), which lifts its corrected total from the broken draft's 32 to 42. But the rendering choice still produces the lowest crawlability score in the test (0/25) and the highest noise ratio (20.3% repeated boilerplate). For a hosted platform customers pay for, the rendering pipeline is something the vendor controls and the customer can't fix. That's the part worth watching.
Raw markdown on GitHub beats a CSR platform on extractability, loses everywhere else
We included Stripe's ARCHITECTURE.md as a baseline: a plain markdown file served from GitHub's raw endpoint, which has no platform or chrome and is just plain text. It scored 42, tied with Document360 on a completely different profile. ssrPass is false (no HTML document at all), and the file has no llms.txt, no sitemap, no .md-endpoint convention (it already is .md, with no parallel HTML view to compare). But its textRatio is 0.996 and its noise ratio is zero. Answer quality cratered at 4/15 because ARCHITECTURE.md is a contributor doc, not an onboarding page. The takeaway isn't "ship raw markdown." It's that the floor for a real platform should sit higher than a single file, and four of them clear it comfortably.
Robots.txt didn't discriminate
Going in, we expected at least one platform to block AI bots. Not one did. Every platform we tested allows GPTBot, ClaudeBot, Claude-Web, PerplexityBot, Google-Extended, and CCBot at the root path:
- Document360: all allowed
- Docusaurus: all allowed
- GitBook: all allowed
- Jamdesk: all allowed
- Mintlify: all allowed
- ReadMe.com: all allowed
- Stripe (raw MD on GitHub): no robots.txt on the raw-content host, so unrestricted by default
Every platform scored the full 10/10: the six hosted platforms by explicitly allowing the crawlers, the raw GitHub file by having no robots rules to apply. The robots layer is effectively settled in the crawler's favor. The interesting decisions are happening one layer up, at the format and discovery layer.
What this test gets wrong
Some of these we can defend. Some we can't. All of them could change the rankings.
We shipped a scoring bug. The headline correction in this post exists because v1.0 of our own script checked llms.txt at the wrong location. We caught it before publishing, but only barely, and only because the buggy result happened to flatter us. If a metric ever ranks its author first, that's the metric to audit hardest. The fixed probe is in the script below; the diff is in the repo.
We picked the test pages. For each platform we chose one "deeper" content page (usually the quickstart) as the primary URL. Different page choices yield different scores.
Rubric questions are arbitrary. "What is this product? How do I start? Where do I get help?" is a sensible developer-onboarding rubric, but it's one of many. Swap in "What's the rate limit? How do I authenticate? Where are the error codes?" and the platforms with strong API reference pages (Mintlify, ReadMe) probably extend their leads.
Tiny phrasing differences flip the rubric. A one-point swing on a 15-point rubric becomes a 1.67-point swing on the total. The top four are close enough that this matters: the Jamdesk/ReadMe tie and Mintlify's one-point lead all live inside that margin.
We didn't include obvious other platforms. Sphinx / Read the Docs, MkDocs Material, Hugo, Astro Starlight: none of these are in the test. We picked seven because they're the ones we get asked to compare against. A wider sweep would probably surface more platforms in the 70–85 range and compress the leaderboard.
The noise ratio is fragile. We hash 200-byte chunks and count exact overlap. A single-byte difference (a request ID, a hashed asset URL, a timestamp) kills a match. Real shared chrome may be several times what we measured; the Docusaurus number (0.003) is probably under-counting.
If you maintain one of these platforms and any of the above changes your numbers, we want the reproduction. That's what the GitHub issue template is for.
Take Aways
Which docs platform is most AI-friendly? On our 100-point rubric, Mintlify scored highest at 87 on June 1, 2026, on the strength of the best onboarding content in the test. Jamdesk and ReadMe.com tied for second at 85, and GitBook followed at 82. All four ship llms.txt, llms-full.txt, and a per-page .md endpoint on server-rendered HTML. Different weight schemes reorder the top four; see "About the weights." Re-run the script before you trust any of these numbers.
Does my docs platform need llms.txt? Yes, if you want AI agents to find canonical content without crawling sidebars and footers. llms.txt is a small markdown file pointing at high-value pages; llms-full.txt is a single-file bundle of your docs in plain markdown. The spec names the root path /llms.txt first but explicitly allows a subpath. Wherever you put it, link to the .md views of your best pages.
Is server-side rendering required for AI to read my docs? Effectively yes. Most AI crawlers fetch plain HTTP and don't execute JavaScript. If your content only appears after hydration, the crawler sees an empty shell. That's why Document360 scored 0 on crawlability while serving 1.05 MB per page.
What is the .md endpoint convention? Append .md to a docs URL and get back the plain markdown source. Mintlify, GitBook, ReadMe.com, and Jamdesk all support it. An LLM fetching docs/quickstart.md gets clean markdown instead of a few hundred KB of HTML chrome.
Are AI crawlers blocked from any docs platform? Not in our test. The six hosted platforms allow the major AI crawlers (GPTBot, ClaudeBot, PerplexityBot, and others) at the root, and the raw GitHub file has no robots.txt at all. The interesting decisions are happening at higher layers: rendering pipeline, discovery files, and content structure.
How do I run the docs-ai-scorer script? Clone github.com/jamdesk/docs-ai-scorer, then run node score-docs.mjs <name> <page1-url> <page2-url>. You'll get one line of JSON. Two URLs from the same site let the script compute the noise ratio.
Limitations
A few things this test does not cover, and one place where it was wrong.
It was wrong once already: the llms.txt probe bug described up top, which is exactly the kind of error an open script is meant to expose. We caught this one ourselves. The next one might come from a counter-run, and that's fine.
We didn't test the writing UX of any platform. We didn't run Cursor or agent loops, just Claude Opus 4.8 as a grader on rendered HTML. JavaScript-discovered content (Algolia, Mendable, in-page search) is invisible to this test by design, because it's also invisible to most AI crawlers. But if your customers reach docs through an in-app agent that executes JS, the picture changes.
We fetched every page with a generic browser-style User-Agent (docs-ai-scorer/1.1), not with GPTBot or ClaudeBot. Some platforms serve different HTML based on UA. We'll add a real AI-bot pass in v2 and report deltas.
If you only do one thing this week
Ship an llms.txt. It's about a dozen lines, takes ten minutes, and it's the single cheapest move on this entire rubric. Even Google is now considering llms.txt files in Google Lighthouse scores.
Put it at /llms.txt (and mirror it to your docs subpath if your docs live there), then link to the .md views of your highest-value pages. Below is the shape Jamdesk uses:
# Jamdesk Docs
> Jamdesk is documentation software that publishes AI-readable output by default.
## Getting started
- [Introduction](https://jamdesk.com/docs/introduction.md): What Jamdesk is and how it fits.
- [Quickstart](https://jamdesk.com/docs/quickstart.md): Two files and a GitHub repo.
- [How Jamdesk Works](https://jamdesk.com/docs/how-jamdesk-works.md): The full build-to-live pipeline.
## CLI
- [CLI Overview](https://jamdesk.com/docs/cli/overview.md): Local preview, validation, deploy.
## AI
- [llms.txt](https://jamdesk.com/docs/ai/llms-txt.md): How Jamdesk auto-generates the discovery files.
- [MCP Server](https://jamdesk.com/docs/ai/mcp-server.md): Every site ships an MCP server.
Drop it at /llms.txt, link to the .md views of your highest-value pages, and you're done. The .md-endpoint convention is the part that requires platform support. Server-side rendering takes work, cutting boilerplate noise takes design discipline, and writing a quickstart that answers five questions cleanly is its own craft. As this test shows, that last one is what separates the leaders. But shipping llms.txt is a Tuesday afternoon.
Epilogue: we took our own advice
Writing this post handed us a to-do list. The rubric graded Jamdesk's quickstart 12 out of 15 on answer quality. That one point was the gap to Mintlify, and the rubric was specific about where it went: three of the five onboarding questions lost points: where to get help, what the product actually is, and where to find the full command and feature list.
So we fixed all three in our own docs:
- Where do I get help? A dedicated "Need Help?" section: Help Center, live chat, and a support email. (This was the first fix, mentioned earlier.)
- What is this product? The quickstart now opens by stating what Jamdesk is in one line, instead of jumping straight to deployment steps.
- Where's the feature/command list? A new "Full Reference" section points to the component, CLI, and
docs.jsonreferences in one place.
The changes are live and the diff is public: jamdesk-docs@989ae5d, rendered at jamdesk.com/docs/quickstart.
The result: On a like-for-like re-grade (our own, which is exactly why it doesn't count yet), those three answers reach 3/3 each: 15/15 on answer quality, or 90 out of 100, ahead of Mintlify's 87.