Last updated:
The llms.txt playbook for devtools companies: what Stripe, Neon, and Supabase get right (and wrong)
Buried inside Stripe’s llms.txt is a section almost no other major API company has shipped: direct instructions telling AI agents which of Stripe’s own APIs not to recommend.
“Never recommend the legacy Card Element…” “…never recommend the Charges API.” “You must not call deprecated API endpoints such as the Sources API…”
Stripe isn’t just making its docs machine-readable. It is programming what AI tools say about Stripe, on purpose, in a plain text file anyone can read.
Most companies with an llms.txt haven’t done anything close to that. Supabase, a company built around AI-assisted development, ships an llms.txt that is a flat list of doc links with no instructions section, no schema markup, and no MCP server, gaps an independent agentic-readiness audit catches directly.
A good llms.txt is more than the file itself. It curates a structured index instead of dumping every page, tells agents what to avoid where a product has real traps, and sits inside a small set of machine-readable signals, an MCP server, a full-text sibling, content negotiation, that most companies never build. Seven checkable signals separate the companies doing this well from the ones checking a box, and you can score any file against all seven, including your own, by the end of this post.
One more note before the case studies: every file quoted, scored, or linked below reflects what was live in early August 2026. These files change quickly, Stripe’s grew mid-writing this very piece, so treat the specifics as a snapshot and use the seven signals to check the current state yourself.
What does Stripe’s llms.txt do that almost nobody else does?
Stripe has fifteen years of API surface area, including several generations of deprecated payment primitives. The Charges API still works. The Card Element still exists. Developers, and the AI assistants helping them, keep reaching for these older APIs because they show up in old Stack Overflow answers and pre-2022 training data.
As of this writing, docs.stripe.com/llms.txt includes this:
## Instructions for Large Language Model Agents: Best Practices for integrating Stripe
Stripe's primary backend object for payments is the Checkout Sessions API,
which now works with the Payment Element. Prioritize the Checkout Sessions
API, including if a user wants to use Payment Element, and never recommend
the Charges API. [...]
Never recommend the legacy Card Element or the Payment Element in card mode,
and advise users who ask for the Card Element to migrate.
You must not call deprecated API endpoints such as the Sources API and avoid
outdated API endpoints such as Tokens and Charges unless there is a specific
need and absolutely no other way. [...]Confirmed live on that URL as of August 8, 2026. Worth noting since it makes the point for us: this section has grown since it was first reported on in February, Stripe rewrote it from a short bullet list into fuller prose and expanded it to cover Stripe Connect too. These files are not static.
That’s not documentation, it’s a prompt shipped as a static file, designed to load into an AI coding assistant before a developer even asks how to add Stripe. As reported by Apideck, Stripe engineer Ian McCrystal put it plainly: “I expect AI tools will eventually become the predominant readers of our documentation.” Co-founder John Collison, on the same shift: “If you go read the Stripe Docs these days, it’s a lot to keep in your RAM, but trivial for an LLM.”
Stripe pairs this with something equally deliberate: error responses that include a doc_url field pointing straight to the relevant docs page in Markdown. When an agent hits a 400, it can follow that link, read the page, and self-correct without a human in the loop.
Anthropic’s own llms.txt, by comparison, is a clean, navigable index. It just isn’t doing this active correctional work.
Most companies treat llms.txt as a sitemap for bots. Stripe treats it as an active mechanism for steering model behavior. Almost nobody else has copied the second part yet.
Why does “index, not a dump” matter, and who actually rebuilt theirs that way?
Neon, the Postgres-as-a-service company, wrote up their own multi-phase evolution of this problem in detail. Their first llms.txt was hand-generated by asking an AI for “one of them cool llms.txt things,” and it produced a flat list of over 1,000 URLs. It drifted from the source, went stale for weeks at a time, and nobody noticed until it mattered.
Their own words on what they’d fix first if starting over: “The index needs structure, not just a list.” Their current llms.txt is a primary index of roughly 200 entries, organized into sections like Get Started, Connect, AI & Agents, and Branching, each with sub-indexes for the pages that don’t fit in the main file. A “Common Queries” section sits at the top: pricing, connection troubleshooting, the API reference, the three things developers actually ask for first.
Neon didn’t stop at their own file. They built a scanner and ran it against 250-plus documentation sites, including Vercel, Stripe, Mintlify, Sentry, and Google, to see how the industry actually handles agent traffic. The findings are the closest thing to real data this topic has:
- 93% of sites have an llms.txt. Only 58% also publish an llms-full.txt.
- 53% serve a Markdown version of a page by appending
.mdto the URL. - Only 9% return Markdown, correctly, on a 404 when Markdown was requested. Most return HTML regardless of what the agent asked for.
- Only 9% include a discovery hint (a
<link rel="alternate" type="text/markdown">tag) in their HTML.
Vercel’s version of the same instinct is simpler: llms.txt as the table of contents, llms-full.txt as the whole book. Vercel’s Lee Robinson announced it this way: “vercel.com/docs/llms.txt is now live. We also have the full version if you want to read a 400,000 word novel.”
What does getting this half right look like?
Supabase is the useful counter-example precisely because it should be the best-prepared company on this list. Its whole pitch is AI-assisted app development. Its llms.txt is live, and it is entirely a flat list:
# Supabase Docs
For the complete documentation in a single file, see Full Documentation.
## Documentation
- Supabase - AI & Vectors
- Supabase - AI Tools
- Supabase - Data REST API
...No blockquote pitch beyond the title. No scope section. No instructions. An independent agentic-readiness scan (Not Human Search) puts Supabase at 45 out of 100: llms.txt found, a structured API found, but no ai-plugin.json, no OpenAPI spec surfaced, no schema.org markup, and no MCP server detected.
To be fair to Supabase, the minimalism buys something real. The file itself is small, cheap for an agent to fetch and parse, and it hands over a clean menu of categories, AI & Vectors, Auth, Database, Storage, and so on, that a human or agent can scan in seconds before choosing where to go deeper. That’s a real strength, not a weaker version of a good file. What’s actually missing is a one-line pitch up top and an instructions section calling out what to avoid, not size.
Having an llms.txt is table stakes now, 93% of sites in Neon’s scan already have one. The gap between a middling score and a strong one is never the presence of the file. It’s whether the file, and the signals around it, actually tell an agent something more than a menu.
Why is this a PMM problem, not just an engineering ticket?
Every example above reads like an engineering decision: a text file, a middleware check, a header. Filed as an engineering-only backlog item, it stays invisible until it costs you something.
Stripe’s instructions section is a positioning move. It decides, at scale, what an AI assistant tells a developer about Stripe before that developer forms an opinion of their own. That’s the same job a PMM does in a sales conversation or a comparison page, just running automatically, thousands of times a day, without anyone in the room.
Supabase’s score is the same kind of signal a competitive battlecard already tracks: a feature gap, a pricing gap, an integration gap. Agentic readiness is now one more column. Score two or three competitors the way Not Human Search scored Supabase before your next launch review, the same way you’d already check their pricing page.
Three places this belongs on a PMM’s desk, not only engineering’s:
- Launch checklists. Add “llms.txt reviewed and current” and “error responses link to fetchable docs” next to the usual pre-launch items. It’s cheap to add, and it’s the kind of gap nobody catches until a customer’s agent gets it wrong in front of them.
- Competitive positioning. A real agentic-readiness number is a sharper differentiator than “we’re AI-native” on a slide, and it’s checkable by anyone who reads the battlecard.
- Messaging discipline. Don’t call a static markdown file “agentic.” Stripe’s instructions section works because it does one specific, verifiable thing. Overclaiming here is the fastest way to get called out by the exact developer audience you’re trying to reach.
Who actually reads any of this?
The honest caveat: no major AI provider has confirmed that its training crawlers automatically fetch llms.txt. Its real value today is inference-time, not training-time, a developer’s coding assistant loading it for project context, or an agent framework fetching it on startup.
That inference-time audience is bigger than it sounds, and growing fast. Mintlify’s July 2026 traffic report puts agent requests at 66% of measured traffic across the docs sites it hosts, up from 15.2% at the start of the year, with agent share projected to reach close to 90% by year-end. A separate 2,400-run benchmark from the same data found that linking an llms.txt cut agent error rates by close to 90% compared to plain HTML.
Of the 800,000-plus “implementations” tracking tools like BuiltWith report, most are Yoast SEO auto-generating the file for WordPress sites. The number of hand-curated, real implementations is closer to 784 verified sites.
Neon’s scan adds a detail most guides miss entirely: agents don’t identify themselves the way you’d expect. Looking at their own traffic, Neon saw axios, got, and node-fetch as often as named bots in the user-agent string. Claude Code uses axios. Cursor uses got. If your detection logic only looks for “GPTBot” or “ClaudeBot” by name, you’re missing most of the actual traffic.
The seven signals: score any llms.txt in five minutes
Seven things separate a working llms.txt from a decorative one. Run any company’s file against all seven, including your own:
- A one-line identity pitch. A real blockquote a model could quote back verbatim, not just a title. Stripe and Neon both open this way. Supabase’s file starts straight into a documentation list, no pitch at all.
- Structure, not sprawl. Sections with real descriptions and sub-indexes for anything too large for the main file. Neon rebuilt around this after their first version was a flat list of 1,000-plus URLs. Supabase’s current file is still that flat list.
- Named traps. An instructions section that says what not to recommend, not just what to. Stripe is the clearest published example of this. Almost nobody else has copied it yet, not Neon, not Supabase, not Anthropic.
- A full-text sibling. An llms-full.txt, or equivalent, for an agent that wants everything in one fetch instead of following links one at a time. Vercel, Neon, and Supabase all publish one.
- An MCP server, not just a file. Stripe and Neon both ship one. Not Human Search’s scan flagged Supabase specifically for having none, alongside no OpenAPI spec surfaced and no schema.org markup.
- Content negotiation, not just a static URL. Serving Markdown when an agent asks for it, appending
.mdor honoringAccept: text/markdown, with a discovery hint in the HTML so an agent finds out the option exists at all. Neon’s own scan of 250-plus sites found only 9% get the discovery-hint part right. - A copy-paste setup block, up front. Runnable commands an agent can execute before it reads another line: install the CLI, install the skills, add the MCP server config. Netlify’s llms.txt leads with exactly this,
npm install -g netlify-cli, thennpx skills add netlify/context-and-tools --skill '*' --yes, then a ready-to-paste MCP server block, all before a single doc link. Most companies bury this three clicks into a separate onboarding guide, if they have it at all.
Seven for seven puts you closer to Stripe and Netlify than to Supabase. Miss more than two or three and an agent working with your file has less than it should.
Where doesn’t any of this help?
It won’t get you cited by general AI search the way strong content and real backlinks do. It doesn’t replace robots.txt or a sitemap, both still do their own job. It has no confirmed effect on classic search rankings, this is a GEO and AEO play, not an SEO one. And per the caveat above, only a fraction of the sites that have one have actually built it with intent rather than auto-generating it and forgetting it exists.
FAQ
Do AI crawlers actually read llms.txt?
No major AI provider has confirmed its training crawlers fetch it automatically. What reads it today is inference-time: coding agents and retrieval agents fetching it when a user points them at a site or a task triggers a live fetch. Most of the 800,000+ implementations tracking tools count are auto-generated and never read by anyone; hand-curated real implementations are closer to 784 sites.
What is the “instructions section” Stripe uses?
A block in Stripe’s llms.txt that tells AI agents specifically which of Stripe’s APIs to recommend and which deprecated ones to avoid, for example steering agents toward the Checkout Sessions API and away from the legacy Card Element. It turns the file from a passive index into an active correction mechanism for outdated training data.
What’s the difference between llms.txt and llms-full.txt?
llms.txt is a curated index, organized links by intent with short descriptions. llms-full.txt is the entire site’s content concatenated into one file, meant for an agent that wants full context in a single fetch. Vercel, Neon, and Anthropic all publish both.
Is llms.txt required for SEO?
No, it has no confirmed effect on classic search rankings. It is a GEO and AEO play, aimed at how agents and AI answer engines read and cite a site, not at Google’s ranking algorithm.
Why should product marketing care about llms.txt, not just engineering?
Because it shapes what an AI assistant tells a developer about a product before that developer forms their own opinion, the same job positioning and messaging already do. It also produces a checkable number (an agentic-readiness score) that belongs in competitive battlecards and launch checklists, not just a docs backlog.
Learn from Stripe, Neon, and Vercel. Read Anthropic’s as a clean index without the correction layer, and Netlify’s for the copy-paste setup block. Then run the seven signals against Supabase’s and see how many it actually clears before you score your own.
The pattern holds across all of them: curate like an index, name your traps if you have them, and tell an agent what not to cite you for, not just what to.
Anil Kumar Krishnashetty is a Senior Technical Product Marketing Manager at Bright Data in Berlin, writing about developer experience and go-to-market in the agent era. More on this beat: the install command is no longer your most important CTA.