一份能避開最常見產生錯誤的 llms.txt 草案，只包含一行以專案或網站名稱命名的 H1、可選的引文摘要、可選的非標題詳細內容，以及零個或多個 H2 段落，其中每個 Markdown 清單項目都連結到一個規範且高價值的 URL，且順序與提案文件記載完全一致。大多數產生錯誤來自於跳過這個順序、挑選含有憑證或非 HTTP 協定的 URL、將 llms.txt 視為 sitemap 的替代品，或是讓 Markdown 分隔符號與控制字元破壞結構。一份參考的 llms.txt 檔案範例能讓這些錯誤一目了然，因為每個有問題的元素都是一行你可以大聲朗讀並判斷的內容。llms.txt Generator 正是為了這個審查時刻而存在:它只接受提案所定義的項目，掌控順序、拒絕不安全的 URL、標準化對 Markdown 敏感的文字，並回報重複的標準化 URL，而不是默默重複新增條目，因此你所複製或下載的草案是你在發布到 /llms.txt 之前，確實可以親自檢視與編輯的內容。
llms.txt 檔案範例能及早揭露的錯誤
一份參考的 llms.txt 檔案範例，是最快看出自己草案哪裡出錯的方式，因為這個格式是純文字，每一行都是一個決策。提案描述的是一個精簡、可預測的形狀:一個 H1、一個可選的引文摘要、可選的詳細內容，然後是 H2 段落的 Markdown 清單項目。當範例缺少其中一個部分，或含有不該存在的多餘項目時，你可以立刻看出來。
範例會揭露的常見疏失包括:H1 出現兩行而非一行，迫使解析器猜測哪個標題才是正確的;將描述放在 H1 之前，破壞了文件記載的順序;將 Optional 區段當作主要文件的標題外層，而提案其實將該名稱保留給消費者可以略過的次要資料;以及含有憑證或使用提案拒絕協定的 URL。
文件化的 Markdown 順序，以及跳過它的錯誤
在這個格式中，順序並非美觀問題。這個格式是設計來讓一般解析器可讀、並且對語言模型可預測，因此檔案的流程是 H1，接著是摘要，然後是詳細內容，再來是 H2 連結段落。如果你重新排列這些區塊，檔案在瀏覽器中仍然能以 Markdown 呈現，但你會失去消費者所期待的可預測性。一個實用的範例會讓每個區塊都留在它應有的位置，讓審查者能夠線性地掃讀。
| 位置 | 元素 | 必填 | 備註 |
|---|---|---|---|
| 1 | 含專案或網站名稱的 H1 | 是 | 僅能有 1 個 |
| 2 | 引文摘要 | 否 | 通常為兩到三句 |
| 3 | 非標題的詳細內容段落 | 否 | 出現在任何 H2 之前 |
| 4 | 含 Markdown 清單項目的 H2 段落 | 建議至少 1 個 | 每個項目都必須包含一個連結 |
| 5 | 名為 "Optional" 的 H2 段落 | 否 | 保留給次要資源 |
將位置欄視為不可更動;將可選元素是否存在視為你的編輯選擇。略過位置是入門範例最常揭露的錯誤。
如何在產生 llms.txt 時不再重蹈覆轍
避免重蹈上述覆轍的最乾淨方法，是使用一個能為你掌管結構的工具，而不是手動輸入 Markdown。llms.txt Generator 正是如此:它會序列化一個必要的 H1、可選的摘要、可選的詳細內容，以及有序的 H2 連結段落，並在檔案產生前輸出任何會違反規則的內容。
- 開啟產生器，將網站名稱輸入為唯一的 H1。
- 新增一段簡短的引文摘要以及任何非標題的詳細內容，保持文件化的順序完整。
- 只新增規範且高價值的 URL，放在明確的 H2 段落標題下，每個連結之後可選擇加上冒號與註記。
- 產生決定性的 Markdown，在複製或下載 llms.txt 之前，逐行閱讀 Optional 段落以及每一則註記。
- 將儲存的草案貼到驗證器中，確認標題順序、連結清單語法、重複的目標，以及在合理範圍內的大小，然後再發佈。
在步驟 3 中，工具會拒絕含有內嵌憑證的 HTTP URL、可執行的危險程式 scheme(例如 javascript:)，以及內嵌資料的 scheme(例如 data:)，因此不安全的目標永遠不會進入檔案。標籤、註記、標題與摘要都會經過標準化，讓一個孤立的反引號或控制字元無法破壞產生的結構，重複的標準化 URL 會被標示出來，而不是被默默地寫入兩次。
在真實範例中要留意的錯誤模式
當你將自己的草案與已知的 llms.txt 檔案範例比對時，最常出現四種錯誤模式。一個建構良好的範例能讓這些錯誤容易辨識，因為檔案短到可以從頭到尾讀完。
| 錯誤模式 | 看起來的樣子 | 產生器會怎麼做 |
|---|---|---|
| 重複的 URL | 同一個規範連結在一個或兩個段落中出現兩次 | 回報重複的標準化 URL，而不是將它寫入兩次 |
| 不安全的 scheme | 以 javascript:、data: 開頭，或含有密碼的連結 | 在序列化之前拒絕該 URL |
| Markdown 注入 | 標題、摘要或註記含有散落的反引號或井字號 | 標準化文字，使結構保持完整 |
| 區段位置錯誤 | H2 段落出現在 H1 之前，或出現多個 H1 行 | 在產生時強制執行文件化的順序 |
你也應該留意將 Optional 標題用於主要資源的情形。提案將該區段定義為放置次要資料之處，當消費者需要較短的脈絡時可以略過。將你最重要的文件標記為 Optional 是編輯上的錯誤，而不是產生器的錯誤，沒有任何自動化工具能替你決定哪些來源真正屬於次要。
在發佈前驗證草案
產生只是工作流程的一半。在你複製或下載編輯過的檔案之後，將它貼到同一個工具內建的驗證器中。驗證器會回報具體、以行為單位的問題與警告:缺少或重複的 H1、順序錯亂的標題、錯誤的連結清單語法、重複的標準化目標，以及檔案大小超過合理範圍。它不會在背後重寫檔案、不會去追蹤任何列出的 URL，也不會聲稱連結的資源是準確的。
一份乾淨的驗證報告代表草案符合目前提案的文件化解讀。它並非更廣泛廠商支援的憑證，因為 llms.txt 是一種新興的格式，生態系仍會演進。在你建立依賴精確語法的自動化之前，請重新檢查方法論與來源連結。如需深入參考網站如何將 llms.txt 與文件工具整合，請參考 DeveloperHub llms.txt 實作文件。
llms.txt 與 robots.txt 和 sitemap.xml 的定位關係
其中一個代價較高的錯誤，是將 llms.txt 視為它無法取代的檔案的替代品。每個機制都有其各自的功能，而混淆角色正是「AI 可見度」專案悄悄變成重複工作的方式。
| 檔案 | 用途 | 消費者 | 它無法做到的事 |
|---|---|---|---|
| robots.txt | 為參與的爬蟲表達抓取偏好 | 參與的爬蟲 | 單獨授予或封鎖個別頁面的存取 |
| sitemap.xml | 盤點可建立索引的 URL 以供搜尋探索 | 搜尋引擎 | 描述頁面內容或挑選規範版本 |
| llms.txt | 提供策展過的 Markdown 總覽與一份簡短的高價值參考清單 | 自願性消費者 | 強制爬蟲抓取、覆寫身分驗證，或從訓練中移除頁面 |
結構化資料描述的是實體與頁面內容。llms.txt 則提供策展過的 Markdown 總覽，以及一份針對推論時使用的高價值參考簡短清單。要避免的錯誤是混淆這些角色，因為只有當你把每個 URL 都倒進去時，策展過的簡報才會與 sitemap 做同樣的事，但這會浪費消費者的脈絡，並重蹈大型 sitemap 已造成的過載。
以內容、而非 SEO 產物的角度審視已發佈的檔案
驗證通過後，以純文字或 Markdown 相容的內容類型，將檔案發佈到 /llms.txt 或適當的子路徑。以人類審查者的角度讀回它:確認標題與摘要與網站相符、每個連結都是規範的、註記事實正確、可選的資源確實屬於次要，且沒有出現私人或測試環境的 URL。
定期驗證列出的連結是否解析到預期的內容，因為該檔案是靜態快照，頁面會移動、重新命名或下架。策展的品質比長度更重要。優先選擇規範的文件、產品說明、政策以及穩定的參考頁面，並在你的網站能穩定提供時連結到 Markdown 版本，但不要捏造會回傳錯誤的 .md URL。
發佈 llms.txt 並不會強制爬蟲或助理去請求它。它無法授予受封鎖頁面的存取權、無法覆寫身分驗證、無法將內容從模型訓練中移除，也無法證明 AI 回答會引用你的網站。要判斷你的工作流程是否真的使用了這個檔案，誠實的衡量標準是你的工具與流程是否真的讀取了它;單純發佈本身並非搜尋或引用改善的證據。如需一份將這些步驟與每一步編輯審查結合的端對端檢查清單，請參考 如何透過編輯審查產生 llms.txt 檔案 的指南。