llms.txt 完整指南：讓 AI 看懂你的網站在講什麼

想像你開了一家很大的書店，書架有三十排。有人推門進來，只給他一份「所有書的清單」——三萬筆書名，按進貨日期排序。他會怎麼樣？大概站在門口翻兩分鐘就走了。

這差不多就是 AI 爬蟲面對 sitemap.xml 時的處境。

llms.txt 想解決的就是這件事：不是把所有東西倒給它，而是給它一張「這家店在賣什麼、精華在哪幾排」的簡介。一頁就好。

這篇文章會把 llms.txt 的規範、寫法、常見誤解講清楚，最後我會直接公開 SEM.tw 自己這份檔案是怎麼做的、中間卡在哪些取捨——因為這部分網路上幾乎沒人寫。

什麼是 llms.txt？

llms.txt 是一個放在網站根目錄的 Markdown 檔案（https://你的網域/llms.txt），用簡短、結構化的方式告訴大型語言模型：這個網站是做什麼的、有哪些重要內容、該從哪裡讀起。

它由 Jeremy Howard 在 2024 年提出，規範文件在 llmstxt.org。核心觀察很簡單：LLM 有 context window 上限，塞不下整個網站；而一般網頁充滿導覽列、廣告、JavaScript，訊噪比很差。與其讓 AI 自己在雜訊裡淘金，不如網站主動遞一份乾淨的摘要。

要注意的是，llms.txt 目前不是任何一家 AI 公司的官方標準。OpenAI、Anthropic、Google 都沒有正式宣布會讀取它。它比較像當年 sitemap.xml 剛出現時的狀態——由社群推動，等待採用。

所以該不該做？我的看法是：成本低到不做很可惜。一份檔案、幾十行內容，就算現在沒被讀取，格式本身也逼你把網站的內容結構想清楚一次。這件事對AI 搜尋優化（AISO）的其他環節同樣有幫助。

為什麼需要 llms.txt？我已經有 sitemap.xml 了

因為兩者的讀者不同。sitemap.xml 是給搜尋引擎爬蟲「排程用」的，它只回答「有哪些網址、什麼時候更新的」；llms.txt 是給語言模型「理解用」的，它回答「這個網站在講什麼、哪些內容最值得看」。

差別可以這樣看：

我們站上有兩百多篇文章，sitemap.xml 就是兩百多筆 <url>，每筆只有網址和更新時間。AI 拿到這份檔案，除了知道「這站有很多頁」之外，什麼也不知道——它不知道哪篇是入門、哪篇是進階、分類之間是什麼關係。

llms.txt 補的就是這層語意。

llms.txt 的格式規範是什麼？

規範刻意訂得很鬆，只有四個層次，而且全部是標準 Markdown：

第一行是 H1，寫網站或專案名稱。 這是唯一必填的區段。

接著是一段 blockquote（> 開頭）作為摘要。 用一到三句話講清楚這個網站是誰、為誰做、提供什麼。這段是整份檔案最重要的一行——如果 AI 只讀得下一句話，就是這句。

然後可以放零到多段自由說明文字。 補充背景、使用方式、注意事項都可以，但不要放清單。

最後是若干個 H2 區段，每段底下是連結清單。 格式固定為 - [連結標題](網址): 一句話描述。冒號後面的描述不是裝飾，它是 AI 判斷「要不要點進去讀」的依據。

規範另外定義了一個特殊區段 ## Optional，意思是「這些是次要資源，context 不夠時可以跳過」。

寫的時候有幾個容易忽略的細節：連結建議用完整絕對網址而不是相對路徑，因為 AI 抓到這份檔案後未必記得住 base URL；描述要寫給沒看過你網站的人看，不要用內部術語；區段標題用讀者理解的分類名稱，不要用資料庫裡的 slug。

llms.txt 和 llms-full.txt 差在哪？

llms.txt 是目錄，llms-full.txt 是全文。前者只列標題與描述讓 AI 決定要不要深入；後者直接把所有內容的 Markdown 原文串成一個大檔案，讓 AI 一次讀完、不必再發請求。

llms-full.txt 不在原始規範裡，是社群後來的延伸做法。它的取捨很直接：

好處是 AI 不需要逐頁抓取就能拿到完整內容，減少它「讀不到」或「讀錯」的機會。特別是網站有大量 JavaScript 渲染的內容時，這份純文字檔可能是唯一能被完整讀懂的版本。

代價是你把全部內容毫無保留地攤開了。任何人打開這個網址，就拿到你所有文章的原始 Markdown——複製、餵給模型、二次利用，全都不設防。

這個決定沒有標準答案，取決於你的內容是不是核心資產。教學內容、公開文件、開源專案文件，攤開通常划算，因為你的目的本來就是被引用、被推薦。但如果內容本身是付費產品的一部分，或是你靠獨家研究報告吸引訂閱，那就要三思。

我們選擇了全部公開。理由是 SEM.tw 的商業價值不在文章本身，而在「被認為是這個領域可信的來源」——文章被 AI 完整讀懂、正確引用，比藏起來有價值得多。這也是讓內容被 AI 引用的基本邏輯。

