llms.txt 的正確定位，是一份需要維護的公開導覽文件：清楚列出重要頁面與用途，每個連結都回到網站上的正式內容。這適用於想給語言模型一份內容索引的網站；Google Search 目前不使用它，所以把它加進去之前，先確認頁面本身的可抓取、索引、canonical 問題已經解決。本文提供的是可以直接判斷的東西：它處理哪一個問題、和 robots.txt／sitemap 的責任分工、建立與維護的實際成本，以及哪些結論推不出來。
用建築物來想：robots.txt 是門禁卡機，sitemap 是消防逃生圖，llms.txt 比較像大廳那塊「一樓服務台、三樓會議室」的樓層導覽牌。導覽牌寫得再清楚，門禁刷不過去的樓層還是上不去——它提供方向，不提供權限。
Google 目前的官方說明明確表示，Google Search 不使用 llms.txt，它不會對搜尋曝光或排名產生正面或負面影響。所以這份文件取代不了可抓取內容、內部連結、robots.txt 或 sitemap。
llms.txt 是內容導覽提案，不取代 crawler 控制規則。
llms.txt 到底處理哪一個問題
llmstxt.org 的 proposal 把 llms.txt 設計成網站根目錄的精簡內容索引；依該提案的目標，它可能讓需要處理大量網站資料的工具更快理解網站的主題、重要頁面和頁面用途，但這是提案意圖，不是所有工具都會實際變快的量測結果。提案把它描述為根目錄的 Markdown 文件，通常包含網站名稱、簡短說明，以及帶有描述的連結清單。所有模型、搜尋引擎或 crawler 是否讀取與遵循，仍需按產品查證。
這個區分很重要，因為它決定了你會不會把時間花錯地方。llms.txt 提供的是「可以先看哪些公開文件」的導覽——頁面本身的可存取性，它一點都沒有處理。就本文的驗收判讀而言，可推論把頁面列入不等於索引指令；依 Google 對 sitemap 沒有索引保證的說明，列出頁面也不能支持「已索引」結論。讀者仍然需要檢查該頁的 HTTP 狀態、內容品質、canonical、robots 指令與實際公開範圍。
先分清楚提案、標準與官方支援
在開始投入維護時間前，先把證據分成三層：
| 問題 | 目前可以確認的事 | 不能直接推出的事 |
|---|---|---|
| 格式來源 | llmstxt.org 將其稱為 proposal，並提供 Markdown 範例 | 本文未找到 Google Search 將它列為必要文件的官方要求 |
| Google Search | Google 官方文件說 llms.txt 不會影響 Google Search 的正面或負面曝光、排名 | 不能說它能提升 Google AI Overviews 或一般搜尋排名 |
| 其他 AI 產品 | 各產品是否讀取、如何讀取，需看該產品當下文件或實際證據 | 不能把一個產品的行為推廣到所有模型 |
| 網站治理 | 它可以成為公開內容導覽與版本維護的一層 | 不能取代原始頁面、robots.txt、sitemap 或權限控制 |
Google 的 AI optimization guide 目前指出 Google 忽略 llms.txt，不會因此改變 Google Search 的曝光或排名。Google 更新紀錄 在 2026 年 6 月 15 日也記錄了這項澄清。這是 Google 的產品邊界，不是對所有 AI 服務行為的普遍判決。
如果你引用提案本身，應直接標示它是提案。llmstxt.org 的 proposal 說明根目錄位置、Markdown 結構和連結描述的設計目的，但它不能代替每個平台自己的 crawler 政策。寫作時不要把「有一個格式提案」改寫成「所有 AI 引擎都支援」。
llms.txt 與 robots.txt、sitemap 的分工
三個檔案容易被混寫，實際上要回答不同問題：
| 工具 | 主要問題 | 適合放什麼 | 不應承擔什麼 |
|---|---|---|---|
robots.txt | 特定 crawler 是否可以請求 URL | crawler 規則與 sitemap 位置 | 不負責挑選內容摘要，索引結果仍要另查 |
sitemap.xml | 網站有哪些可供發現的 URL | URL、可選的更新欄位與 sitemap index | 協助發現，不直接證明抓取、索引或 AI 引用 |
llms.txt | 哪些公開文件值得先讀，如何快速定位 | 人和工具都能讀的頁面導覽與描述 | 不控制 crawler，也不替代頁面證據 |
Google 的 robots.txt 介紹 說明，robots.txt 控制 crawler 能否存取 URL，但不是隱藏頁面的完整方法；sitemap 文件 則說 sitemap 有助於發現與有效率抓取，但沒有索引保證。這些功能不能因為都放在網站根目錄，就被視為同一個控制面板。
什麼情況值得維護
是否建立 llms.txt，應根據維護成本和內容治理需求決定，而不是根據「大家都應該有」的說法。可以先問四個問題：
- 網站是否有一組穩定、公開、希望被人快速找到的核心文件？
- 是否有人能在產品或文件改版時同步更新連結與描述？
- 是否能把每一個條目回溯到真正的 canonical 頁面，而不是另造一份無法驗證的摘要？
- 團隊是否接受它目前對 Google Search 沒有正面或負面排名作用？
如果四個答案都是否，先改善公開頁面的內容、內部連結、robots.txt、sitemap 和標準網址，通常更直接。這裡的「更直接」是根據工具責任所做的編輯判斷，不是「一定帶來曝光」的結果保證。
若答案多為是，可以把它放進內容發布清單。每次刪頁、改 slug、調整產品能力或變更內容負責人時，一併檢查連結是否仍可用。不要把它變成由不同團隊各自維護的第二套內容真相。
一份可維護的內容結構
以下是依公開提案整理的最小示意，不代表 Google 或其他平台的必要格式：
# EthorX
> EthorX 提供 AI 搜尋可見度與內容治理相關服務與觀測方法。
## 核心文件
- [AI 搜尋可見度](https://ethorx.com/blog/ai-visibility): 說明可觀測性、引用與限制。
- [GEO 服務](https://ethorx.com/geo/): 說明服務範圍、交付與證據邊界。
## 產品與方法
- [Otlex](https://ethorx.com/otlex/): 產品頁，能力以正式頁面最新內容為準。這個示意有四個治理重點。第一，連結指向公開頁面，不在檔案內複製一段可能過期的產品承諾。第二，描述只說頁面能驗證的主題，不把「可能被讀取」寫成「一定被引用」。第三，正式網址仍由網站的路由與 canonical 決定。第四，產品能力要回到正式的公司資訊與產品頁核對，不能因為想讓模型理解，就把未確認功能放進文件。
不要在 llms.txt 放入 API key、未公開客戶資料、內部後台網址、尚未確認的案例數字或只供 crawler 的祕密提示。公開文件的風險與一般公開網頁相同，任何可連到的內容都應先通過公開範圍審查。
建立後如何驗收
驗收目標是確認「這份公開文件可被讀到、內容仍正確」，不是證明某個模型已使用它。可以依以下順序記錄：
- 用 HTTPS 直接請求
/llms.txt，保存檢查日期、HTTP 狀態和內容版本。 - 檢查每個連結是否指向預期的公開頁面，並記錄 200、重新導向、404 或需要登入的狀態。
- 逐頁核對 title、canonical、主要主張和頁面可見內容，不要只看
llms.txt的描述。 - 檢查 robots.txt、sitemap 和內部連結是否仍與頁面治理策略一致。
- 若要觀察某個 AI 產品是否讀取，先指定產品、日期、查詢、裝置和取樣方式，再把「未觀測到」記為無資料，不要寫成未讀取。
- 若網站有版本控制，將每次修改的原因、變更連結和審核人記在內容紀錄中。
「頁面能被連到」與「模型真的讀過」是不同證據。沒有產品端 log、官方說明或可重複的觀測，就只能說文件已公開，不能聲稱它帶來引用、排名或生成答案的變化。
常見問題
llms.txt 會提升 Google AI Overviews 的出現機率嗎？
Google 的 AI optimization guide 明確寫出 Google 忽略 llms.txt，不會由此改變 Search 的曝光或排名——這句話在官方文件裡，不是推論。Google AI features 仍以可抓取、可索引和符合摘要資格等既有條件為基礎，顯示與否也不保證。
llms.txt 可以取代 robots.txt 嗎？
robots.txt 是 crawler 存取規則的一部分，llms.txt 是內容導覽提案——回到樓層導覽牌那個比喻：把牌子上的三樓擦掉，三樓的門還是開著的。要限制 Google crawler 存取，依 Google 的 robots 文件、noindex 或權限控制選方法。
llms.txt 可以列出尚未公開的文件嗎？
根目錄文件本身就是公開資產——任何人都打得開。連到未公開、需要登入或含敏感資訊的內容，等於在公開的牌子上寫出那扇門在哪裡。某一頁不該公開的話，先處理權限和公開狀態。
我應該把所有文章都放進 llms.txt 嗎？
提案的價值在於整理重要、穩定且可驗證的內容。複製一份 sitemap 進去，維護成本跟著整站走，導覽效果卻沒有增加——先列出讀者理解網站主題所需的核心頁面，再由內容負責人定期檢查連結、描述和內容狀態。
沒有 llms.txt 就不能做 AI 搜尋優化嗎？
Google 官方目前不把 llms.txt 當成 Google Search 的正負面訊號——沒有它，你並沒有少掉什麼。AI 搜尋內容治理從公開頁面、內部連結、可抓取文字、來源歸屬、結構化資料與可觀測的查詢紀錄開始就好，實際產品行為分平台驗證。
把文件放回內容治理
要採用 llms.txt 的話，我會把它當成一個小型、可撤回的內容治理實驗：責任寫清楚，記錄來源日期和連結狀態，再看維護成本合不合理。真正要小心的是它的副作用——一份看起來很完整的導覽檔，容易讓團隊覺得「AI 那邊處理好了」，而頁面本身的可抓取、索引、canonical 問題還原封不動地躺在那裡。
如果你要整理跨頁面的 AI 搜尋證據，EthorX 的 GEO 服務頁 和 Otlex 產品頁可作為下一步閱讀入口；聯絡 EthorX 前，請先準備網站範圍、目標市場、要驗證的查詢，以及目前可取得的 Search Console、伺服器或產品觀測資料。這些連結是工作入口，不是對曝光或排名的保證。
查證邊界
本文依 2026-09-21 可取得的 Google Search 文件與 llmstxt.org 提案整理格式和支援界線。提案、搜尋文件與各產品對公開 Markdown 的處理方式可能更新；本文的範例是語法與內容治理示意，不是本網站已部署的檔案，也沒有以它推出排名、索引或 AI citation 結果。