免費網站健檢
首頁 › 資源中心 › llms.txt 要不要做？先看 AI 爬蟲到底讀不讀它

llms.txt 要不要做？先看 AI 爬蟲到底讀不讀它

作者：卞譁丞｜負責人｜最後更新：2026/07/21

llms.txt 是一種放在網站根目錄的 Markdown 檔案，用來把網站的重點內容整理成一份給語言模型看的索引，由 Jeremy Howard 在 2024 年 9 月提出。這兩年它被大量行銷內容包裝成「AI 時代的 robots.txt」，變成 GEO 提案裡的固定項目。但如果你真的去查 llms.txt AI 爬蟲 之間到底發生了什麼，會看到一個跟話術差很多的現實：到 2026 年 7 月為止，沒有一家主要 AI 公司公開承諾會依它行動，而實測資料顯示絕大多數網站的這個檔案，從上線那天起就沒被抓取過。

這篇不是要叫你別做，而是要先把它放回正確的位置——它是什麼、不是什麼、什麼情況下值得花那十分鐘。

最常見的誤解：它從來就不是爬蟲指令

大部分關於 llms.txt 的誤解，起點都是把它跟 robots.txt 類比。

規格作者自己在 llmstxt.org 上就把這件事講清楚了：robots.txt 的用途是告訴自動化工具「哪些存取是可接受的」，而 llms.txt 的資訊「通常是在使用者明確提出需求時被取用」。用規格書的原話，它服務的是 inference time——模型正在回答一個問題的當下，而不是爬蟲在背景抓取網頁的時候。

這個區別不是文字遊戲，它決定了你該對這個檔案抱什麼期待：

  • robots.txt 是指令，爬蟲讀了會改變行為（該不該抓這個目錄）。
  • llms.txt 是建議性的內容索引，模型可以拿去用，也可以完全不理。

換句話說，即使某個 AI 工具讀了你的 llms.txt，那也只代表它省下一點翻頁的力氣，不代表它更願意引用你。「被讀到」和「被引用」是兩件不同的事，而 GEO 在意的是後者。

實際被抓取的比例，低到接近雜訊

規格是一回事，實務是另一回事。這裡有幾組公開的爬蟲紀錄資料：

Ahrefs 在 2026 年 5 月的研究掃了 137,000 個網域，結果是 97% 的 llms.txt 檔案收到的請求數是零——不是「效果不明顯」，是連一次抓取都沒發生過。

其他監測服務的數字方向一致：在數百萬次 AI 機器人造訪的樣本中，明確指向 /llms.txt 的請求佔比落在 0.1% 上下。GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBot 這些主要的 AI 爬蟲，絕大多數時候是直接爬 HTML，繞過這個檔案。

為什麼會這樣

從模型端的角度看其實很合理。一份由網站自己撰寫、自己挑選、可以隨時改寫的摘要檔案，本質上是自述。AI 系統如果直接採信這種檔案，等於開了一個成本極低的操縱入口——這正是當年 keywords meta 標籤被廢棄的原因。

Google 的 John Mueller 就是這樣類比的：他把 llms.txt 形容成「暫時性的拐杖，也許能省一點 token」，並直接拿它跟過時的 keywords meta 標籤相提並論。

Google 的官方立場很明確

這部分不需要推測，Google 在 2026 年 5 月發布的生成式 AI 最佳化指南裡寫了：

「你不需要為了出現在 Google Search（包含其生成式 AI 功能）而建立新的機器可讀檔案、AI 文字檔、標記或 Markdown……這麼做既不會傷害也不會幫助你在 Google Search 的能見度與排名，因為 Google Search 會忽略它們。」

同一份文件列出真正有影響的項目：內容的獨特性與專業觀點、技術面的可爬取與可索引、語意化的 HTML 結構、清楚的頁面組織、真實的商家資訊。沒有一項是新的檔案格式。

那 Google 自己為什麼有 llms.txt

這是個好問題，也是最容易被斷章取義的地方。

