llms.txt 檔案是一份簡短、由人工策展的 Markdown 文件，列出網站對語言模型讀者最實用的資源，並依照 llmstxt.org 所提出的結構撰寫。為自己的網站產生這份檔案並不需要爬取、擷取，或將任何資料傳送給外部服務：你自行決定哪些標準網址應該列入索引，將編輯內容貼到本機的表單中，工具就會依照提案文件記載的順序，輸出具有確定性的 Markdown。這種單檔、由策展人主導的做法，正是 llms.txt 與網站地圖或 robots 指令不同之處，同時也說明了為何一個完全不碰你伺服器的產生器，往往比自動掃描器更能產生誠實的結果，因為只有你能確認哪些頁面是穩定、具標準網址，且值得推薦的。下方的工作流程會逐步說明產生前的編輯決策、產生器的逐步操作、驗證草稿是否符合提案的檢查流程，以及讓已部署檔案持續保持實用的發布與驗證循環。
llms.txt 實際上是什麼（以及不是什麼）
該提案描述的是一份簡潔的 Markdown 索引，內含一個必要元素：一個 H1 標題，內含專案或網站名稱。在該 H1 之後，提案允許加入選擇性的引文摘要、選擇性的非標題細節說明，以及零個或多個 H2 區段，每個區段包含 Markdown 列表項目，其必要核心為一條連結。提案中對 Optional（選擇性）區段有專屬慣例：置於名為 Optional 的 H2 之下的資源會被標記為次要資料，模型在需要較短上下文時可以略過。其餘的一切，包括哪些資源符合選擇性的資格，都是檔案作者的編輯決策，而非由產生器自動指派的標籤。
同樣重要的是 llms.txt 不做的事。它不是 robots 指令，不是資安控管機制，不是網站地圖的替代品，也不是保證能讓內容被探索到的通訊協定。發布這個檔案並不會強制爬蟲或助理去請求它，無法授予被封鎖頁面的存取權，無法覆蓋身分驗證機制，也無法將內容從模型訓練中移除。它本身也不是排名訊號：並無證據顯示搜尋引擎會將 llms.txt 的存在與否視為排名因素，該提案也未作此主張。將其視為排名訊號，往往會導致檔案塞滿所有頁面，反而失去策展的本意。
| 機制 | 主要用途 | 格式 | 使用對象 |
|---|---|---|---|
| llms.txt | 策展式的推論階段資源地圖 | Markdown | 語言模型與助理 |
| robots.txt | 參與式爬蟲的爬取偏好設定 | 純文字 | 選擇讀取它的網路爬蟲 |
| sitemap.xml | 可建立索引之網址的清單 | XML | 搜尋引擎 |
| 結構化資料 | 描述實體與頁面內容 | JSON-LD 或 Microdata | 搜尋與助理解析器 |
每種機制都有其各自的功能。llms.txt Generator 只負責處理上表中的第一列，而且不會去爬取你的網站，也不會取代其他任何機制。
在產生之前先策展標準連結
在開啟產生器之前，最重要的工作是編輯。策展的重要性遠大於長度，提案也明確指出，一份包含所有頁面的檔案可能重蹈大型網站地圖過載的覆轍，並浪費模型的上下文。理想的起始清單應簡短、具事實性且穩定：標準說明文件、產品介紹、政策，以及無論今天或未來都能如實回傳預期內容的參考頁面。
這個前置階段應包含三項檢查。第一，確認每個網址都是標準版本：是你真正希望模型讀到的版本，而非測試、草稿或重複路徑。第二，當網站能穩定提供時，優先採用 Markdown 版本，但不要自行捏造會回傳錯誤的 .md 網址，因為清單上出現 404 比缺少條目更糟糕。第三，決定哪些資源真正屬於次要，因為將過多項目標記為 Optional 會降低檔案實用性，而標記過少又會讓短上下文讀者不堪負荷。任何含有憑證、或指向可執行檔或內嵌資料協定的網址，都應在進入表單前就剔除；產生器會拒絕這些項目，但提前過濾能縮短草稿審閱時間。
如何在本機從網站產生 llms.txt
產生器完全在瀏覽器中執行。以下是操作者從頭到尾可以預期的流程。
- 開啟 llms.txt Generator 並輸入網站或專案名稱。該字串會成為必要的 H1 標題。
- 加入一段選擇性的引文摘要，以一兩句話概述網站，再加入任何你希望讀者在連結區段之前看到的自由格式細節說明。不需要的話可留空。
- 建立 H2 區段標題，並只加入各區段應包含的標準連結。每個列表項目的核心必須是一條連結；你可以在連結後加上冒號與簡短說明，解釋該資源的內容。
- 決定哪個區段（如有）應命名為 Optional。將真正屬於次要的資源移入該區段，並把最實用的連結留在上方。
- 產生 Markdown。輸出為依提案順序排列、具有確定性的純文字：H1、若有則為摘要、若有則為細節說明，接著是 H2 連結區段。
- 審閱 Optional 區段與每一條說明。把檔案當作內容而非機械產物來閱讀，確認標題與摘要仍與網站相符。
- 將結果複製到剪貼簿或下載為 llms.txt。下載檔名是固定的；若需不同檔名，請自行選擇儲存路徑。
- 在發布前，將編輯後的檔案貼回驗證模式。確認驗證器沒有回報任何未處理的錯誤。
- 將最終檔案發布於 /llms.txt 或適當的子路徑，以純文字或 Markdown 形式提供服務，然後排程定期檢查每個列出的網址。
依提案順序驗證草稿
驗證與產生是兩種不同的模式，應分別看待。貼上的草稿會被檢查是否包含必要的 H1、是否遵循提案的標題順序、連結清單語法、是否有重複目標，以及大小是否在合理範圍內。驗證器會回報具體、以行為導向的問題與警告，且不會在背後擅自改寫檔案。它同樣不會擷取任何列出的網址，也不會聲稱連結資源是正確的，這讓來源驗證的責任留在它原本該在的地方。
有兩類警告值得再次檢視。經標準化後重複的網址會被回報而非靜默地重複出現，因為一份清單中若同一個目標出現兩次，等同告訴模型同一個頁面重要兩次。不安全的網址（包括任何內嵌憑證、或使用可執行檔、內嵌資料協定的網址）會在序列化時被拒絕，因此在驗證階段抓到這類情況，代表草稿來自產生器之外，需要同樣的審查。驗證成功僅代表草稿符合產生器對現行提案的解讀；這不是對更廣泛廠商支援的認證，提案與生態系都可能演進。在建立任何依賴精確語法的自動化之前，請重新檢視方法論與來源連結。
持續發布與驗證
發布是檔案開始代表網站的時刻，因此有兩項細節至關重要。路徑應為 /llms.txt 或清楚等效的子路徑，且內容類型應為純文字或相容於 Markdown 的格式，讓消費者能在不需協商的情況下擷取。檔案上線後，應衡量你自己的工具與工作流程是否真的使用了它，並不要單純以發布作為搜尋或引用成效改善的證據。
驗證是多數檔案最常忽略的部分。當頁面搬移、改名，或被身分驗證機制擋下時，參考清單就會漂移。應排程定期檢查每個連結的網址，替換任何不再回傳預期內容的連結，並刪除已失去標準網址身份的連結。提案仍處於發展階段，發布者的職責是保持這份策展地圖的誠實，而非等待生態系支援來背書它。如果你需要更深入的提案區段排序說明，以正確順序為網站產生 llms.txt 這份指南與本工作流程搭配閱讀相當合適，而 DeveloperHub 實作文件 以及 AnswerDotAI 參考儲存庫 在你想了解他人如何組織自家檔案時，是很好的延伸閱讀。
llms.txt 檔案刻意保持簡短，而 llms.txt Generator 的價值在於它所強化的紀律：一個必要的 H1、具有確定性的 Markdown 順序、一個明確的 Optional 區段，以及一次能抓出人工撰寫草稿常見錯誤的驗證流程。將這些機制結合編輯策展與定期連結檢查，你就能得到一份真正兌現提案承諾的檔案：對網站最實用資源的簡潔、可審閱 Markdown 概覽，不附帶任何關於爬蟲採用率或排名提升的聲明。
如需更深入的說明，請參閱 如何在 WordPress 中建立 Robots.txt 檔案。