我審查了 70 家公司的 llms.txt 檔案，大多數沒有
每個人都在寫 llms.txt 教學，但沒人去檢查這些公司到底做了沒。我對 70 個理應有 llms.txt 的網站做了實測——AI 實驗室、文件平台、開發基礎設施巨頭、大型 SaaS——只有 31 家有真檔案。31 家裡又有 12 家不符合社群自己定義的格式。下面是數據。
/llms.txt 這份提案是 2024 年底提出的。兩年過去，每個 SEO 部落格都寫過它的教學；每篇討論「GEO」（生成引擎優化）的文章都把它當成檢核清單上的項目；WP Engine 在過去一個月發了五篇關於它的文章；Mintlify 為它做了產品功能。
只有一件事沒人做：檢查那些理應有 llms.txt 的網站到底有沒有，以及它們做出來的東西到底像不像樣。
所以我跑了個指令稿，掃了 70 個站——AI 實驗室、文件平台、開發基礎設施大廠、當下熱門 SaaS、WordPress 媒體——抓下它們的 /llms.txt。下面是我看到的。
結論先放這：70 家裡 31 家（44%）有真 llms.txt。剩下 56% 要嘛 404，要嘛回傳了 HTML（SPA 路由把這個路徑吃掉了），要嘛乾脆給爬蟲 403。這 31 個真檔案裡，有 12 個（41%）不符合 llmstxt.org 自己定義的格式。檔案大小從 648 byte 到 280 KB，相差 432 倍。你以為會領跑的公司——OpenAI、Hugging Face、Google AI、Mintlify、GitBook、ReadMe——一個都沒有。
測試方法
我從八個類別裡挑了 70 個站：
- AI 實驗室（Anthropic、OpenAI、Mistral、Cohere、Perplexity、Hugging Face、Google AI、Replicate、ElevenLabs）
- AI 寫程式工具（Cursor、Codeium、Windsurf、Claude、Aider）
- 文件平台（Mintlify、GitBook、ReadMe、Redocly、Docusaurus）
- 開發基礎設施（Vercel、Supabase、Stripe、Cloudflare、Fly、Netlify、Railway、Render、Bun、Deno）
- 現代 SaaS（Linear、Notion、Retool、Raycast、Framer、Airtable、Segment、Amplitude、Mixpanel、PostHog）
- WordPress 生態（Kinsta、WP Engine、Yoast、ManageWP、Cloudways、WordPress.com、WP Tavern）
- llms.txt 提案方（llmstxt.org、fast.ai、AnswerAI）
- 社群 / 出版平台（dev.to、Hacker Noon、Substack、Indie Hackers、GitHub、GitLab）
對每個站，我用一般瀏覽器 User-Agent，不加特殊 header，直接 GET https://<網域>/llms.txt。解析回應內容判斷是真 markdown（開頭是 # 標題）還是 HTML（SPA fallback 吃掉了路由）。
對每個真樣本，量化了七個維度：
- 檔案 byte 數
- 行數
- H2 章節數
- markdown 連結總數
- 深層內部連結 / 行銷首頁 / 外部連結 各佔比
- 是否符合 spec 的
# 標題+> 引言區塊格式 - 前 200 字元（用來找漏網的 HTML fallback）
就這些。沒登入、沒 API key、沒特殊爬蟲——任何 LLM 爬蟲都會發出的同樣 HTTP GET。
發現 1：超過一半「應該有」的站根本沒有
| 結果 | 數量 | 比例 |
|---|---|---|
真 llms.txt |
31 | 44% |
| 404 | 22 | 31% |
| HTML fallback（200 但 SPA 回傳） | 9 | 13% |
| 403 / 530 / 逾時 | 8 | 11% |
44% 這個數字已經夠難看。但更難看的是，「理應有」那一群裡最響亮的都缺席：
- OpenAI：根網域 403，platform.openai.com 404。世界上最被討論的 LLM 是他們做的，但他們自家文件沒有 llms.txt 幫 LLM 找到。
- Hugging Face：404。這個平台存在的全部意義就是託管那些「讀文字」的模型。
- Google AI（ai.google.dev）：302 轉址，跳過去也沒有 llms.txt。
- Mintlify——這家公司正在向客戶賣「一鍵加 llms.txt」產品功能——自家行銷站 404，自家文件站 530。
- GitBook、ReadMe：都 404。
- fast.ai：404。Jeremy Howard 的網站。llms.txt 這事就是他提出來的。
- WP Engine、Kinsta、WP Tavern、ManageWP：404 或 HTML fallback。同樣這幾家 WordPress 主機商，每個月發五篇關於 GEO 和 AI 搜尋排名的內容系列。
可以反駁一句：「llms.txt 只對那種 LLM 會在答案裡引用的站有用；OpenAI 沒必要為 ChatGPT 引用 OpenAI 做最佳化。」 行。但這解釋不了 Mintlify——他們當下整個賣點就是「用我們的平台一鍵加 llms.txt」。如果他們自己都不吃自家狗糧，你應該問為什麼。
HTML fallback 那一組（9 個站回傳 200 但是 HTML 內容）也值得單獨看。Cohere docs、Cursor docs、Codeium、Windsurf、Claude.ai、Kinsta、Notion、Segment、Deno 全在這組。這些站跑的是 Next.js / Vue / 同類 SPA 框架，框架預設的 catch-all 路由把 /llms.txt 當成應用程式路由，回傳了 React 外殼。沒人發現。沒人監控。LLM 爬蟲抓到的「llms.txt」是一坨 50 KB 的 <div> 加上一堆 JavaScript bundle URL，裡面甚至沒有「llms.txt」這個字。
這是最尷尬的一類。404 是明確的「我沒有」。HTML fallback 是無意識的「我以為我有但其實沒有」。你跑了個工具，從 CMS 裡複製了一段，以為搞定了，結果沒。
發現 2：存在的檔案裡 41% 不符合格式
llmstxt.org 自己定義的 llms.txt spec 簡單到不行。結構上只有兩個必選元素：
- 檔案開頭一個
# 標題H1。 - H1 後面緊跟一個
> 引言區塊，用一句話說這個站是做什麼的。
完了。剩下的章節、連結、## H2 分組——都是自由發揮。
去重後的 29 個獨立樣本裡（cloudflare.com / www.cloudflare.com 和 cursor.com / www.cursor.com 是同一份）：
- 17 家（59%）符合 H1 + 引言區塊格式。
- 12 家（41%）跳過了引言區塊。 有的連 H1 都沒。
不合格名單不是你以為的那種新手：
| 站 | 章節數 | 連結數 | 問題在哪 |
|---|---|---|---|
| docs.anthropic.com | 3 | 1,415 | 沒有引言區塊簡介 |
| docs.stripe.com | 26 | 528 | 沒有引言區塊簡介 |
| render.com | 6 | 295 | 沒有引言區塊簡介 |
| bun.sh | 2 | 317 | 沒有引言區塊簡介 |
| netlify.com | 10 | 83 | 沒有引言區塊簡介 |
| developers.cloudflare.com | 9 | 103 | 沒有引言區塊簡介 |
| docs.mistral.ai | 1 | 75 | 單一章節，沒有簡介 |
| elevenlabs.io | 7 | 49 | 沒有引言區塊簡介 |
| cursor.com | 20 | 0 | 沒有引言區塊，且零 markdown 連結——只是裸 URL 清單 |
| replicate.com | 7 | 1 | 沒有引言區塊簡介，連結幾乎為零 |
| amplitude.com | 7 | 0 | 沒有引言區塊，零連結 |
| supabase.com | 2 | 19 | 沒有引言區塊簡介 |
Anthropic——LLM 生態裡字面意義上的標竿客戶——發了 150 KB 的連結，開頭沒有任何一句引言區塊。Stripe 發了 90 KB 結構化文件索引，開頭沒有任何一句話告訴讀者「這是 Stripe」。這些都不是新手網站，他們有專門的技術寫作者。
這看起來像什麼呢：平台團隊某個工程師按 docs sitemap 自動產生了 llms.txt，發了，沒看 spec。爬蟲抓到這個檔案，看到一片連結，不知道這個站到底是什麼。
Cursor 的最怪。20 個章節，巢狀得很整齊，零 markdown 連結——每一行都是裸 URL：
## Get Started
- https://cursor.com/docs.md
- https://cursor.com/docs/get-started/quickstart.md
- https://cursor.com/docs/models-and-pricing.md
- https://cursor.com/docs/models/claude-4-6-sonnet.md
而且裡面至少有一處串接 bug：https://cursor.comhttps://cursor.com/changelog.md 直接寫在那兒。如果某個 LLM 爬蟲對 markdown 連結解析比較嚴格，Cursor 的檔案可能有一半對它而言是隱形的。
發現 3：檔案大小相差 432 倍，關於這個檔案是什麼沒人達成共識
最小的真 llms.txt：648 byte。這是 llmstxt.org 自己——這份 spec 的發源地——指向三個文件。
最大的：279,743 byte。PostHog，看起來像是把整個文件站台 sitemap 都倒進去了，外加每個條目的散文式註解，54 個 H2 章節，2,555 個 markdown 連結，每個指向某個文件頁面的 .md 版本。
中間隔著八個數量級的實作差異：
| 區間 | 數量 | 例子 |
|---|---|---|
| 極小（<1 KB） | 1 | llmstxt.org（648 byte） |
| 小（1-5 KB） | 8 | railway.app（1.4 KB）、supabase.com（1.3 KB）、amplitude.com（2.8 KB）、replicate.com（3.4 KB）、mistral.ai（4.9 KB）、cohere.com（4.8 KB）、hackernoon.com（4.9 KB）、answerai.com（1.8 KB） |
| 中（5-20 KB） | 9 | linear.app、cursor.com、framer.com、yoast.com、wordpress.com、cloudflare.com、elevenlabs.io、docs.mistral.ai、developers.cloudflare.com |
| 大（20-100 KB） | 9 | docs.perplexity.ai（22 KB）、github.com（28 KB）、bun.sh（33 KB）、render.com（36 KB）、netlify.com（20 KB）、stripe.com（64 KB）、cloudways.com（64 KB）、docs.stripe.com（93 KB）、redocly.com（98 KB） |
| 巨型（100 KB+） | 2 | docs.anthropic.com（152 KB）、posthog.com（280 KB） |
中位數：9.4 KB。平均：34.7 KB。平均值被兩個巨型異常值拉高了——多數站的檔案其實很小。
這個分布直接對應「llms.txt 到底是什麼」的兩種不同理念。spec 文本對此態度模糊，於是大家各自做了選擇：
理念 A（spec 給的範例）：llms.txt 是一個微型指標檔案。幾百 byte。一個標題、一句話簡介、幾個最重要頁面的連結。LLM 自己去爬那些連結。llmstxt.org（648 B）、supabase.com（1.3 KB）、railway.app（1.4 KB）、answerai.com（1.8 KB）屬於這一派。
理念 B（索引傾倒）：llms.txt 是給 LLM 用的全量 sitemap。每一個記錄的頁面都列上。PostHog（280 KB）和 Anthropic 文件（152 KB）大致按這種方式把整個 docs map 倒進去。Stripe（90 KB）是稍微精簡版的同樣思路。
哪一種是對的，沒有共識。Mintlify 的產品（能用的時候）輸出的是理念 B。手寫的多半趨向理念 A。280 KB 的檔案對模型 context 來說想必負擔不小；648 byte 對模型來說想必資訊又太少。
誠實的回答是：現在沒人知道哪種更管用，因為沒人公開發過資料，證明任何一種做法帶來了更多 LLM 引用或流量。
發現 4：連結品質其實可以——但連結數量被幾個大檔案拉偏了
好消息：當各家網站真的在 llms.txt 裡放連結時，那些連結基本都是有用的。
29 個樣本累計 7,557 個 markdown 連結：
- 73.8% 是深層內部連結（路徑有兩段或更多——
docs.example.com/api/v2/something） - 23.3% 是外部連結（多數是引用標準、SDK、GitHub repo）
- 2.9% 指向行銷首頁（首頁或頂級目錄頁——
/pricing、/about）
2.9% 這個數字讓人鬆了口氣。本來對 llms.txt 最大的擔心是各家公司會把它當 SEO 漏斗——把 AI 引到首頁和定價頁。結果他們基本沒這麼做，連結確實指向有用的文件。
壞消息是這個總數被幾個大檔案嚴重拉偏。PostHog 一家就貢獻了 7,557 個裡的 2,555 個，三分之一。Anthropic、Redocly、Stripe、Cloudways 再貢獻 3,000+。多數站的連結數其實在 0 到 100 之間。
四個站零 markdown 連結：amplitude.com、cohere.com、cursor.com、hackernoon.com。Cursor 和 Hackernoon 用裸 URL 字串（某些爬蟲能用，技術上不是 markdown）。Amplitude 和 Cohere 乾脆用散文描述自家產品，作為上下文勉強算有用，但不是 spec 設計的用法。
發現 5：WordPress 生態幾乎全軍覆沒
測試的 7 個 WordPress 生態候選裡：
- Cloudways、Yoast、WordPress.com：有。✅
- Kinsta：HTML fallback（你以為他們有，他們沒有）。❌
- WP Engine、ManageWP、WP Tavern：404。❌
這個結果特別刺眼，因為 WP Engine 最近一直在猛推「GEO」——生成引擎最佳化。一個月裡發了五篇專文，包括《Technical GEO: Ensuring Sites are Machine Readable》。寫這些文章的人服務的公司，自家行銷站沒有 llms.txt。
Kinsta 的 HTML fallback 更有意思。他們出內容教 agency 怎麼把網站做得對 AI 友善。他們大概覺得自家已經有了 llms.txt——可能裝了某個外掛。外掛沒起作用——Next.js 路由把 /llms.txt 吃成了 React shell。他們團隊沒人檢查過。
WordPress 生態裡，「寫關於 llms.txt 的文章」和「擁有 llms.txt」之間的距離接近無窮大。
發現 6：HTML fallback 這個問題比表面看上去更大
那 9 個回傳 200 OK 但回應是 HTML 的站，值得單獨說，因為從任何監控工具的角度看，它們都是「成功」。
如果你 curl -I kinsta.com/llms.txt，拿到的是 200。你 CDN log 上看到所有存取 /llms.txt 的請求都拿到了資料。什麼都沒壞。
但回應內容是 React 應用。把回應當 markdown 解析的 LLM 拿到的是 50 KB 的 <div class="..."> 加上一堆 JavaScript bundle URL。LLM 沒辦法知道這不是你的本意。
涉及的站：
- Cohere docs、Cursor docs（這兩家公司的主網域有 llms.txt 但 docs 子網域 catch-all）
- Codeium、Windsurf、Claude.ai——AI 寫程式工具自己沒有 llms.txt
- Notion（最有可能被 LLM 引用的 SaaS）
- Segment、Kinsta、Deno
它們多數跑現代 JS 框架，框架預設的 catch-all 路由處理了未知路徑。修復就一行設定：要嘛讓 /llms.txt 明確 404，要嘛真回傳檔案。沒人去改。
如果你的站跑 Next.js / Nuxt / Astro / 類似框架，這是第一件該查的事。用 curl 存取自家 /llms.txt，讀 body。如果看到 <!DOCTYPE html>，無論你本來有沒有打算做 llms.txt，都有問題。
發現 7：沒人有證據這玩意兒真的有用
這篇審查寫到最後最難的部分，是承認：現在沒有證據 llms.txt 做了什麼有用的事。
我特意找過：
- 有沒有公開資料顯示，有 llms.txt 的站比沒有的站，在 Perplexity / ChatGPT / Claude 答案裡被引用得更多？
- LLM 爬蟲真的在請求
/llms.txt嗎？（Cloudflare 公開了部分 bot 流量資料，但不針對這個路徑。） - 有沒有任何經 A/B 測試的案例，證明加上 llms.txt 改變了引用份額、推薦流量、或任何可測量的東西？
三個問題，2026 年中的答案都是「基本沒有」。有軼事。有教學。有讀起來像供應商行銷的案例。但沒有嚴肅的公開證據證明 llms.txt 真的影響了什麼。
也可能——其實很可能——大 LLM 服務商把它當作 hint 在讀，類似某些搜尋引擎讀 sitemap.xml 的方式。也可能他們沒在讀，整個圍繞這個檔案的討論是 SEO 行業為了填補「AI 答案引擎到底怎麼排名」這個謎團的沉默。
最有意思的事實是：連那些商業模式最直接受益於 llms.txt 真的有用的公司——模型提供商自己——多數都沒給自家文件站寫一份。這要嘛是因為他們知道一些 SEO 行業不知道的事，要嘛是因為他們和所有人一樣困惑。
我覺得這意味著什麼
幾個謹慎的結論。不是建議——網路上的 llms.txt 建議已經太多了。只是盯了 31 個真檔案一天得出的觀察。
1. llms.txt 是靠預設勝出，不是靠採用率勝出。 這是這個領域唯一一個有公開擁護的提案。但「我聽說過」和「我加到我站上了」不是一回事。多數站都沒加。加了的，多數沒加好。
2. 真正的開放問題是理念 A 還是理念 B，不是「該不該加 llms.txt」。 648 byte 的指標檔案和 280 KB 的 sitemap 倒賣，不可能同時是同一份 spec 的正確解讀。在有人公開發出「哪種檢索效果更好」的真資料之前，所有「最佳實踐」文章都是在猜。
3. HTML fallback 是當下槓桿最高的修復點。 如果你用現代 JS 框架，且從來沒檢查過自家 /llms.txt 回應內容——你大概率有一個沉默的漏掉。一行 curl 能看出來。一行路由設定能修好。
4. 遵守 spec 幾乎免費，但幾乎沒人做。 41% 的存在的檔案跳過了開頭的引言區塊。爬蟲讀這些檔案得從 URL 清單裡猜這個站是做什麼的。在 > 引言區塊裡加一句話十秒鐘搞定，可能比下面那一堆精緻的結構更重要。可能。
5. 「寫關於 llms.txt 的文章」和「擁有 llms.txt」之間的差距非常大，在 WordPress 和主機商生態尤其明顯。 這要嘛是機會（其他人都在睡覺），要嘛是訊號（最貼近 SEO 的人已經算過了，決定跳過）。你自己挑。
關於樣本資料
如果想看原始資料：我把 31 個真 llms.txt 檔案、probe 指令稿、分析輸出都做了公開鏡像。方法簡單到你可以在 5 分鐘內對自己的懷疑名單跑同樣的審查。
至少值得對自家站跑一次。HTML fallback bug 是沉默的，spec 是短的，萬一 llms.txt 真有用——一個格式正確的文字檔就夠了。
如果有人跑出來的結論和我這個差得很遠，我真心想看看。特別是有人能拿出引用份額資料證明這事真在起作用。在這件事上，目前觀點的市場喧囂，證據的市場沉默。
資料說明：70 個候選站點於 2026-05-16 用普通 HTTP GET + 桌面瀏覽器 User-Agent 探測。31 個回傳真 llms.txt。去掉鏡像網域（cloudflare.com / www.cloudflare.com、cursor.com / www.cursor.com）後 29 個獨立樣本。Probe 指令稿、原始回應、單站分析均做了鏡像。
方法限制：只探測了根路徑 /llms.txt。某些站可能在子網域或帶版本的路徑下也有 llms.txt。沒檢查 spec 裡可選的 /llms-full.txt（詳細版）。按 IP 或 User-Agent 阻擋自動請求的站（Reddit、部分 Indie Hackers）可能有看不到的真檔案。HTML fallback 這一類是偽陰性風險，估計低估了真實採用率 1-3 個站。