2026 年 5 月，Google 把 llms.txt 的存在檢查加進了 Chrome Lighthouse 的「代理瀏覽」稽核類別，理由是「沒有 llms.txt 的話，代理可能要花更多時間爬取網站才能理解整體結構」。Mueller 隨後說明，Google 在自家開發者文件站放這個檔案是為了探索性與功能性，讓 AI 寫程式工具更快找到對的頁面——「這不是為了搜尋而做的」。

所以正確的讀法是：Google 認為 llms.txt 在「AI 代理好不好使用你的網站」這件事上有意義，在「搜尋與 AI 摘要要不要提到你」這件事上沒有意義。這兩件事被混在一起講，就會變成「連 Google 都在做，你怎麼能不做」。

那到底誰該做

把上面三件事合起來，判斷標準其實很清楚。

該做的：技術文件站、API 文件、需要被 AI 寫程式工具正確讀取的產品。 這是 llms.txt 目前唯一有明確價值的場景。你的使用者正在用 Cursor、GitHub Copilot 或 Claude 邊問邊接你的 API，一份整理好的索引，決定了工具是產出可以跑的整合程式碼，還是幻想出一個不存在的端點。Stripe、Vercel、Cloudflare、Anthropic 這類公司維護這個檔案，理由是開發者體驗，不是 SEO。

可以做但別記在成效上的：一般企業官網、服務業、電商。 成本是十分鐘，風險是零，Google 明說不影響排名。當作一個技術衛生習慣沒問題——但它不該出現在任何一份 GEO 提案的「預期成效」欄位裡。

該警覺的訊號： 如果一份 GEO 報價把「建置 llms.txt」列為主要交付項目、或用它來解釋為什麼收這個價錢，那值得多問幾句。這跟提案書該怎麼看是同一類問題——把低成本的技術動作包裝成策略服務，是這個行業常見的膨脹手法，跟那些該轉頭就走的紅旗屬於同一個家族。

如果要做，最省事的做法

真的要放，規格本身很簡單：根目錄 /llms.txt，Markdown 格式，一個 H1 標題、一段簡述，接著用清單列出重點頁面與各自的說明連結。重點只有兩個：

  1. 只放真的重要的頁面。 這是索引不是網站地圖，塞滿反而失去意義。
  2. 維護它。 一份指向失效頁面的索引比沒有更糟。如果沒人負責更新，不如不放。

至於預期，維持在「這是給 AI 代理省力用的」就好。

那時間該花在哪

如果你的目的是被 AI 提到，資源該放在內容本身，而不是檔案格式。方向大致是這幾件事：

  • 答案寫在段落開頭，不鋪陳。模型在切「可引用單元」時，優先取用一段話就構成完整答案的段落。
  • 用具體數字取代形容詞。「經驗豐富」沒有東西可以引用，「這道流程含 16 道檢查」有。
  • FAQ 的第一句就是完整答案，不要用「這要看情況」開頭。
  • 確認內容爬得到。 如果你的頁面靠 JavaScript 動態產生文字，那才是真正該先處理的技術問題——這比 llms.txt AI 爬蟲 這組議題重要得多。

這些也正是 Google 那份指南在講的事。想先弄懂整個架構，可以從 GEO 是什麼開始，再看 SEO 和 GEO 的差別。

小結

llms.txt 是一個立意良善但目前缺乏採用的提案。它不是爬蟲指令，主要 AI 公司沒有承諾依它行動，97% 的檔案沒被抓取過，Google 明說會忽略。

它值得做的理由只有一個——你的內容需要被 AI 開發工具正確讀取。除此之外，把同樣的時間花在讓內容本身變得可引用，回報高得多。

如果不確定自己網站現在在 AI 眼中長什麼樣，可以加 LINE（@APM168）跟我們約一次免費諮詢，我們會直接拿你的頁面去問模型看看它能答出什麼。

SEO/GEO 成效受搜尋引擎與 AI 模型演算法、市場競爭等因素影響，實際結果因專案而異，本文不構成排名或被引用之保證。

資料來源

本文經 AstraPath 編輯流程 查證與更新。