llms.txt 是 AI SEO 新蛇油：Google 6/15 認證沒用，5 億爬蟲只碰它 408 次
2026 年最被過度包裝的「AI SEO 必做項」，正在被官方訊號與伺服器日誌雙面打臉。6 月 15 日 Google 在 Search Central 直接加了一段話：llms.txt 對 Google Search（含生成式 AI 功能）沒有幫助，也沒有壞處。同月一份掃過 5 億次 AI 爬蟲流量的日誌研究拆解得更難堪：GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBot 對 /llms.txt 的總命中數，只有 408 次——比例 0.00008%。你可以繼續放這個檔案，成本很低；但別把它當策略，也別繳學費買「llms.txt 優化服務」。這篇拆解官方訊號、爬蟲行為數據、Shopify 78% 採用率的統計錯覺，以及 Vince 判定 llms.txt SEO 該讓位給誰的資源優先順序。
一、Google 6/15 蓋棺論定：Search Central 明說 llms.txt 對 Search 沒用
Google 過去對 llms.txt 一直採「不表態」——沒推薦、也沒否認。但 2026-06-15，這條中立線被官方文件親自劃掉。Google Search Central 在 robots-related documentation 底下新增「Clarifying guidance on llms.txt files」子段，用官方語言把 llms.txt SEO 的想像蓋棺論定。
(一) Search Central 新增段落原文：對 Search 沒幫助也沒傷害
新增段落的核心句是這一段：「Google Search itself doesn’t use them… having a llms.txt file on your site won’t harm nor help your site’s presence in Google Search (including generative AI features).」 兩個關鍵字：不會傷害、不會幫助。這不是「暫未支援」，也不是「未來會看」，是官方對 llms.txt SEO 的功能歸零宣告——連 Google AI Overview、AI Mode、Discover 這幾個生成式 AI 面板都被明確納入「沒幫助」範圍。
(二) 白名單媒體交叉報導：SEJ 一次講到底
Search Engine Journal 在同一週把 Google 這段更新翻譯得很直白：Google 說 “fine” 不是背書，是「你要放沒差」；SE Roundtable 也追訪報導，指出 Google Search Advocate 在社群媒體多次補充「llms.txt 不是 ranking signal」。過去半年台灣 GEO 教學文最常引用的「Google 沒明說反對」語意漏洞，在 6/15 之後被官方原文直接堵死。
(三) 「暫未支援」還是「明說沒用」：讀懂 Google 的官方語氣
Google 官方文件慣用「currently not supported」表達「還沒做，但未來會看」；用「doesn’t use」表達「不打算用」。這次的措辭是 doesn’t use，不是 currently doesn’t use——這是條件式否定與絕對式否定的差別。SEO 圈習慣把 Google 每段模糊語言當成「留伏筆」，但 6/15 這段沒留伏筆。它是把 llms.txt SEO 直接歸到 rel=”author”、rel=”me”、authorship markup 這類「歷史上被試過、後來被拿掉」的訊號堆裡。
| Google 官方措辭 | 語意 | 案例 |
|---|---|---|
| currently not supported | 暫未支援，未來可能會看 | 2019 前的 JSON-LD 部分屬性 |
| doesn’t use | 明說不用，非過渡性 | 2026-06-15 llms.txt 段落 |
| won’t harm nor help | 沒罰也沒賞，功能歸零 | llms.txt 現況 |
| use at your own risk | 警告性語氣，代表有壞處 | Cloaking、隱藏文字 |
二、5 億次 AI 爬蟲日誌只命中 408 次：llms.txt SEO 的實測完敗
官方訊號之外，最硬的打臉來自伺服器日誌。過去半年多份大樣本 log 研究把 llms.txt 的實測命中率拉到極低。爬蟲來得比你想的兇——但完全不走這條門。
(一) Digital Applied 30 天研究：GPTBot 每站每天 4,200 次點擊
Digital Applied 一份 30 天生產站日誌研究記錄了 AI 爬蟲的真實強度：GPTBot 每站每天平均 4,200 次點擊、ClaudeBot 1,800 次、PerplexityBot 980 次、OAI-SearchBot 620 次。AI 爬蟲對內容站的抓取密度早已超過 Googlebot 部分子桶，這證明生成式引擎確實在密集索引全網——只是它們沒走 llms.txt 這扇門。
(二) 90 天 5 億次流量樣本：命中 408 次 = 0.00008%
把樣本拉到 90 天、5 億次 AI 爬蟲流量的規模後，數字更難看：直接命中 /llms.txt 的請求只有 408 次，換算比例約 0.00008%。作為對照，同一份日誌裡 /robots.txt 的命中率是三位數百分比——每個 crawl session 幾乎都會讀。結論不含糊：AI 爬蟲的行為模式跟 llms.txt 完全脫鉤，它們讀 sitemap.xml、讀 robots.txt、讀 HTML 主體，就是不讀你精心寫的 llms.txt。
(三) 爬蟲來得兇，但完全不走這條門
這是很多 SEO 工作者的思考盲點：他們以為「AI 爬蟲量爆增」等於「llms.txt 會被讀」，把兩件事混為一談。事實是 AI 爬蟲對站點的流量確實爆增（有些站台 AI 爬蟲已占 15-30% 總 bot 流量），但抓取路徑跟傳統 crawler 幾乎一致——Casey Burridge 掃全網數百萬站發現 llms.txt 有效存在率僅 5-10% 級距，多份日誌研究同步指出 AI 爬蟲對 llms.txt 的實際 fetch 率趨近於零。這也對接了筆者在 Google AI Overview 引用崩壁：Top 10 命中率從 76% 掉到 38%裡談的機制：AI 引擎的引用邏輯，早就跟「有沒有 llms.txt」這種表層檔案沒關係。
- Digital Applied 30 天研究：GPTBot 4,200 / ClaudeBot 1,800 / PerplexityBot 980 / OAI-SearchBot 620 次每站每天
- 90 天 5 億流量樣本：
/llms.txt命中 408 次，比例 0.00008% - 對照組
/robots.txt：命中率為 llms.txt 的 10 萬倍以上 - Casey Burridge 全網掃描：llms.txt 有效存在率 5-10%，且與 fetch 率解耦
- 結論：AI 爬蟲不缺流量，只是不把 llms.txt 當入口
三、Shopify 讓 78% 是統計錯覺：llms.txt SEO 採用率的行銷數字陷阱
台灣 GEO 社群近半年最常拿出來背書 llms.txt 的一組數字，是「整體採用率 10.13%」或「電商平台採用率 78%」。這兩個數字都沒錯，但錯在解讀——把「平台強推」誤讀成「站主主動策略」，把「統計基期抬升」誤讀成「業界共識形成」。
(一) Shopify 2026-04 至 2026-05 悄悄替 700 萬家店自動生成
Shopify 5/28 developer changelog 揭露：平台在 4 月到 5 月間，替全平台約 700 萬家商店自動生成 /llms.txt、/llms-full.txt、/agents.md、/.well-known/ucp。這是平台級預設值變動，不是 700 萬家店主動優化——換句話說，這個「巨量新增採用」跟站主的 SEO 決策沒關係，跟他們是否讀過任何 GEO 教學文更沒關係。可是它把全網 llms.txt 採用率的統計基期整體抬高了。
(二) 78% 是行銷數字，不是策略數字
行銷邏輯跟技術邏輯是兩件事。「業界 78% 都在做 llms.txt」是一個看起來有共識、實際上是平台預設值的統計人造物。SE Ranking 300,000 網域研究把整體有效採用率標在 10.13%，但扣掉 Shopify 這 700 萬家自動生成的部分之後，主動採用率會回到接近 Casey Burridge 掃出的 5-10% 級距——而這個級距裡，還有一大部分是被 SEO 顧問售出的「llms.txt 優化服務」放上去的。真實站主主動決策的比例，遠低於 SEO 工具商想讓你相信的數字。
(三) 平台級差別對待：OpenAI 沒寫、Anthropic 說會讀但實測不讀
更多打臉來自平台自己的文件：OpenAI 的 OAI-SearchBot 官方文件完全沒提 llms.txt；Anthropic 與 Perplexity 曾公開表態「有的話會讀」，但實際 log 顯示 fetch 率趨近於零。真正在讀 llms.txt 的，其實是開發者工具鏈——Cursor、Claude Code、Copilot、Windsurf、MCP servers 這類 IDE 或 agent framework 會抓 llms.txt 當作 context 引導檔。它的價值在 dev tooling，不在 AI 搜尋能見度。這是兩個完全不同的用途場域，被行銷語言合成同一個故事。
| 平台 / 引擎 | 官方對 llms.txt 表態 | 實測 fetch 行為 | llms.txt SEO 效果 |
|---|---|---|---|
| Google Search / AI Overview | 明說不用（6/15 官方段落） | 不 fetch | 無 |
| OpenAI ChatGPT / OAI-SearchBot | 官方文件沒提 | 趨近於零 | 無 |
| Anthropic Claude | 「有的話會讀」 | fetch 率極低 | 幾乎無 |
| Perplexity | 「有的話會讀」 | fetch 率極低 | 幾乎無 |
| Cursor / Claude Code / MCP | 會抓作 context | 會 fetch | 對 dev tooling 有效 |
四、llms.txt SEO 該讓位給誰：Bing IndexNow、作者實體、可爬 HTML
否定完 llms.txt SEO，剩下的問題是：那該把時間、預算、KPI 放哪？這一節列出 Vince 判定 CP 值最高的三個資源優先順序——都是有官方訊號或大樣本日誌支撐的動作，不是又一組「看起來很合理」的新噱頭。這一節也可以跟筆者的 你在意的 Domain Authority 死了：2026 作者實體驗證才是 AI 引用的准入門檻合起來讀，兩篇構成「AI 引擎的真訊號 vs 偽訊號」矩陣。
(一) 優先順序 #1：Bing Webmaster + IndexNow
ChatGPT Search 底層走的是 Bing 索引，這是公開事實。沒進 Bing 索引，就沒資格進 ChatGPT Search 候選池——這條決定性遠比 llms.txt 硬。Bing Webmaster Tools 與 IndexNow 協定的組合，讓內容站可以在 URL 產生的當下把索引請求推到 Bing 邊緣節點，加速被抓取與被納入 candidate pool。這是動作明確、成效可測、且對接 ChatGPT Search 引用機制的實作。相對於「寫個 llms.txt 給 AI 讀」，「主動推 URL 進 Bing」才是 AI 搜尋時代的真動作。
(二) 優先順序 #2：Author schema + sameAs 陣列
W29 那篇拆解過作者實體驗證的機制與實作。這邊補一個對照：把預算從「做 llms.txt 優化」轉去「補完 Author schema 與 sameAs 陣列」，是本質上兩種不同時代的 SEO 動作——前者是 2024 年的想像投射，後者是 2026 年 Google Discover Core Update 直接獎勵的訊號。Person 型 Author schema 加上 LinkedIn / ORCID / Wikipedia / 組織頁的 sameAs 陣列，是 AI 引擎跑圖譜遍歷時真的會用的節點。這是可以量化、可以驗證、也能對接 AI Overview 引用面板的動作。
(三) 優先順序 #3：純 HTML 可爬取（Static 94% vs JS 23%）
多份 AI crawler 行為研究揭示一個常被忽略的事實：AI 爬蟲對 static HTML 的解析成功率約 94%，對 JavaScript 渲染頁面只有 23% 上下。這是把「crawlability」直接轉譯成引用能見度的關鍵——你的內容再有觀點、作者實體再強，AI 爬蟲讀不到 DOM 就不會納入候選。這條動作比 llms.txt 難執行（可能牽涉框架選型），但對 AI 搜尋引用命中率的影響級距，跟 llms.txt SEO 是天差地遠。這也呼應筆者在 我為什麼認為 SEO 文章，未來幾乎會變成垃圾內容裡的判斷：新工具與新噱頭不是答案，可爬性、作者實體、Bing 索引這些基本盤才是。
- Bing Webmaster + IndexNow 主動推 URL：進 ChatGPT Search 候選池的先決條件
- Person 型 Author schema + sameAs 陣列：對接 W29 作者實體驗證，AI 引擎跑圖譜遍歷的真實訊號
- 純 HTML 可爬取 / 減少 heavy JS：AI 爬蟲對 static HTML 解析成功率 94%，JS 渲染僅 23%
- Organization schema + 明確 memberOf：把作者綁回組織實體，強化圖譜可驗證性
- 不必砍掉 llms.txt：成本很低、放著沒差，但別當 KPI、別買「llms.txt 優化服務」
五、常見問題 FAQ
Q1：llms.txt 現在到底該不該寫？
可寫可不寫。Google 明說沒幫助也沒傷害，AI 爬蟲的實測 fetch 率趨近於零。如果你已經放了，成本很低、放著沒差；如果還沒放，也不必列為優先動作。真正該優先的是 Bing IndexNow、Author schema、可爬 HTML 這三項，這三項有官方訊號、日誌數據、且對 AI 引用有可量化影響。llms.txt SEO 不是禁區，只是不該擺在 KPI 或客戶提案裡。
Q2：Google 說 llms.txt 沒用，那 ChatGPT、Perplexity 這些引擎會不會偷偷讀？
目前的公開實測結論是：不會，或極少。OpenAI 的官方文件對 OAI-SearchBot 完全沒提 llms.txt；Anthropic 與 Perplexity 有口頭表態「有的話會讀」，但 5 億次日誌樣本裡 /llms.txt 命中只有 408 次。這代表就算某些 AI 引擎理論上會讀，實務上的抓取行為證明它不是主要 context 來源，也不是被引用機率的關鍵訊號。
Q3：Shopify 的 78% 採用率不是代表業界共識嗎？
不是。Shopify 在 2026-04 到 2026-05 間悄悄替全平台約 700 萬家商店自動生成 llms.txt，這是平台預設值變動，不是 700 萬家店主動做的 SEO 決策。扣掉這批被動生成的資料後，主動採用率會回到 5-10% 級距。用 78% 這個數字說服客戶「業界都在做」是統計錯覺，不是策略共識。
Q4：那 agents.md、UCP、MCP 又是什麼？也要跟嗎？
要不要跟看業別。agents.md 是給 AI agent 操作站點的指引檔、/.well-known/ucp 是統一商務協定端點、MCP 是模型呼叫通道。ChatGPT 走 ACP、Google AI Mode 與 Gemini 走 UCP。如果你賣的是實體或數位商品、需要 AI agent 直接下單，這才是要跟的協定；如果你是內容站或個人品牌部落格，這一整套目前跟你關係不大，可以先觀察。這也是 Shopify 5/28 changelog 揭露的重點：agents.md 與 UCP 才是他們平台級推動的核心，llms.txt 只是順便放。
Q5：如果我已經買了「llms.txt 優化服務」，要退費嗎？
這不是退費問題，是預算重配問題。llms.txt 本身寫起來就是一份 markdown，多數服務商賣的其實是「幫你把站點內容濃縮成 llms.txt 格式」——這件事本身沒錯，但它不會影響 AI 引用機率。合理的做法是：完成的檔案留著、預算下一輪轉去做 Author schema 與 sameAs 陣列補完，或是接 Bing Webmaster + IndexNow。這兩者是「同樣的預算，效果級距差 100 倍」的替代方案。