Google 9/18 親手拆掉 llms.txt 最後一根支柱：13.7 萬站實測 97% 零讀取，AI 檢索爬蟲只佔 1.1%

台灣時間 9 月 18 日凌晨，Google Search Relations 的 John Mueller 在 Bluesky 一句話，把過去一年「我的 llms.txt 真的被 AI 抓走了」的證據打了對折。他指出網路上已出現一批「everything llms.txt」目錄站，會掃描所有網域、把找到的檔案全部連結出去；爬蟲爬到這些目錄，就順著連結把你的檔案抓一次。翻成人話：你 log 裡那筆抓取，很可能不是 AI 平台找上門，而是它在爬別人的清單時順手撿到。

llms.txt 是 Answer.AI 共同創辦人 Jeremy Howard 在 2024 年提出的單一索引檔規格：放在根目錄、用 Markdown 告訴模型你是誰、哪幾頁最重要。SEO 產業花 18 個月把它做成產品——Wix 直接生成，Framer 與 Lovable 內建掃描，WordPress 外掛一鍵產出，GEO/AEO 工具把「有沒有它」寫進評分卡。但採用率跟效果從來對不上：SE Ranking 掃近 30 萬個網域，只有 10.13% 有這檔案，月流量 10 萬以上那一階反而更低（8.27%）。更難堪的是，他們用 XGBoost 預測網域被 LLM 引用的頻率，把這個變數整個拿掉，模型準確度反而上升——它給的不是訊號，是雜訊。

拿三個真正成功的標準對照：robots.txt、sitemap.xml、schema.org 都是「平台先公開承諾會讀，站長才做」。llms.txt 剛好倒過來，站長先做了 18 個月，至今沒有主流 AI 平台公開承諾會讀。Google 自己也裂成兩半：Search 文件的 Mythbusting 區塊寫著「你不需要建立新的機器可讀檔案、AI 文字檔、markup 或 Markdown」，Chrome 卻把 Agentic Browsing 稽核放進 Lighthouse 預設設定，其中一項就是檢查根目錄有沒有它。

這會直接打到台灣的中小企業與接案工作室：客戶下週很可能拿著 PageSpeed Insights 報告來問「為什麼我們 Agentic Browsing 只有 2/3」。這篇要解三件事——這一分值不值得修、修了誰會讀、以及真正會被 agent 讀到的那一層怎麼做，含工時與台幣估算。

事件細節：時間軸與完整數字

2025 年 7 月：Google 的 Gary Illyes 表示不支援、也沒有支援計畫。
2025 年 11 月 7 日：SE Ranking 發佈 30 萬網域研究，與 AI 引用零相關。
2026 年 5 月 7 日：Lighthouse 13.3.0 把 Agentic Browsing 放進預設設定，llms.txt 檢查進入每一次 PageSpeed Insights。
2026 年 5 月中：Google Search 發佈 AI 優化指南明說不需要這類檔案；不到一週後，Chrome 開始稽核它。
2026 年 6 月 15 日：Ahrefs 公佈 137,210 個網域的伺服器 log 實測。
2026 年 6 月 18 日：Lighthouse issue #17082——882 條連結、18 區段、零錯誤的合規檔案被 PSI 判為 fetch failed，CDN log 卻記錄 Google IP 成功抓取兩次。標為 P1 bug。
2026 年 9 月 18 日：Mueller 點名目錄站連鎖抓取，Barry Schwartz 當天收進 Search Engine Roundtable 日報。

Ahrefs 的 log 數字最殘忍。13.7 萬個網域中，28%（約 38,360 個）有合規檔案，其中 97% 在整個五月收到零次請求。剩下 3% 吃掉全部約 2.2 萬次請求，96% 來自機器人：SEO 稽核工具 21.7%、無法辨識流量 14.9%、一般爬蟲 13.1%、技術棧偵測 11.6%。真正決定你會不會被引用的 AI retrieval bot（OAI-SearchBot、PerplexityBot 等）只佔 1.1%，Slackbot 的連結預覽抓取還比 PerplexityBot 多。最後一擊是 404 資料：所有「請求了不存在的 llms.txt」流量裡，AI bot 佔比是零——沒有 AI 系統會主動敲一扇不存在的門，「不做就會被漏掉」這個前提從頭就不成立。

三類讀者的立刻行動

