home / notes / llms.txt 該不該做：先分清搜尋爬蟲、AI 代理與掃描流量
Note
llms.txt 該不該做：先分清搜尋爬蟲、AI 代理與掃描流量
為機器優化網站，應先分清要服務搜尋爬蟲、AI 代理，還是管理訓練／掃描爬蟲的存取。我的判斷是，llms.txt 的爭論有很大一部分來自目標混淆：被搜尋引用、被代理順利使用、控制網站負載，需要不同的證據與工具。
Google Search 與 Lighthouse 回答的是不同問題
討論 llms.txt 時，很容易把問題縮成有用或沒用。但對創辦人而言，有用必須接得上具體結果：內容被引用、開發者順利完成整合，或網站少承擔無效請求。把這些結果合併成機器友善，就會讓一個檔案背負它未必能完成的任務。
依據 Search Engine Journal 的報導，Google Search 將 llms.txt 列為生成式 AI 搜尋功能不需要的做法；Chrome Lighthouse 卻在 Agentic Browsing 類別中加入實驗性的 llms.txt 稽核。這是第三方對產品文件的整理，不能把其中一邊的訊號擴張成 Google 所有產品的共同立場。
我認為兩者可以同時成立。搜尋端回答的是參與搜尋功能是否需要這個檔案；代理端關心的是網站有沒有提供方便理解與導覽的入口。通過代理瀏覽稽核，不能直接推導成搜尋排名會上升；搜尋端說不需要，也不足以證明代理使用它毫無價值。
三種機器讀者，對應三種產品目標
我會依任務把機器讀者分成搜尋爬蟲、AI 代理，以及訓練／掃描爬蟲。這是決策用的分類，不是互斥的身分認證。同一個助理產品可能先搜尋，再讀取文件；大量掃描的請求，也不能光憑行為就斷言一定用於訓練。分類的用途，是釐清網站希望換到什麼結果。
| 機器讀者 | 網站追求的結果 | 優先處理的層次 | 證據與可能代價 |
|---|---|---|---|
| 搜尋爬蟲 | 內容進入搜尋流程並有機會被引用 | 可存取性、內容與資訊架構 | Google Search 的說法有報導可循；不能據此承諾其他產品的效果 |
| AI 代理 | 正確理解文件並完成使用者任務 | 導覽索引、內容表示法 | 有文件站實例與實驗性稽核；另有同步維護成本 |
| 訓練／掃描爬蟲 | 讓允許的存取符合資源預算 | 爬取規則、快取與流量控制 | 有 Cloudflare 的流量資料；限制過廣可能妨礙想服務的用途 |
對內容網站，我會先問被引用能帶來什麼價值；對 API 產品，我更在意代理能否讀懂文件並完成整合；對負載吃緊的網站，優先事項可能是控制請求成本。這些目標可以並存，但不適合共用一個成功指標。請求增加可能只是成本增加，無法自行證明曝光或產品採用變好。
這也延續了把爬蟲流量與能見度拆開評估的思路。若團隊只問機器來了多少次，就容易鼓勵更多抓取；若目標是代理成功使用產品，真正有意義的問題應是它拿到的資訊是否足以完成任務。流量與成果之間，還需要證據連接。
llms.txt 的合理用途，是降低代理找資料的阻力
llms.txt 提案主張以 Markdown 檔案提供有助代理使用網站的資訊。它的立論是，HTML 把正文包在導覽、廣告與 JavaScript 裡，轉回乾淨文字既困難又不精確；有限的上下文空間，也讓多餘文字產生時間與 token 成本。這說明提案想解決的問題，並不等於已證實所有代理都會因此受益。
實際的供給端例子是 OpenAI 開發者文件：頁面提供 llms.txt 完整文件索引，並說明在頁面網址後加上 .md 可取得 Markdown 版本。這能證明文件站提供了另一種讀取入口與表示法，卻不能證明各家代理會優先選它，也不能證明網站因此更常被引用。
從目前公開資訊來看，我會把這類設計視為文件可用性的候選投資。假如產品需要 coding agent 讀懂 API，減少找錯頁面或讀入無關內容的機會，就有合理的產品動機。支持這個動機的證據，比保證能提高搜尋曝光更直接；但任務成功率到底改善多少，目前提供的來源沒有答案。
對文件很多、更新頻繁的產品，導覽入口可能值得維護。對內容不多、頁面已清楚易讀的個人網站，我則不會把 llms.txt 放到所有工作之前。若主要代理根本不讀這個入口，或原本就能可靠解析頁面，它帶來的額外價值可能很有限。採用與否，應取決於它能否解決具體阻力。
爬取規則、導覽、內容格式與負載，不能互相代替
機器存取還有另一套制度。RFC 9309 定義 Robots Exclusion Protocol，也就是 robots.txt 所依循的正式規範，狀態為 Proposed Standard；llms.txt 則仍是提案。兩者處理的問題不同，不能因為檔名相似，就把導覽資訊當成爬取規則。
在產品設計上，我會分開看爬取規則、導覽索引、內容表示法與基礎設施負載。robots.txt 表達爬取規則，llms.txt 提供導覽資訊，Markdown 是內容的表示方式；快取與流量控制則處理請求帶來的資源消耗。多提供一份乾淨文字，並不能直接回答網站願意承擔多少請求。
Cloudflare 表示，其網路上 32% 的流量來自自動化流量，其中包含搜尋爬蟲、正常運作檢查與廣告網路等，不能全部算成 AI 流量。它也指出，AI 機器人可能大量平行請求，存取冷門內容，甚至依序掃描整站。這些是該公司網路範圍內的資料與描述，不能直接套成每個網站的流量組成。
這可能代表，以熱門頁面為重心的快取安排，未必適合廣泛掃描的請求。對網站經營者而言，是否開放與如何承擔成本，必須一起判斷。若目標是控制負載，投入 llms.txt 未必碰得到問題核心；若目標是讓代理使用文件，一概限制機器存取又可能傷到原本想服務的用途。
人與機器的取捨，常發生在維護成本與成效歸因
我認為，提供機器入口不必然要求犧牲人的閱讀體驗。若同一份原始內容能產生 HTML 與 Markdown，理論上可以保留適合人的版面，同時減少另一種表示法的維護負擔。但這是架構上的推論；OpenAI 文件提供兩種表示法的事實，並沒有揭露它背後的產製流程。
真正的代價可能出現在內容分流之後：人讀到的價格、限制或 API 說明，若與代理讀到的版本不同，錯誤就可能進入使用者決策。這也是我偏向共用內容來源的理由。至於提供不同內容是否涉及搜尋引擎的 cloaking 判定，現有來源不足以回答，不能把另一種格式當成任何做法都安全的保證。
另一個代價是歸因。如果同時改動頁面設計、內容結構與機器入口，後續成效就很難拆解。我會把人類訪客的轉換、代理任務的完成情況、搜尋引用與請求成本分開評估。這與從資訊架構理解 AI 搜尋的方向一致：單一檔案很難代表整個網站是否適合被使用。
是否投入 llms.txt，要看它能改變哪個結果
接下來我更在意的訊號，是代理產品是否明確說明如何使用 llms.txt、不同表示法是否影響任務完成，以及額外請求能否換回產品價值。現有資料還不足以量化 llms.txt 對引用率的影響，也沒有交代各家代理是否優先讀取 Markdown。實驗性稽核可以提示方向，不能代替這些答案。
我的判斷是：以 Google 搜尋曝光為主要目標時，不應把 llms.txt 當成必要投資；希望代理讀懂並使用產品時，它值得依文件複雜度與維護成本評估；問題若是掃描負載，資源就該回到存取與基礎設施。創辦人最需要先決定的，是哪種機器行為值得服務，以及願意為那個結果付出多少成本。
常見問題
只想提高 Google AI 搜尋曝光，需要做 llms.txt 嗎？
依據 Search Engine Journal 對 Google Search 指南的報導，生成式 AI 搜尋功能不需要 llms.txt。因此不宜把它當成提高曝光的必要投資；這個說法也不能直接外推到其他搜尋或助理產品。
提供 llms.txt 或 Markdown，就能讓 AI 代理正確使用產品嗎？
不能保證。它們可以提供導覽與另一種內容表示法，但目前來源沒有說明各家代理是否優先使用，也沒有量化任務成功率的提升。我的判斷是，文件型產品可以評估這項投資，但應以代理能否完成任務衡量價值。
llms.txt 可以代替 robots.txt 或控制爬蟲負載嗎？
兩者處理不同問題：llms.txt 提案著重協助代理使用網站，robots.txt 的正式規範處理爬取規則。若目標是控制負載，還需要評估快取與流量控制，不能只靠導覽檔案。