我們怎麼做 SEM.tw 的 llms.txt

講三個實際卡住的決策點，這些都是規範文件不會告訴你的。

第一個決策：每個分類要放幾篇？

我們站上有十個分類、超過兩百六十篇文章。如果全放，llms.txt 會膨脹到七百多行，那就失去「摘要」的意義了，跟直接給 sitemap 沒兩樣。

最後定在每個分類取最新的 5 篇，加上一篇入門總覽，總共約六十行。這個數字是這樣試出來的：三篇太少，看不出分類的內容廣度；十篇的話整份檔案接近一千五百字，開始稀釋掉每一筆的權重。五篇剛好能呈現「這個分類在談什麼」而不讓 AI 失焦。

排序用發布時間由新到舊，而不是流量或人工挑選。原因是 AI 搜尋特別在意時效性，一份 llms.txt 如果永遠列著三年前的文章，會讓模型判斷這個站已經沒在更新。

第二個決策：靜態檔案還是動態產生？

我們選動態產生。網站每新增一篇文章，llms.txt 自動更新，不需要有人記得去改。代價是每次請求都要查資料庫，所以加了一小時的快取——AI 爬蟲的抓取頻率遠低於一小時，這個延遲完全無感，但省掉了絕大部分的資料庫查詢。

如果你的網站是純靜態或內容很少更動，寫一個檔案手動維護反而更單純。判斷標準很簡單：內容更新頻率高於一個月一次，就自動化。

第三個決策：分類的描述文字從哪來？

一開始我們在程式裡另外寫了一份給 AI 看的分類說明，結果很快就跟網站上顯示的分類描述長歪了——改了一邊忘了另一邊。後來改成兩邊共用同一份定義，llms.txt 直接讀網站本身的分類描述。

這個原則值得記住：給 AI 看的內容和給人看的內容，來源要一致。 一旦分岔，維護成本會慢慢咬人，而且不一致本身就會傷害可信度。

順帶一提，llms-full.txt 那支因為要讀取檔案系統上的 Markdown 原文，我們加了路徑檢查，確保只能讀到內容目錄底下的檔案。這種把使用者資料轉成檔案路徑的地方，一律要防路徑遍歷——不是因為 llms.txt 特別危險，而是這類寫法本來就該這樣做。

常見的四個錯誤

把 sitemap 直接改個副檔名。 這是最常見的。llms.txt 的價值在描述文字，只有一排光禿禿的網址等於沒做。

描述寫成關鍵字堆疊。 有人把 SEO 那套「主關鍵字塞三次」搬過來，寫出「Google Ads 教學｜Google Ads 課程｜Google Ads 代操」這種描述。語言模型讀這種句子，只會判斷這是低品質內容。用完整的句子講清楚這篇在解決什麼問題就好。

放了 llms.txt 卻在 robots.txt 擋掉 AI 爬蟲。 兩份檔案互相矛盾，等於準備了說明書又把門鎖上。做 llms.txt 之前先確認robots.txt 的設定有放行你想被讀取的爬蟲。

做完就不管了。 llms.txt 是網站的門面摘要，網站改版、分類重整、主打內容換了，它就該跟著改。手動維護的話，建議直接排進季度檢查清單。

怎麼驗證 llms.txt 有沒有效果？

老實說，目前沒有官方工具可以告訴你「AI 有沒有讀你的 llms.txt」。但有三件事可以做。

第一，確認技術面沒問題。 直接在瀏覽器打開 你的網域/llms.txt，檢查三件事：能不能正常顯示（不是 404）、中文有沒有亂碼（Content-Type 要標明 UTF-8）、內容是不是純文字而不是被 HTML 模板包起來。這關過不了，後面都免談。

第二，看伺服器日誌。 過濾 User-Agent 含有 GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBot 的請求，看它們有沒有抓 /llms.txt。這是目前最直接的證據。我們觀察下來，AI 爬蟲對根目錄檔案的抓取頻率大約落在每週一到數次，不像 Googlebot 那樣密集。

第三，做提示詞測試。 定期到 ChatGPT、Perplexity 問幾個你的內容應該能回答的問題，看它們會不會引用你的網站。這個方法不精確，但能看出長期趨勢。做法可以參考GEO 監測工具的比較。

要提醒的是，別把流量變化直接歸因給 llms.txt。它是整套 AI 搜尋優化裡很小的一塊，內容品質、結構化資料、外部提及的影響都比它大得多。把它當成「基礎衛生」——做了不保證加分，沒做倒是有點說不過去。

結語

llms.txt 現在的處境，很像 2005 年的 sitemap.xml——規範存在、工具零散、官方態度不明，早期採用者投入的成本不高，但如果標準真的成形，先做的人不必手忙腳亂。

我的建議是：花一個下午把它做出來，重點放在那段 blockquote 摘要和每個連結的描述文字上——這兩處是整份檔案唯一有智慧含量的地方，其餘都是格式。做完之後別急著看成效，把力氣放回內容本身，那才是 AI 願不願意引用你的真正原因。

如果想先建立整體的框架認知，建議從AISO 完整指南開始，那篇把 AI 搜尋優化的各個環節串成了一張完整的地圖。