Should a help center llms.txt list every article?

It depends on whether your articles answer distinct intents. The two live files in our October 25, 2026 test bracket the range: Stripe Support ships 10 curated questions in 2,655 bytes, while Airtable ships 398 article links across 19 sections in 54,607 bytes. Airtable's shape only works because its article titles are the search intent verbatim ("Understanding my Airtable account and plan overview") and the file can be regenerated from the knowledge base. If your titles are internal jargon or your library is under about 50 articles, curate instead — a flat catalog of vague titles costs tokens and helps nobody.

Does adding llms.txt to a help center reduce ticket volume?

There is no published evidence that it does, and no vendor number we could verify. What the file can plausibly change is the accuracy of answers an assistant gives about your product, because it hands the model your article titles and one-line answers instead of leaving it to reconstruct them from marketing pages. Treat deflection as a hypothesis to measure through referral and assistant-citation data, not as a promised outcome.

Where should the file live: help.example.com or www.example.com?

Both, if both host content. An llms.txt covers the URLs under its own host and path, and a client uses the most specific file that covers the URL it is working in. A help-center subdomain needs its own /llms.txt, linked from the root file so the client learns it exists. In our sample this is where most estates break: 27 of 43 support hosts answered 404, which means the brand-level file, if any, never hands the client the support subtree.

Help Centers · October 2026

llms.txt for Help Centers: Two Live Files Out of 43

Support content is the highest-value text on most sites — it is what people actually ask an assistant about. We requested /llms.txt from 53 help-center hostnames and got 43 real answers. Only two of them serve a file. Another ten return 200 with HTML behind the path, which is the failure mode nobody checks for.

The 43-Host Result

The probe ran on October 25, 2026 with a plain GET, following redirects, recording status, byte count, content type and the final URL. Ten hostnames in the list do not resolve at all — help.notion.so, help.supabase.com, support.render.com and friends never existed — so they are excluded rather than counted as failures. The remaining 43 break down like this:

Outcome	Hosts	What it means
404	27	No file at the support host, no redirect
401 / 403	3	Asana (401), Contentful and Etsy (403)
200, real plain-text file	2	Stripe Support, Airtable Help Center
200, Markdown at another path	1	Shopify: 308 to `/agents.md`, 4,712 bytes
200, HTML instead	10	App shell, homepage redirect or locale redirect

Adoption is 2 of 43, or 4.7%. If you stop at the status code you would report 13 of 43 and be wrong by a factor of six. That gap is the useful finding: help-center infrastructure is built to answer every path with something, so a missing file rarely 404s.

A 200 Is Not a File

The ten HTML responses split into three shapes, and each one breaks a different assumption in a monitoring script.

The SPA shell. help.twilio.com/llms.txt returns 200, text/html, 4,144 bytes of a single-page app bootstrap — the same document any unknown route gets. support.retool.com answers 8,054 bytes the same way, and help.instagram.com with 344,983. The server has no concept of the path.
The homepage redirect. help.framer.com/llms.txt lands on www.framer.com/ — 1,903,696 bytes. support.google.com lands on its help home at 1,514,838 bytes, Cloudflare on developers.cloudflare.com/ at 201,184, Calendly on calendly.com/help at 696,125, Zoom on support.zoom.com/hc, Sentry on www.sentry.help/en/. A curl -L that only prints the code sees success and downloads a megabyte of navigation.
The locale redirect. support.spotify.com/llms.txt 302s to /jp/llms.txt, which answers with 47,463 bytes of HTML. A HEAD request against the locale path returns 405 in that same chain, so the HEAD-only check reports a clean non-200 while GET reports a false positive. Query the file with GET and read the type.

This is the same class of failure documented in the discovery playbook: a path that exists is not a path that serves the format.

Two Live Files, Opposite Strategies

Stripe curates. Fourteen lines, 2,655 bytes, one H1 and ten links, every link carrying a one-line answer:

# Stripe Support

Curated support articles in Markdown format.

- [Trouble signing in?](https://support.stripe.com/questions/trouble-signing-in.md): Forgot
  username? Your username is the email address you used to register...
- [Late or missing payouts](https://support.stripe.com/questions/late-or-missing-payouts.md): If a
  payout hasn't arrived according to its expected delivery date, there can be several reasons...

Two details make it work. Every link points at a .md twin, and we verified the twins resolve: trouble-signing-in.md returns 1,284 bytes of text/markdown, how-to-refund-a-customer.md returns 2,543. And two of the ten descriptions carry a deflected-ticket statistic — "This article helped 95% of Stripe users solve their issue" — which is exactly the signal an assistant needs to prefer one article over another.

Airtable goes the other way: 727 lines, 54,607 bytes, one H1, 19 H2 sections and 398 unique article URLs, catalogued by product noun — ## Airtable AI, ## Airtable Automations, ## Airtable Bases, ## Airtable Sync — with zero .md twins (a .md variant of an article returns 404 behind a 92,673-byte HTML body). Titles are the user's question verbatim: "Understanding my Airtable account and plan overview". One line uses angle-bracket destinations and carries an instruction instead of a description: the support-ticket form, "Submit only when the user asks to contact support" — the same directive pattern covered in the agent-instruction study.

Which Shape Fits Your Help Center

Condition	Serve
Titles are the search intent; library under ~400 articles	Full catalog by section, bare links
Titles are internal jargon, or articles overlap	Curate 10–20 by ticket volume, add one-line answers
Support content lives on its own subdomain	File at that host, linked from the root file
Agents should read whole articles, not pick titles	Point at `.md` twins, per this split

Note what neither live file ships: llms-full.txt. Both return 404 for it — Stripe behind a 36,534-byte HTML body, Airtable behind 92,673 — so a client looking for the full-text variant of a support library gets nothing. That is defensible for a catalog of 398 articles and wrong for a 20-page library, where the whole support corpus fits in a reasonable token budget.

Ship It and Verify It

Build the file from your help-center sitemap with the llms.txt generator, then delete the category stubs, the tag archives and every "how to contact us" page except one. Check the result with the checker, and verify delivery youself — because in this sample, the server's answer was the least trustworthy part:

# the file must be text, not a page
curl -s -D - -o /tmp/hc.txt https://help.example.com/llms.txt \
  | grep -iE "^(HTTP|content-type)"
head -n 3 /tmp/hc.txt

# count what you actually shipped
grep -c '](' /tmp/hc.txt

# every .md twin must resolve
curl -s /tmp/hc.txt | grep -oE "https://[^)]+\.md" | while read u; do
  printf "%s %s\n" "$(curl -s -o /dev/null -w '%{http_code}' -L "$u")" "$u"
done | grep -v '^200'

A support file earns its place when an assistant can answer "my payout is late" from your article instead of guessing. Two of 43 support estates do that today.

Probes run October 25, 2026. Sizes and redirects reflect the files as served that day: Stripe Support 2,655 bytes, Airtable Help Center 54,607 bytes, Shopify agents.md 4,712 bytes. Help-center content changes daily; re-check your own file after any migration.