中小企業主

廠商拿 Agentic Browsing 分數報價時先問：「過去 30 天我的 log 裡有幾次 OAI-SearchBot 或 PerplexityBot 讀 /llms.txt？」答不出來就不要付。
把預算移到第一手內容：報價區間、施工天數、服務範圍、真實案例數字。這些才是被引用時會抓的東西。

接案工作室／開發者

Agentic Browsing 檢查 llms.txt、WebMCP、無障礙樹，外加 CLS。後三項才有技術門檻，而且對真人使用者同樣有效，那才是能開發票的工作。
Google 文件明說 agent 把無障礙樹當「主要資料模型」。補上程式可讀的 label、修掉被誤藏的互動元素，同時改善 agent 可用性與無障礙合規。
真要產 llms.txt 就當程式碼管理：納版控、限制編輯權、只連自己掌控的資源。Ahrefs 資料裡出現過一隻叫 prompt-injection-survey 的爬蟲，已經有人把它當提示注入面研究。

內容行銷人

別再把「llms.txt 已上線」寫進月報成果，改成「本月被 AI 引用的頁面數」與這些頁面的共同特徵。
會固定讀它的第一名 AI 類別是 agent 與 agentic 基礎設施（10.5%），其中 Claude-Code 抓取次數高過所有 AI 檢索爬蟲。客戶是開發者工具、API、SaaS 文件站就有價值；餐飲、裝潢、醫美、電商沒有。

影響對照表

對象	30 天內會發生	該做	不該做
中小企業	廠商拿 2/3 截圖加價	要求 log 證據	為單一稽核開專案
接案工作室	客戶要「AI 優化」卻說不清	賣無障礙樹修復＋結構化資料＋log 監控	賣 llms.txt 代建當主力
內容行銷	AI 可見度 KPI 失去依據	改用引用頁面數	把上線當成果
開發者工具／文件站	coding agent 抓取成長	維護 /docs 的 Markdown 版	當 SEO 手段行銷
電商／在地服務	幾乎沒變化	補第一手資訊與 schema.org	花錢做機器可讀檔

工具比較：誰在賣「AI 可見度稽核」

工具	核心功能	價格	適合誰
Chrome Lighthouse / PSI	Agentic Browsing 三項稽核＋CLS	免費	所有人，注意 #17082 誤判
Ahrefs Bot Analytics	依 user agent 拆解真實爬蟲請求	付費訂閱	需要證據反駁「AI 有在讀」
SE Ranking / SE Visible	AI 引用追蹤與跨平台可見度	付費訂閱	要交月報的代理商
Profound 等 AEO 平台	品牌在各 AI 平台的提及監測	付費（企業級）	有品牌聲量預算的客戶
自架 log 解析	從 Nginx／Cloudflare log 直接統計	約 NT$0 授權費	台灣中小企業與接案商

不會告訴你的事

一、Google 的「矛盾」其實不是矛盾，但結果一樣傷人。Search 文件談「被搜尋引擎發現」，Lighthouse 談「被 agent 操作」，技術上不衝突。問題是沒人向中小企業主解釋這個區別——他們只看到 Google 的工具給了紅字，然後付錢消除它。這是介面設計製造出來的需求。

二、稽核工具本身可能是錯的。issue #17082 的回報者做完所有該做的事，仍然 fail。更荒謬的是 PSI 跑 HeadlessChromium 146，而 Google 自己的計分文件寫著這類別需要 Chrome 150 以上。你可能在為一個跑在不支援環境的稽核付錢。

三、「反正做了沒壞處」不是真的。Ahrefs 明確指出這是安全風險：agent 被設計成信任這個檔案，而已有研究爬蟲在系統性地把它當提示注入面測試。一個沒人維護、內容過期、或被外掛自動改寫的 llms.txt，會誤導每一個讀到它的 agent。

四、12% 的請求來自產業自己研究自己。GEO/AEO 工具 5.8%、目錄與驗證器 3.6%、研究爬蟲 2.7%。加上目錄站連鎖效應，「有人在讀」有相當比例是生態系自己製造的回音。

台灣落地做法：不花 SaaS 訂閱

與其買 AI 可見度訂閱，不如自己看 log。以下在 Laravel 站或任何 Nginx／Cloudflare 環境都能做，授權成本 NT$0。

