首頁 / 技術文章 / llms.txt 真的有用嗎？從伺服器日誌看 AI 爬蟲怎麼抓網站
技術文章
llms.txt 真的有用嗎？從伺服器日誌看 AI 爬蟲怎麼抓網站
llms.txt 和 Markdown 到底值不值得維護，不用先看別人怎麼說，先看自己的伺服器日誌最實際。真的有 AI 爬蟲來抓、來源也能確認，再評估值不值得持續投入；如果觀察一段時間後幾乎沒有可驗證的請求，那就沒有必要為了跟風，額外增加一套維護成本。
提供 Markdown，與爬蟲真的使用，是不同問題
llms.txt 提案原始站是理解這項提案的起點；但採用提案與取得效益仍要分開判斷。OpenAI 的開發者文件頁面明確說明，在頁面網址後加上 .md 可取得 Markdown 版本，完整文件索引則見 llms.txt。這證明它提供另一種文件入口，尚不足以推論其爬蟲偏好哪種格式。
據 Search Engine Journal 報導，John Mueller 曾將 llms.txt 比作 keywords meta tag，並表示當時沒有 AI 服務使用、機器人也不會請求該檔案。這是有時間與情境邊界的說法，不宜直接拿來判定每個網站往後的流量。
同篇報導指出，Google Search 的指南將 llms.txt 列為生成式 AI 功能不需要的手段，Lighthouse 卻在實驗性的 Agentic Browsing audit 中檢查它，並標示取得檔案時的伺服器錯誤。這裡引用的是媒體轉述，未核對原始指南。較合理的解讀是：搜尋曝光與 agent 使用便利性需要分開評估，工具檢查也不能直接當成自然需求。
先放最小探針，確認日誌涵蓋哪些請求
若網站尚未提供 llms.txt，建議先檢查既有日誌是否有人探測該路徑，再決定是否放置最小版本。初期只整理網站說明與少量重要內容入口，指向實際存在的頁面即可；不必同時替全站建立 Markdown。這個檔案的用途是測量需求，不應預先冠上提升 AI 引用的效果。
記下探針上線時間、內容更新與自行測試時段。若也要測試 Markdown，先選維護成本可控的內容，列出 HTML 與 .md 的對應網址，並記錄哪些入口提供了連結。未提供、未連結的版本與可正常取得的版本，應分開解讀，避免把難以發現誤判成沒有需求。
開始統計前，請維運人員確認存取日誌的範圍：是否涵蓋 CDN 或反向代理、快取命中的請求是否留下紀錄、保留期間是否完整，以及有沒有抽樣。若無法確認，就將結論限定為目前這份日誌未見請求，不能擴大成整個網站完全沒有流量。
篩選 llms.txt 與 .md，保留回應結果
建議在既有日誌查詢工具中依下列順序處理，不必為了這次評估更換分析平台。重點是查詢條件能重複使用，而且能從統計結果回到原始紀錄。
- 限定網站網域與觀察期間，統一時間基準；查詢用的路徑欄位移除查詢參數，原始請求網址另行保留。
- 分別篩選路徑恰為 /llms.txt，以及路徑以 .md 結尾的請求。若網站使用其他 Markdown 路徑，另外列入實際清單。
- 保留時間、請求方法、路徑、回應狀態、User-Agent 與可供核對的來源 IP；將缺少欄位的紀錄標記出來。
- 拆開成功回傳、重新導向、找不到檔案、拒絕存取與伺服器錯誤，再標記部署驗收、監控與人工測試流量。
不要只交出一個總請求量。判读時，請求不存在的 .md 路徑應列為探索線索；成功取得內容則另列為可用性訊號。若只有檢查回應資訊的請求，也不要與實際要求內容本文的請求混算。這些分類有助於區分對方在找入口、檢查服務，或嘗試取得內容。
User-Agent 用來初步分類，身分需要另外驗證
建議先把 User-Agent 分成聲稱為 GPTBot、OAI-SearchBot 等 AI 爬蟲、Lighthouse、一般瀏覽器與未知 agent。報表欄位應寫成聲稱身分，避免把可自行填寫或偽造的名稱直接當成驗證結果。辨識工作可搭配從存取紀錄辨識爬蟲的操作方向整理。
接著依各業者可核對的驗證方法檢查來源，例如比對其公布的 IP 範圍；若方法涉及 DNS 反查，還應核對正向解析是否回到原 IP，並確認網域歸屬。不要替所有爬蟲套用同一套規則，也不要猜測允許的網域或 IP。找不到可靠依據的，保留為未驗證來源。
Lighthouse 與自行執行的檢測應獨立計算，否則評估工具本身產生的請求可能被誤認為採用需求。一般瀏覽器與未知 agent 也先保留，不必急著歸入人類或 AI。對文件團隊而言，這些紀錄可以成為詢問使用者需求的線索，卻還不足以宣稱特定 AI 服務已採用。
比較同一來源對 HTML 與 Markdown 的存取
完成分類後，將同一個已驗證來源、同一觀察期間、同一篇內容的 HTML 與 Markdown 請求配對比較。建議同時列出各格式的成功請求量、涵蓋文章、出現日期，以及兩種格式都被請求的文章。不要拿全站 HTML 流量與少數試行頁面的 .md 流量直接相比。
若需要單一指標，可將 Markdown 成功請求量除以相同內容配對中 HTML 與 Markdown 的成功請求總量，作為格式使用占比；分母為零時標記無資料。同時保留原始量，避免少量請求形成看似突出的比例。llms.txt 是入口檔案，應另列，不併入文章格式的比較。
這個占比適合描述存取分布，不適合直接命名為格式偏好。解讀時仍應檢查入口連結、發布時間與存取規則是否一致。即使同一來源先請求 llms.txt、再請求 .md，也宜記錄為存取順序，不能僅憑順序認定前者導致後者，更不能推論內容已進入答案。
| 觀察結果 | 建議判讀 | 後續動作 |
|---|---|---|
| 只有自行測試或 Lighthouse 請求 | 檢測流量尚不足以支持外部需求 | 保留最小探針，暫不擴充 |
| 未驗證來源反覆請求 .md | 有待核對的使用線索 | 先查來源與回應結果 |
| 已驗證来源持續取得 Markdown | 可支持特定來源存在存取需求 | 評估同步成本與試行範圍 |
| 請求多為找不到檔案或伺服器錯誤 | 尚未形成正常內容交付 | 檢查路徑與服務狀態後再觀察 |
觀察期與停損條件，應在看結果前決定
建議事先選定連續 N 週作為觀察期，N 依內容更新節奏與日誌保留能力決定，不必假設存在通用門檻。可採用的決策規則是：期間內若無已驗證的 AI 爬蟲請求，且沒有使用者明確需要 Markdown，就不擴大投入；未知來源則留待查證，不先算成成效。
反過來，即使已有持續請求，也應先估算同步、失效連結與存取規則的維護成本。編輯判斷上，能由同一內容來源自動產生 Markdown 的文件站，比需要人工維護另一份全文的媒體更適合試行。但有需求只是投入條件，並不保證收益大於成本。
權限管理也要獨立處理。RFC 9309規範 robots.txt 的爬蟲存取規則；因此，提供內容格式與設定存取規則應視為不同工作。新增 .md 路徑時，建議重新檢查相關規則，不要把 llms.txt 或 Markdown 當成允許、禁止讀取的替代機制。
請求紀錄能支持維護決策，不能證明引用成效
目前所引用的來源沒有量化測試，足以判斷 Markdown 是否改善摘要品質或提高引用率，也未說明 GPTBot、OAI-SearchBot 是否優先選用 .md。評估時應把成功取得內容與搜尋答案中的採用分開；可參考拆解 AI 搜尋取得網頁的不同關卡，避免用前段訊號代替後段效果。
適合擴大維護的訊號，是可核對且持續的存取需求，加上可接受的內容同步成本。若日誌涵蓋完整、入口可取得，觀察期內仍沒有這類證據，就先維持最小探針，或停止額外維護。下一次重新評估，應由新的請求或明確使用需求觸發，而不是再一次公開表態。
常見問題
日誌裡沒有 llms.txt 請求，就可以不做 Markdown 嗎？
可作為暫不擴大投入的依據，但先確認日誌完整、入口可取得，以及觀察期合理。若使用者另有明確的 Markdown 需求，仍應獨立評估，不能只看爬蟲流量。
看到 GPTBot 或 OAI-SearchBot 的 User-Agent，就算驗證成功嗎？
不應直接計入已驗證來源。建議依業者提供的身分驗證方式核對來源；無法核對的紀錄保留為聲稱該身分，並與已驗證流量分開。
Lighthouse 請求 llms.txt，可以算 AI 使用需求嗎？
建議列為檢測流量。據 SEJ 報導，相關檢查屬於實驗性的 Agentic Browsing audit；這不足以證明外部 agent 持續使用內容，也不能推論 Google 搜尋採用了該檔案。
Markdown 的請求占比提高，代表 AI 引用效果變好了嗎？
不能如此推論。這項指標只用來比較所選內容與來源的存取分布；目前引用的來源未提供足以證明摘要或引用效果提升的測試。