AI 搜尋不是靠格式，是靠知識整齊｜補 llms.txt 之前該先做的事
先給答案：在補 llms.txt、MCP 這類新格式之前，先把公司內部的知識整理成一份可信的底。Search Engine Journal 的 Bill Hunt 在 2026 年 9 月 3 日的文章裡講得很直接，他看過 100 份以上的 agentic readiness 稽核報告，每一份都在檢查網站有沒有 llms.txt，沒有一份去看那份檔案裡的內容夠不夠深，品質好不好。[1]
格式做的事情是把知識送出去。知識本身有缺口的時候，多開一個格式只是把同一個缺口再發佈一次。這篇用五題問答，講清楚知識整齊的三個條件，以及格式該擺在哪個順序。
先說結論
- llms.txt V2 在 2026 年 8 月 10 日由原作者 Jeremy Howard 發布[2]。Google 官方的 AI 最佳化指南寫明 Google 搜尋不使用這類檔案，維護它對能見度與排名不會有幫助也不會有傷害[5]。
- Bill Hunt 的核心句是「新格式修不好缺漏的知識」，他建議的順序是先建一次規範知識源，然後到處發佈。[1]
- AI 會不會推薦你，看的是決策覆蓋率，也就是客戶做決定要用到的證據，你有沒有公開寫出來。
- 知識整齊有三個條件：同一個事實只有一個版本，每項知識有負責人，答案照客戶做決定的順序排。
- 新格式會一直來。WebMCP 在 2026 年 8 月由 OpenAI、Shopify 與 Cloudflare 推進到實際產品，Google Chrome 提供瀏覽器端支援。[3]底整理好，接新格式是幾天的工。
加個 llms.txt 就好了嗎？
llms.txt 是一份放在網站根目錄，給 AI 讀的索引檔。2026 年 8 月 10 日，這份規格的原作者 Jeremy Howard（Answer.AI）發布 V2 版本，加上了 Markdown 連結的標記方式。[2]有一句話值得記下來，而且它來自 Google 自己：Google 的 AI 最佳化指南寫明 Google 搜尋不使用這類檔案，維護它對網站的能見度與排名不會有幫助也不會有傷害。[5]
格式負責傳輸，內容要自己先有
Bill Hunt 在 9 月 3 日的文章把這件事講得更白：新格式修不好缺漏的知識。[1]他舉的例子很好懂，假設客戶要做一個決定需要五項條件，你的網站只說得清楚其中四項，把這四項換一個協議再發佈一次，第五項不會因此長出來。
換句話說，客戶關心的資訊若本來就沒寫進網站，再多開一個格式，AI 讀到的還是同一份缺口。
AI 搜尋到底看什麼？
Hunt 用「決策覆蓋率」（Decision Coverage）來描述這件事：AI 要能評估、比較、篩選，最後放心把你推薦出去，它得先在你公開的內容裡找到足夠的證據。[1]
客戶心裡的那五題，頁面上有答案嗎
翻成白話，客戶心裡的問題大概是這幾題：這服務適不適合我的狀況，大概要花多少，有哪些限制，跟別家差在哪，做完會拿到什麼。這幾題的答案要用明白的文字寫在頁面上，AI 才引得到。
答案散在業務的腦袋裡、報價單裡、通訊軟體的對話裡，機器讀不到。Google 官方在這件事上講得很直白：想出現在 AI Overviews 或 AI 模式沒有額外的要求，也不需要特別的最佳化，把既有的搜尋基本功做好就是了[7]。而那份基本功的核心，正是內容要對讀者有用，資訊要講得完整[8]。
- llms.txt
- 放在網站根目錄的索引檔，指引 AI 讀取網站內容。V2 在 2026 年 8 月 10 日加入正式的 Markdown 連結標記。Google 搜尋不使用這類檔案。
- WebMCP
- 讓 AI 代理直接跟網站內部功能互動的規格，例如查庫存、送表單。規格出自 W3C Web Machine Learning 社群小組，2026 年 8 月由 OpenAI、Shopify 與 Cloudflare 分別推進到實際產品，Google Chrome 提供瀏覽器端支援。
- 決策覆蓋率（Decision Coverage）
- Bill Hunt 提出的衡量方式，看一家公司公開的內容裡，是否含有 AI 評估、比較、篩選、推薦所需要的證據。
- 規範知識源（Canonical Knowledge Source）
- 公司事實、關係、政策、專業與決策證據集中維護的地方。各種發佈格式一律從這裡取用同一份內容。
什麼叫「知識整齊」？
三個條件，缺一個就會在 AI 搜尋裡掉分。
條件一：同一個事實只有一個版本
價格、服務範圍、交期，網站、提案、社群三邊講的要一致。三邊講法不同的時候，AI 讀到的是矛盾，矛盾的內容很難被拿來當推薦依據。
條件二：每一項知識有明確的負責人
這條資訊由誰維護，多久更新一次，講得出來。沒有負責人的知識會慢慢過期，而過期的內容跟錯誤的內容在機器眼中差別不大。
條件三：答案照客戶做決定的順序排
讓人一路讀下去就能做出判斷，順序跟著客戶的疑問走，不跟著公司內部的部門分工走。Hunt 在文章裡點出反面的代價：
「如果每一種發佈格式都自己維護一份公司事實跟決策證據，每次更新就多一次同步問題，每來一個新協議就多一個實作專案。」
Bill Hunt，Search Engine Journal，2026 年 9 月 3 日一個格式一份資料，三個格式就是三份要同步。把兩種做法攤開來比：
| 面向 | 每個格式各養一份 | 一份規範知識源 |
|---|---|---|
| 改一次價格 | 每個格式各改一次，容易漏 | 改一次，各輸出口跟著更新 |
| 新格式上路 | 重做一次整理工程 | 多接一個輸出口，幾天的工 |
| 事實一致性 | 網站、提案、社群容易各說各話 | 三邊同一個版本 |
| 維護成本 | 隨格式數量往上疊 | 集中在知識層，格式層很薄 |
這跟 Tiago Forte 在《打造第二大腦》講的邏輯一樣：先把知識集中整理成一個可信的底，之後產出只做重新組合。
建一次基礎，然後到處發佈。難的工只做一次，發佈層隨技術更替換掉就好。
替客戶整理知識源，是哪幾步？
四步，都是我實際在跑的流程。
建單一事實來源
每個客戶一份主檔，服務範圍、價格結構、產業定位、專業背景、過往決策全部寫在同一個地方。網站、提案、文章一律回頭引用它。
頁面事實核對
新頁面上線前逐條比對主檔，兩邊講法有出入就先對齊再發。這一步攔下來的多半是價格跟服務範圍，也是客戶最在意的兩項。
FAQ 手寫結構化資料
常見問答一題一題人工寫，答案跟頁面正文對得上，再標上結構化資料給機器讀。Google 官方文件本來就要求標記內容必須和使用者看得到的內容一致[6]，工具自動生成的 FAQ 常跟正文脫節，我不走那條路。
四步跑完，你手上會有一份可信的知識底。要出 llms.txt、要接新協議，都是從這份底輸出。想看更完整的 AI 搜尋佈局，可以接著讀2026 GEO 全攻略，或從GEO 新手 5 天入門開始。
那格式完全不用管嗎？
要管，只是順序放後面。基礎整理好之後，接上新格式通常是幾天的工。
新格式會一直來
WebMCP 是最近的例子。規格出自 W3C Web Machine Learning 社群小組，Google Chrome 2026 年 2 月先開早期預覽、提供瀏覽器端支援，但一直停在實驗階段；到了 8 月，OpenAI、Shopify 與 Cloudflare 把它推進實際產品，Shopify 在所有 Liquid 商店開通，OpenAI 在 8 月 25 日讓 ChatGPT 內建瀏覽器用得上，Cloudflare 推出邊緣橋接，它才算真正落地，讓 AI 代理直接操作網站內部的功能。[3]值得留意的是，WebMCP 管的是代理進站之後能做什麼，跟排名或引用是兩回事。這種東西每隔幾個月就會多一個。
Hunt 的建議是先建一次基礎，然後到處發佈。手上有一份規範知識源的公司，每來一個新格式就多一個輸出口；手上還沒整理的公司，每來一個新格式就多一份要同步的資料。差距是從這裡拉開的。結構化資料的部分怎麼落地，可以參考 Google 搜尋中心的結構化資料入門文件[10]，以及我整理的AI Overviews 引用檢查清單。
問題一：你的網站上，同一個服務的價格區間出現過幾種說法？
如果網站、提案、社群貼文講的數字對不上，這就是條件一沒過。先把價格結構統一寫進一份主檔，其他地方一律引用它。
問題二：客戶最常問的五個問題，答案在頁面上找得到幾題？
找得到三題以下，代表決策覆蓋率不足。AI 蒐證的時候湊不齊條件，就不會把你放進推薦名單。
問題三：你的 FAQ 結構化資料，跟頁面上看得到的文字一樣嗎？
不一樣的話，先把標記改成跟正文同一份答案。標記與可見內容不一致，是結構化資料最常見的失效原因。
常見問題
Q1：llms.txt 到底要不要放？
可以放，順序擺在知識整理之後。llms.txt V2 在 2026 年 8 月 10 日由原作者 Jeremy Howard 發布。Google 官方的 AI 最佳化指南寫明 Google 搜尋不使用這類檔案，維護它對網站的能見度與排名不會有幫助也不會有傷害。它的價值在於讓 AI 代理更快找到你網站上已經寫清楚的內容，網站上沒寫的東西它變不出來。
Q2：公司規模不大，也需要做知識架構嗎？
需要，而且小公司做起來比大公司快。大公司卡在跨部門的事實各說各話，小公司的問題通常單純得多，資訊只存在老闆跟業務的腦袋裡。把服務範圍、價格結構、限制條件、常見疑慮寫成一份主檔，一個下午就能起頭。
Q3：知識整理跟 SEO 是同一件事嗎？
同一件事的兩層。SEO 處理的是讓內容被找到，知識架構處理的是內容裡有沒有客戶做決定會用到的證據。傳統 SEO 做得好，但頁面回答不了「適不適合我的狀況」「有哪些限制」，AI 一樣不會把你放進推薦名單。想補內容可信度那一層，可以讀E-E-A-T 實作指南。
Q4：整理知識源要多久才看得到效果？
知識整理本身是內部工，兩到四週可以完成第一版主檔跟頁面對齊。被 AI 引用的變化通常要再等四到十二週，因為各家 AI 重新抓取跟更新的節奏不同。第一個月看不到引用變化是正常的。
Q5：結構化資料要用工具自動產生還是手寫？
手寫。工具自動產生的 FAQ 結構化資料常常跟頁面正文對不上，Google 官方文件也要求標記的內容必須和使用者看得到的內容一致[6]。我的做法是常見問答一題一題人工寫，正文跟標記用同一份答案。
首次發佈 ｜最後更新 ｜本文依據 2026 年 9 月 3 日當下可查證的公開資料撰寫，格式規格若有變動會回頭更新。
更正紀錄（2026-09-03）：初版有三處錯誤，已回頭核對原文全部更正。一，把 llms.txt V2 的發布日寫成 8 月 18 日，實為 8 月 10 日，8 月 18 日是報導日期。二，把 WebMCP 寫成由 Google 與業界推出，實為規格出自 W3C Web Machine Learning 社群小組，8 月由 OpenAI、Shopify 與 Cloudflare 推進到實際產品，Google Chrome 提供瀏覽器端支援。三，引用 Google〈AI Features and Your Website〉支持「資訊要完整才有被引用機會」，但該頁其實寫的是沒有額外要求，已改為照原文陳述，內容品質的部分改引〈Creating Helpful Content〉。
參考文獻
- Bill Hunt，〈The Next AI Protocol Won't Save Your SEO Strategy〉，Search Engine Journal，2026-09-03（原句「A new format cannot fix missing knowledge」與「Build the canonical base once. Publish everywhere.」，並提及看過 100 份以上 agentic readiness 稽核報告）。連結
- 〈Llms.txt V2 Adds Formal Markdown Linking For AI Agents〉，Search Engine Journal，2026-08-18（報導 Jeremy Howard 於 8 月 10 日發布 V2 規格）。連結
- 〈WebMCP Connects AI Agents To Actions Inside Websites〉，Search Engine Journal，2026-08-28（Shopify 全站開通，OpenAI 8 月 25 日接入 ChatGPT 內建瀏覽器，Cloudflare 邊緣橋接）。連結
- 〈Schema For AI Citations: How To Become A Trusted Source〉，Search Engine Journal，2026-09-01。連結
- Google 搜尋中心，〈AI Optimization Guide〉（寫明 Google 搜尋不使用 llms.txt 這類檔案，維護它對能見度與排名不會有幫助也不會有傷害）。連結
- Google 搜尋中心，〈FAQ (FAQPage) Structured Data〉（明確要求標記內容必須與使用者可見內容一致）。連結
- Google 搜尋中心，〈AI Features and Your Website〉（明確寫出想出現在 AI Overviews 或 AI 模式沒有額外要求，沿用既有的搜尋最佳化基本功即可）。連結
- Google 搜尋中心，〈Creating Helpful, Reliable, People-First Content〉（內容自評問題清單）。連結
- 提亞戈．佛特（Tiago Forte），《打造第二大腦》（集中整理一次，輸出時重新組合的知識管理邏輯）。
- Google 搜尋中心，〈Intro to How Structured Data Markup Works〉（結構化資料的運作方式與標記原則）。連結
圖片來源：首圖與內文圖皆為 AI 生成示意圖，由注意力行銷以自家模型製作。