步驟一（0.5 人時）：grep -Ei "GPTBot|OAI-SearchBot|PerplexityBot|ClaudeBot|Claude-Code" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -50——直接看出 AI 在讀哪些頁。
步驟二（1 人時）：包成每日 cron 寫進資料表，用 Laravel 排程加一頁 Blade 報表呈現 30 天趨勢。
步驟三（2 人時）：跑一次 Lighthouse，只修無障礙樹與 CLS——對真人與 agent 同時有效，不依賴任何平台承諾。
步驟四（1 人時）：把報價區間、服務範圍、交期、案例數字補成可單獨引用的段落，加上 Organization 與 FAQPage 結構化資料。

合計約 4.5 人時。以台灣接案常見的 NT$1,200–2,000／人時計，約 NT$5,400–9,000 一次性成本，之後每月維護不到 0.5 人時。對照動輒每月數千到數萬元的訂閱，第二個月就回本，而且資料是你自己的。

30／60／90 天檢核

☐ 第 30 天：log 報表上線，能列出各 AI bot 抓取次數與熱門頁面
☐ 第 30 天：確認 /llms.txt 實際請求數；若為 0，從提案與月報移除此項
☐ 第 60 天：Lighthouse 無障礙樹與 CLS 通過，附修改前後對照
☐ 第 60 天：第一手資訊段落上線，Rich Results Test 驗證無錯誤
☐ 第 90 天：確認新增段落已被 AI retrieval bot 抓到
☐ 第 90 天：計算「AI bot 抓取頁」與「詢問來源頁」重疊率，作為下季唯一指標

常見問題 FAQ

我已經有 llms.txt 了，需要刪掉嗎？

不需要刪，但要改變管理方式：納入版控、限制編輯權限、內容只放連結與純描述、只連自己掌控的資源，並設定變更告警。真正的風險不是檔案存在，而是它長期沒人看、內容過期，卻被設計成「應該被信任」的 agent 讀走。

Agentic Browsing 顯示 2/3，會影響 Google 排名嗎？

不會。Google Search 官方文件在 mythbusting 區塊明確表示，你不需要建立這類機器可讀檔案才能出現在生成式 AI 搜尋結果中。Agentic Browsing 是實驗性類別，甚至不產出 0–100 分數，只給通過比例；它衡量 agent 操作友善度，不是搜尋排名。

那我到底該不該做 llms.txt？

看客戶是誰。開發者工具、API 服務或技術文件站，資料支持你做——coding agent 的抓取次數高過所有 AI 檢索爬蟲。餐飲、裝潢、醫美、在地服務或一般電商，97% 零請求就是你的預期值。若 CMS 會自動生成，留著即可，不要另外投預算。

有沒有比 llms.txt 更值得做的事？

有，順序很明確：先把第一手資訊寫成可單獨引用的段落，再補 schema.org 結構化資料，接著修無障礙樹與版面穩定度，最後才輪到機器可讀檔。前三項對真人與機器同時有效，不依賴任何平台的未來承諾。

我的觀點

主流敘事分兩派：一派說 llms.txt 已死，一派說它是為 agentic web 提前佈局。我兩邊都不站。我的判斷是：llms.txt 會活下來，但它會以「開發者文件的 agent 介面」這個身分活下來，那個版本跟 SEO 毫無關係。真正會在 18 個月內被清算的，是「AI 可見度稽核」這整個工具類別——當 Chrome 把 Agentic Browsing 放進每一次免費的 PageSpeed Insights，那些靠「掃描網站、給一個 AI 就緒分數」收月費的工具，核心功能就被瀏覽器內建吃掉了。

對 ScriptWalker 這種 Laravel + Flutter 接案工作室，啟示很直接：不要把「llms.txt 代建」做成服務項目，要把「agent 可讀介面層」做成服務項目。前者是一個 Markdown 檔，客戶用外掛五分鐘就能做，毛利趨近於零；後者包含無障礙樹修復、語意化 HTML 重構、結構化資料、WebMCP 端點，以及那套自架的 log 儀表板——每一項都需要真的懂前端渲染與後端路由，SEO 公司做不了，而且對真人使用者同樣有價值。當客戶拿著紅字報告上門，賣給他的不該是一個檔案，而是一份「哪些是真訊號、哪些是工具雜訊」的判讀能力。

資料來源

第一手

第三方／實測研究