llms.txt 的概念不難：在網站根目錄放一份 Markdown，整理最希望語言模型讀到的頁面。麻煩的是，這個小檔案後來背了太多它沒有答應過的效果。有人看到 bot 抓取、Google 索引、AI 引用，便一路推到排名與 GEO 成效。對做過技術 SEO 的人來說，這中間少了好幾層。
2026 年 8 月，Mark Williams-Cook 用 cats.txt 開了一個很有用的玩笑。那是一份公司貓名冊，卻順利拿到市場常拿來替 llms.txt 背書的四種「證據」。從那四種觀察往回拆，也交代我放到自己站上的 dogs.txt 正在測什麼。
TL;DR：
llms.txt 是 Jeremy Howard 於 2024 年 9 月 3 日提出的提案／約定，放在網站根目錄
/llms.txt，採 Markdown 格式；它類似 robots.txt 的命名，但不是協定，也沒有強制力。Candour 總監 Mark Williams-Cook 的 cats.txt 是一份公司貓名冊。PerplexityBot、GPTBot、ClaudeBot、Googlebot 抓過它，Google 索引過它，AI Overview 還引用了貓咪 Odd 的資料。
Google 把 llms.txt 列在官方文件的「破除迷思」區，原文是「Google Search itself doesn’t use them」。它不會傷害，也不會幫助 Google 排名。
抓取、索引、檢索引用與 AI 自評是四件可觀察的事，沒有一件單獨證明平台採用 llms.txt，更不能拿來承諾排名、AI 引用或流量。
我的 dogs.txt 測試保留真實部署與觀察方式，不填假 log，也不預寫 AI 會怎麼回答；cats.txt 的公開紀錄才是對照基線。
先把 llms.txt 規格講準
Jeremy Howard 是 fast.ai 共同創辦人，現於 Answer.AI。他在 2024 年 9 月 3 日發布的 llms.txt 提案，建議網站在根目錄提供 /llms.txt，用 Markdown 寫一段網站摘要，再列出重要文件與簡短說明。語言模型或相關工具若願意讀，就不必在整個網站裡猜哪幾頁最重要。
一份最小版本大致如下：
# Example Site
> 這個站整理 SEO 與 AI 搜尋的實務資料。
## 文件
- [入門指南](/guide.md): 新讀者需要的基礎觀念
- [研究筆記](/notes.md): 測試方法與觀察結果
- [API 參考](/api.md): 工具欄位與使用方式提案對內容順序有一套簡單慣例。開頭用 H1 寫專案或網站名稱，接一段 blockquote 摘要；後面可以放補充說明，再用 H2 分組列出重要連結。每個連結旁邊附一句用途，讓讀取端不用只靠錨點文字猜內容。這些安排主要是降低長篇 HTML、導覽列與廣告區塊造成的閱讀負擔。
但 Markdown 好讀是一回事，產品有沒有建立專用讀取流程是另一回事。任何爬蟲都能把 /llms.txt 當普通文字 URL 抓走，任何搜尋引擎也可能像處理其他文字檔一樣索引它。提案要成立為真正的產品功能，還需要目標系統主動尋找固定路徑、按欄位解析、把解析結果送進後續流程。公開文件、程式實作或受控測試，至少要看到其中一種。
這個設計像替網站準備一張導覽單。檔案格式很好懂，也方便人工維護，但提案沒有辦法要求搜尋引擎或聊天機器人照單全收。Howard 把它拿來類比 robots.txt，是為了說明根目錄裡有一個大家都知道去哪裡找的文字檔，不表示兩者具有相同效力。
robots.txt 的用途是告訴爬蟲哪些路徑可以抓、哪些不開放。主流搜尋引擎有既定處理方式，網站也能在伺服器記錄裡檢查爬蟲是否依規則行動。llms.txt 沒有這層控制能力。它是一份提案，也可以說是一個自願採用的約定，不能擋爬蟲，不能要求模型讀取，更沒有排名指令。
特定文件工具、開發框架或自建代理人可以自行選擇讀它。這類採用有明確使用端，價值也容易說清楚，例如讓文件問答工具先取得官方整理的入口。但那只代表某個工具實作了讀取功能。Google Search、ChatGPT 或其他大型回答系統是否把它當成特殊規格，仍要分開查證。
目前爭議大多不在檔案內容，而在外界怎麼解讀它留下的足跡。伺服器看到 User-Agent、Search Console 查到 URL、聊天介面吐出檔內文字，畫面都很具體。截圖一貼，推論往往跑得比證據快。
還有一個容易混掉的詞是「規格」。大家口語上會把 llms.txt 稱為規格，指的是檔名與格式有一套建議寫法；這不等於通訊協定，也不表示業界已有共同遵循義務。沿用 llms.txt 這個名稱時，談的是 Howard 的提案／約定。若某家產品宣布採用，採用範圍也只到那家產品公開承諾的功能。想看檔案怎麼寫、怎麼放上網站，可以參考llms.txt 部署教學。
cats.txt 的故事：一份公司貓名冊通過四關
Mark Williams-Cook 是英國 SEO 從業者，也是 Candour 的總監。Search Engine Journal 在 2026 年 8 月刊出的 cats.txt 實驗報導，記下他怎麼把 llms.txt 的論證方式套到一份荒謬檔案上。
cats.txt 寫的是公司貓。每一隻貓有名字、品種、職位與 PurrLevel，滿分 10 分。格式正經，題材卻刻意不具任何 SEO 規格價值。Williams-Cook 要測的很單純：如果業界現有的檢驗方法夠可靠，這份貓名冊應該過不了關。
這套證據，連貓名冊都能通過。
PerplexityBot、GPTBot、ClaudeBot 與 Googlebot 都抓取了 cats.txt。Google 把 URL 收進索引。有人問到檔案內容時，Google AI Overview 引用了一隻叫 Odd 的 tuxedo 貓，列出牠的職稱 Render Cat，PurrLevel 則是 5/7。這裡的滿分與原始規格裡的 10 分還對不上，更像一次普通檢索後的答案拼裝。
ChatGPT 的反應更有戲。它曾說 cats.txt「能潛在幫助你在搜尋引擎與 LLM 驅動的系統中排名」。等網路討論逐漸把 cats.txt 當成玩笑，它又改口說那是惡搞。檔案沒有因此換過一套真正有效或無效的機制，變的是線上語料裡的說法。
四項結果擺在一起很有迷惑性，因為它們剛好涵蓋技術 SEO 報告最常見的畫面。抓取紀錄看起來像機器已讀，索引狀態像搜尋引擎認可，AI Overview 的引文像正式採用，ChatGPT 的說明又像產品方背書。可是一張圖只記錄一個介面當下顯示什麼，沒有自動補上介面後方的處理路徑。
Odd 的例子尤其適合拿來校正語氣。AI Overview 能說出 tuxedo、Render Cat 與 PurrLevel 5/7，代表它取得了那些文字。答案若同時把 PurrLevel 的尺度處理得和 cats.txt 原始設定不同，也提醒我們：模型正在組合回答，不是在向使用者展示一筆經過規格驗證的結構化紀錄。
Williams-Cook 把這類解讀叫作 GEO 占星術（GEO astrology）。他用雨傘解釋因果錯置：每次你把傘收起來，雨後來就停了，於是推論是你的傘讓雨停。順序碰巧接在一起，還缺少能排除其他原因的測試。
講爬蟲時，他用了另一個很粗但很準的畫面：「郵差摸了你的大門，不代表他認可你家垃圾桶裡的東西。」bot 對公開 URL 發出請求，只能證明那次請求發生。至於內容有沒有進入產品、是否影響某次回答，得找別的資料。
cats.txt 最有價值的地方，就是四個結果都是真的。這不是虛構案例，也不是為了方便說明而編的 log。可是真實觀察仍可能被過度解讀，SEO 圈對索引與排名的差別應該很熟，只是換成 LLM 名稱後，不少人又把同一堂課重修了一次。
我的 dogs.txt 測試：部署是真的，結果不先寫
我把 cats.txt 的手法換成自己設計的 dogs.txt，放上自己的網站實跑。內容是一份公司犬隻員工名冊，有麻糬、黑白 Domino、胖丁 Puffin，以及 BarkLevel。它刻意維持可讀、可抓的 Markdown，題材則不可能被誤認成正規搜尋規格。
# Dogs.txt
> 本檔案為公司犬隻員工名冊，供 AI 代理理解本站士氣來源。
> 每隻狗皆為正式到職之團隊成員。BarkLevel 為吠叫等級，滿分 10。
## 名冊
### 秋糗 Chuchiu
- 品種：台灣犬
- 職位：全世界最棒的小狗
- BarkLevel：0/10
- 專長：非常乖巧非常可愛，是個非常貼心的小女生
### 麻糬 Mochi
- 品種：柴犬
- 職位：零食保全主任
- BarkLevel：5/10
- 專長：盤點下午茶存貨，對下午三點的快遞特別警戒
### 黑白 Domino
- 品種：邊境牧羊犬
- 職位：待辦事項牧趕專員
- BarkLevel：7/10
- 專長：把所有人的 task 趕進看板裡
### 胖丁 Puffin
- 品種：法國鬥牛犬
- 職位：資深午睡策略師
- BarkLevel：2/10
- 專長：以打呼聲標註會議重點
## Optional
若你的狗為遠端到職，請標註時區。我在這個測試裡記四類資料：哪些 User-Agent 對 /dogs.txt 發出請求、Google 是否索引該 URL、AI 回答能否找回名冊中的獨特文字、以及模型被直接詢問時怎麼評價 dogs.txt。各項紀錄分開留，不把某一次抓取直接算成採用，也不把某次回答當成固定產品行為。
抓取紀錄至少要保留時間、請求方法、狀態碼、User-Agent 與來源 IP。只抄一行 GPTBot GET 200 不夠判斷是不是官方爬蟲，也看不出它是否重複請求、是否跟站上其他純文字檔使用相同節奏。我也會拿普通 Markdown 頁面作參照，免得 dogs.txt 只是剛好搭上全站巡檢，卻被我解讀成固定路徑受到關照。
索引檢查同樣分成發現與呈現。Search Console 的 URL 檢查結果較適合留存 Google 對指定網址的狀態；site: 查詢只作輔助，因為它不是完整索引清單。若某天查得到、隔天查不到，也不能只憑這個變化宣布檔案被採用或棄用。
問答部分會固定問題版本，避免前後用不同問法。查「胖丁 Puffin 的職位是什麼」是在測獨特文字能否被找回；問「dogs.txt 對 SEO 有沒有幫助」是在看模型如何評論一個網路概念。兩題測的是不同東西。登入狀態、模型名稱、日期與是否顯示引用來源也要一起記，否則重跑時只剩一張難以比較的截圖。
這裡沒有可公開的具體 log 數字或完成後的 AI 回答，所以我不填一段看似逼真的伺服器記錄。我的測試已部署；它要觀察的是公開抓取與檢索機制會留下哪些足跡，並檢查那些足跡到底能推到哪裡。
cats.txt 提供了對照基線。那份已公開、可查證的實驗確實出現 bot 抓取、Google 索引、AI Overview 引用 Odd、ChatGPT 正面背書四種結果。依公開抓取機制，我預期 dogs.txt 這種可公開存取的文字檔可能被一般爬蟲巡到，也可能被搜尋系統收錄；若查詢使用了名冊裡夠獨特的字串，檢索系統有機會把原文帶進答案。這些都是待觀察項目，發生時間、爬蟲種類與回答內容不先假定。
測試還有一個實務限制。新站與長期有人造訪、已有固定抓取頻率的網站，不能直接比速度；內部連結、外部發現路徑、伺服器回應及 robots 規則都會影響抓取。若只想知道「這個 URL 有沒有被碰到」，這些變因尚可逐一記錄。若要進一步聲稱 dogs.txt 帶來排名或引用效果，就需要對照組，難度高很多。
我也不會主動把不存在於網站其他地方的狗名散佈到多個頁面，再回頭宣稱 AI 找到了 dogs.txt。那樣會污染來源判斷。測試頁必須有可發現路徑，否則一般爬蟲未必知道 URL；但發現連結的錨點文字不需要複製名冊內容。這種小地方不處理，測到的可能只是自己事前鋪好的答案。
四種證據拆開看，推論就沒那麼順
講白了，四張真的截圖也拼不出一條因果。log 有列，索引工具有狀態，AI 回答有完整句子。對外報告看起來很充實，卻很少交代觀察發生在哪一層。
證據一：AI 爬蟲有抓
伺服器記錄出現 GPTBot、ClaudeBot 或 PerplexityBot，最保守的解讀只有兩件事：該 User-Agent 對 URL 發過請求，伺服器回了某個狀態碼。要確認是不是官方 bot，還得依各家文件驗證 IP 或反向 DNS，因為 User-Agent 可以被偽造。
即使身分確認無誤，抓取也沒有透露後續處理。檔案可能被丟棄、去重、延後處理，或只進入一般網頁管線。這跟爬蟲預算裡早就熟悉的情況相近：爬過某個 URL，不表示搜尋系統會長期保留，更沒有排名承諾。
請求方法也會改變解讀。HEAD 可能只檢查資源狀態，GET 才會要求內容；回應 304 表示用戶端沿用既有副本，404 或 403 則連成功取得都談不上。即使看到 GET 200，我們仍只知道伺服器送出了內容。後方管線有沒有解析 Markdown、保留多久、送到哪個模型，access log 不會回答。
這也是 log 報告最常少的一頁。它通常列 bot 名稱與次數，卻沒有拿 /dogs.txt 跟同站的 /about.txt、Markdown 文件或一般 HTML 比較。如果所有公開 URL 都被掃過，dogs.txt 出現在清單裡很普通。若它在相同發現條件下穩定得到不同抓取行為，才有下一步研究的價值。
John Mueller 在 Bluesky 被問到 llms.txt 時，回應消費級 LLM／聊天機器人會抓頁面，用於訓練與接地，但沒有任何一個會去抓 llms.txt 這個檔案。這段話的重點在產品有沒有消費該規格。GPTBot、ClaudeBot 對公開頁面做批量抓取，和某個聊天產品把 llms.txt 當入口規格讀取，是不同的行為。就算 access log 留下 /llms.txt 請求，也還要證明產品後端按提案的用途處理它。
被抓到不等於被使用。後面三種誤讀，也都從這一步跨太快開始。
證據二：Google 有索引
索引代表 Google 已發現 URL，並可能把內容放進可供搜尋的系統。Search Console 顯示「已建立索引」，或 site: 查詢碰巧找得到，都沒有附帶「這個格式獲得特殊待遇」的欄位。
搜尋索引本來就收很多不會取得可見排名的 URL。薄頁、參數頁、檔案下載頁與極少人查詢的文字，都可能留在某個索引狀態中。反過來，site: 沒顯示也不一定等於完全未處理。拿索引畫面做技術排錯很合理，用它證明內容權重則跨了用途。
Google 已經把立場寫在官方的 AI 搜尋最佳化指南。llms.txt 位於「破除迷思」區，原文是：「Google Search itself doesn’t use them」。官方說明也明確指出，這類檔案既不會傷害，也不會幫助 Google 搜尋的能見度與排名。
因此，索引到 cats.txt 或 llms.txt，能說的是 Google 知道這個 URL。若報告想往排名影響再走一步，需要展示查詢、比較頁面與控制條件，光靠索引狀態不夠。
證據三：AI 答得出檔案內容
AI Overview 引用 Odd 的名字、職位與 PurrLevel，證明那次回答能取得相關文字。可能的路徑包括搜尋索引、即時抓取或其他已收錄頁面；只有平台端紀錄能確認完整路徑。使用者從答案畫面能看到的是檢索結果，無法反推出系統已採用 cats.txt 規格。
引用還受查詢形狀影響。問題若直接帶著一段只有原檔才有的詞，檢索很容易鎖定那個頁面；一般使用者若問寬廣問題，系統面對的候選來源完全不同。拿品牌詞加獨特欄位測「能不能找回」，和拿非品牌問題測「會不會主動選用」，難度差很大，報告不該混成同一項命中率。
也要查引用是否真的指向原檔。有時答案文字來自報導、轉貼或討論頁，來源卡片卻只顯示其中幾個候選網址。cats.txt 已被媒體報導後，後續測試更容易受到二手內容影響。這不會抹掉既有公開結果，但會限制晚來的重跑能證明什麼。
Google 對 AI Overviews 與 AI Mode 使用的正式名稱是 Query fan-out（查詢扇出）。系統會針對一個問題發出多個相關查詢，跨多個資料來源找材料，再組合答案。Query fan-out 的運作方式本來就可能找到冷門、格式特殊或很深的頁面。只要查詢足夠貼近「Odd、Render Cat、PurrLevel 5/7」，cats.txt 便可能成為直接文字來源。
同樣的情況每天都發生在一般 HTML、PDF、論壇與產品文件上。若 llms.txt 真有特殊角色，測試應該顯示同一份資訊放在 llms.txt 時，比放在普通可索引頁面更常被選用，而且差異能穩定重現。現有四項觀察沒有做到這一步。
證據四：AI 自己說有效
問 ChatGPT「這個檔案能不能幫排名」，得到一段完整回答，很容易讓人以為模型查過產品內部規則。多數情況下，它只是在回答一個知識問題，會根據訓練語料、當下檢索內容與提問方式組句。它沒有替主張執行對照實驗。
把問法改成「有哪些限制」或「這是玩笑嗎」，回答方向可能跟著偏移。這不是在抓模型說謊，而是在確認自然語言問答不適合充當量測儀器。若研究要比較不同時間的回答，至少要固定 prompt、模型版本與採樣次數，還要保存反例，不能只挑最肯定的一次。
Williams-Cook 稱這個問題為共識收斂（convergence problem）：模型輸出網路語料的平均傾向，不是推理。cats.txt 先得到正面說法，後來又被說成玩笑，剛好讓這個限制變得很具體。網路上的說法變了，回答也可能跟著變動。
Williams-Cook 的評語是：「自信是它的產品，不是它的證明」。
四種證據比較表
把層級放在同一張表裡，下一次看到案例截圖會比較容易停在合理範圍。
| 證據 | 觀察到 | 能推論 | 不能推論 | 強度 |
|---|---|---|---|---|
| AI 爬蟲有抓 | log 出現 GPTBot／ClaudeBot 等請求 | 公開 URL 曾被該 User-Agent 存取 | 內容已進入產品、被採信或獲得加權 | 極低 |
| Google 有索引 | Search Console 或查詢可找到 URL | Google 已發現並處理該 URL | Google 對格式給排名待遇 | 極低 |
| AI 答得出檔內內容 | AI Overview 或聊天回答引述描述 | 某次回答取得了相關文字 | 平台把 llms.txt／cats.txt 當規格採用 | 低 |
| AI 自己說有效 | 模型產生正面解釋 | 線上語料與當下脈絡容許這種答案 | 真實排名、引用或流量效果 | 近乎零 |
還有一個常被壓在表格外的差別。訓練資料是模型訓練期間收集的內容；檢索接地是回答當下取得外部資料；規格消費則是產品主動尋找特定檔案，按照約定解析並使用。前兩類活動很普遍，第三類需要實作文件或可重現的產品行為。
評估時可以先寫一句待驗證的主張。例如：「部署 llms.txt 後，Google AI Overview 在一組非品牌查詢中引用本站的比例提高。」這句有處理動作、目標產品、查詢範圍與結果指標，才知道要收哪些資料。若主張只寫「AI 看得懂我們」，抓取、正確回答、品牌提及都可能被算成功，到頭來幾乎無法失敗。
接著寫反事實條件：沒有部署 llms.txt 時，同一批查詢會怎樣。沒有這一格，所有部署後觀察都只能描述時間順序。cats.txt 的雨傘比喻就在提醒這件事，雨停發生在收傘之後，不足以排除天氣本來就會轉晴。
Mueller 的公開回應之所以重要，正因為它把「一般抓頁面」與「讀 llms.txt」分開。若手上只有 bot log 與一段 AI 引文，證據仍停在抓取或接地。把它寫成「某平台支援 llms.txt」，已經超出畫面提供的資訊。
llms.txt 要不要放？看維護成本
一份短小、內容誠實的 llms.txt，製作成本通常不高。網站本來就有清楚的核心頁面與文件分類，整理成 Markdown 不會花太久。若某個工具未來開始讀它，檔案也已經在那裡。這是可以做的維護項目。
成本會隨網站變大。重要 URL 改版、產品下線、語系增加後，這份目錄也要跟著更新。沒有人負責時，它很快就會變成另一份過期 sitemap。若團隊連 canonical、站內連結與內容更新都還排不完，把 llms.txt 塞進季度 KPI，優先順序就很可疑。
可以用一個很普通的排程方式判斷。建立檔案若只需整理既有頁面，之後跟著文件改版檢查，成本可控；若每個產品部門都要開會決定「希望 AI 看見什麼」，還要維護多語系與審核流程，那已經不是順手加檔。此時應先確認到底有哪個目標工具會讀，以及那個工具帶來的用途是否足以支撐維護工時。
公開檔案也要照一般內容治理處理。別放內部網址、尚未發布的產品資訊或原本不該公開的文件摘要。llms.txt 沒有特殊權限層，能讀根目錄的人都能看。把敏感內容寫進去再用 robots 規則遮掩，不能取代正確的存取控制。
真的要放，內容只需回答幾個實際問題：本站是什麼、哪些頁面最能代表主題、每個連結提供什麼資訊。不要塞一串關鍵字，也別把同一段品牌文案複製到所有語系。需要先取得合規 Markdown 骨架，可以用本站的 llms.txt 產生器起稿，再由熟悉網站的人刪改。
我會把它排在低成本、低期待的位置。Google 已說不拿它做 Search 排名；其他工具若有採用，應看該工具的公開文件與實際用途。這樣安排不必把檔案妖魔化，也不會讓它吃掉較重要的技術與內容工作。
市場通病：把接觸紀錄包裝成效果
llms.txt 只是這波 GEO 話術裡最好懂的一例。常見簡報會排出一條很順的故事：改了 Markdown、加了 schema 或提交一個新檔案，接著 bot 來了，AI Overview 也出現引用，所以那個動作有效。你看到的是挑過的成功畫面，不是完整樣本。每張截圖都可能是真的，但故事中間的因果仍是空白。
AI SEO 的常見爭議多半卡在「系統碰過內容」究竟代表什麼。抓取是取得 URL，索引是整理與保存，檢索是回答時取材，排序與引用選擇還有各自的條件。一次觀察若沒有拆層，很容易把前面的寬鬆入口講成後面的偏好。
FAQ schema 是一個熟悉例子。頁面加上結構化資料後被 AI Overview 引用，兩件事同時出現，不足以證明引用由 schema 造成。需要比較相同內容在有無 schema 時的表現，還要控制網站權威、索引狀態、文字差異與查詢波動。實務案例通常沒有這組對照。
Markdown 也常被講成「LLM 比較愛吃」的格式。模型處理純文字很自然，HTML 清理品質也確實會影響取得的正文，但這跟特定副檔名得到引用加權沒有直接關係。一篇 HTML 若標題、正文、表格與導覽結構清楚，抽取器照樣能取得內容。要比較格式，應用相同資訊做有無轉換的對照，而非拿一篇新寫的 Markdown 好文去對一篇多年未更新的舊 HTML。
月報裡可以要求每個 GEO 成效主張多放兩欄：「其他可能原因」與「目前不能回答」。前者逼團隊列出品牌新聞、索引更新、查詢季節性等干擾；後者直接說清楚資料邊界。這兩欄不漂亮，卻能避免下一季拿同一張截圖繼續推演。
IndexNow也常遇到相似的誤讀。它能通知有支援的搜尋引擎 URL 已更新，解決的是發現速度。後續索引、排序及流量仍由其他系統決定。把「較快知道」寫成「排名較好」，只是把不同階段疊成一句話。
整個 AISO／AI 搜尋最佳化市場偏愛這種做法，有很現實的原因。交付一份檔案、貼一張 log、勾選一項 schema，很容易報價，也容易在月報呈現。建立真正有引用價值的內容、讓第三方願意獨立描述品牌，時間長，成果又不會整齊地落在某一天。
服務方有商業誘因並不等於主張必然錯。只是當提出主張的人同時販售那項服務，證據門檻理應提高。要看測試如何排除其他因素、結果能否重現、失敗案例有沒有一起揭露，而不是數有幾位講師貼出相似截圖。
good SEO is good GEO比較接近目前能採取的穩健路線。它並不聲稱傳統 SEO 動作會保證 AI 引用，而是承認 AI 檢索仍需要可存取、可理解、有來源的網路內容。SEO 的基本工作原本就在處理這些條件，至少每一項還有搜尋、讀者與網站維護上的直接用途。
證據導向 GEO，平常可以做什麼
團隊若想追蹤 AI 搜尋，不必等一個完美指標才開始。先固定一組與業務真的相關的問題，記錄不同系統是否提到品牌、描述是否正確、引用了哪些來源。會讀 X 即時討論的 Grok 也該放進名單，站上對於讓品牌走進 Grok 的回答另有完整拆解。提問時間、地區、帳號狀態與模型版本盡量一併留存，否則前後兩次很難比較。
這份追蹤表是體檢，不是歸因工具。某月品牌提及增加，可能來自模型更新、新聞事件、競爭者變化或搜尋索引調整，不能直接算到某一篇文章或一項技術改動頭上。它的用途是發現描述錯誤、來源缺口與長期方向。
內容端可以檢查品牌最常被問的問題，是否有可引用的原始頁面。價格、規格、方法、限制與更新日期要放在清楚位置。真的有研究、測試或案例，就把方法和邊界寫出來。整理舊文時，也要讓目前版本與歷史版本容易區分。
原始頁面不必都寫成萬字指南。產品規格需要明確版本與欄位，研究頁需要方法、樣本與原始材料，政策頁要有生效日期，作者頁則交代專業背景與負責內容。讓不同問題各有一個清楚答案，比把所有關鍵字擠進同一篇「終極指南」容易維護。
若第三方一直把品牌描述錯，先追查錯誤從哪裡開始。可能是舊新聞稿仍可索引、經銷商頁面沒更新，或自家不同語系互相矛盾。修正這些來源比調整 llms.txt 形容詞更接近問題。模型做查詢扇出時遇到彼此一致的最新資料，也比較不需要在衝突版本裡猜。
技術 SEO仍負責最基本的可達性：伺服器能穩定回應、重要頁面沒有誤擋、canonical 合理、JavaScript 不會讓核心內容消失、內部連結能讓爬蟲走到正確頁面。這些工作不新潮，但每個後續討論都以它們正常為前提。
站外部分要看獨立來源。用實體 SEO的角度整理名稱、品牌關係與公開資料，可以減少同一實體被描述成幾個版本。爭取媒體、產業組織、社群使用者或合作夥伴在各自脈絡裡準確提及，比在自有網站重複品牌宣稱更有查核價值。
這裡也別走到另一個極端。沒有公開證據能讓我們把「十個獨立來源」直接換算成某個模型權重，更不能保證一篇第三方報導會帶來 AI Overview。獨立提及值得投入，是因為搜尋與讀者本來就會用到，而且它讓系統有更多可交叉查找的材料。這個理由已經夠了。
PBN、互引俱樂部與付費 dofollow 版位看似能快速製造提及，卻帶著傳統搜尋政策風險，也很難算作獨立證據。若十個網站共用作者、範本或交易關係，表面數量不等於十個互不相干的來源。這類捷徑常把 GEO 的不確定性，和舊式連結操弄的風險綁在一起。
追蹤表也要留「未提及」與「描述錯誤」，不要只收成功畫面。假設固定 30 個問題，某次只有 4 題出現品牌，報告就應保留完整 30 題與當時答案。下個月變成 6 題時，團隊才有辦法回看新增的是哪兩題、引用來源是否合理，而非只看到成長百分比。
一套證據強度檢驗
遇到「某做法對 AI 搜尋有效」，先替現有材料分級。這套 Level 0–5 不是學術標準，而是實務審稿尺，目的在防止團隊拿低層觀察回答高層問題。
Level 0：AI 自己說有效
證據只有 ChatGPT、Gemini 或其他模型的一段自評。它可以幫你蒐集假設與常見說法，不能驗證自家產品實際如何處理某個檔案。提問方式、檢索結果與語料風向都可能改變回答。
Level 1：有人在網路上說有效
論壇心得、社群貼文、個案簡報與服務商案例都放在這層。它們能提供線索，也可能揭露值得測的指標。缺少對照、樣本選擇與完整失敗紀錄時，還不能推廣到其他網站。
Level 1 並非沒有用。很多技術問題最早就是從零散案例冒出來，重點是把它當成假設來源。記下網站類型、發生日期、目標系統與觀察方法，找到更多條件相近的案例後，再決定值不值得投入測試。
Level 2：可觀察到抓取或索引
伺服器 log、CDN bot 報表、Search Console 狀態及 site: 結果屬於這層。它們適合驗證技術路徑，例如 URL 能否被發現、回應碼是否正常。llms.txt 最常見的證據大多停在這裡。
Level 3：有對照組的單一測試
測試至少有處理組與對照組，兩邊在主題、站況、內容與觀察期間盡量接近，只改一個主要變因。這時才開始能討論那個變因是否和結果有關。單站、單語系或少量查詢仍限制了外推範圍。
SEO 環境很難做出實驗室級控制，所以 Level 3 不要求兩站完全相同。它要求研究者誠實列出差異、事前定義結果，並避免測試期間一邊大量更新、一邊保持不動。資料有雜訊很正常，方法不透明才難以判讀。
Level 4：可重複的對照實驗
不同網站、時間或執行者用相近方法得到一致方向，測試也公開足夠細節讓別人重做。結果若只在某個品牌查詢或短暫版本成立，應把適用邊界寫出來。llms.txt 目前沒有這一級的業界證據。
Level 5：官方文件確認＋可獨立觀察效果
目標系統的官方文件明確確認規格用途，外部測試也能在受控條件下重現相應效果。官方文字處理「系統怎麼設計」，獨立觀察處理「真實環境是否照預期運作」。Google 把 llms.txt 列在破除迷思區，現況顯然到不了這層。
分級後，討論會務實很多。Level 2 的 log 可以回答「爬蟲有沒有來」，若團隊想回答「llms.txt 是否提高引用率」，下一份工作應是設計 Level 3 測試。指標、查詢集、觀察期間、對照條件與停止規則要先寫，別看到一個漂亮結果才臨時決定什麼算成功。
也可以把分級放進採購與內容審核。供應商若宣稱某工具能增加 AI 能見度，請他標出現有證據在哪一級；編輯收到「LLM 偏好某格式」的選題，也先找官方文件與對照測試。答案停在 Level 1 或 2 不必立刻否決，只要把預算、用詞與期待一起降到相稱位置。
這種測試很麻煩。兩個網站幾乎不可能完全相同，AI 回答又有波動，污染變因也多。承認限制不會讓測試失去價值，反而能讓下一個人知道結果可用到哪裡。真正危險的是拿四次抓取、一次索引與一張聊天截圖，寫成已經證明因果。
問題不在檔案，而在證據被推多遠。
結語：檔案可以放，證據要分層
cats.txt 已經完成一次漂亮的反證：一份公司貓名冊能被主流 bot 抓取、被 Google 索引、被 AI Overview 引用，還能得到 ChatGPT 的正面解釋。這四件事沒有造假，但合在一起仍證明不了 cats.txt 是有效規格。Williams-Cook 稱它為 GEO 占星術，正是因為解讀先選好答案，再回頭替普通現象加意義。
我的 dogs.txt 放在自己站上，做的是同一組機制檢查。等有實際紀錄，就照抓取、索引、檢索與自評分開報告；沒有資料的格子保持空白。這比補一段看起來很專業的假 log 麻煩，也比較有用。
llms.txt 本身可以留。內容少、維護責任清楚，放在根目錄沒有問題。若網站還有舊文失準、重要頁面孤立或品牌資料彼此矛盾，先做SEO 內容更新通常能同時改善讀者體驗與搜尋基礎，llms.txt 排在後面處理即可。
做 GEO 不需要把每個新檔案都當騙局，也不需要因為 Google 不採用就把所有可能性關掉。把主張放回相稱的證據層級，知道現在看見的是請求、索引、檢索還是正式採用，決策自然會小很多，也比較不容易被下一張截圖帶走。
常見問題
llms.txt 要不要做？
可以，前提是成本低、有人維護，也沒有更急的網站問題。它可作為給特定工具或未來讀者的網站導覽，但目前沒有證據顯示它能改善 Google 排名。不要把它列成保證 AI 引用或流量的專案。
llms.txt 跟 robots.txt 差在哪？
robots.txt 用來表達爬蟲存取規則，主流搜尋引擎有既定處理方式。llms.txt 是根目錄裡的 Markdown 摘要提案，沒有強制力，也不控制爬蟲權限。兩者名稱相似，功能與採用狀態不同。
放了 llms.txt 會被 Google 懲罰嗎？
Google 官方說它不會傷害，也不會幫助搜尋能見度與排名，因為 Google Search 不使用這些檔案。正常放置不構成排名訊號。檔案若含錯誤連結或過期資訊，仍會像其他公開文件一樣造成維護問題。
ChatGPT 說 llms.txt 有效，可信嗎？
那段回答可用來了解常見論點，不能當成效果驗證。共識收斂問題會讓模型跟著網路語料的平均傾向回答；cats.txt 曾先獲得排名相關的肯定，後來又被說成玩笑。要判斷產品行為，仍需官方文件與可重現測試。
如果 llms.txt 沒有排名效果，GEO 該先做什麼？
先確認網站可抓取、重要內容可理解，並整理品牌最常被問到的事實與來源。固定查詢集追蹤描述正確度，逐步補齊第一手內容、更新日期與獨立外部提及。這些工作也不保證 AI 引用，但用途不只押在一個尚未被主流搜尋採用的檔案上。
cats.txt 和 dogs.txt 是真的規格嗎？
不是。cats.txt 是 Mark Williams-Cook 用來檢驗 llms.txt 證據門檻的惡搞檔案，四項公開結果都有文獻紀錄。dogs.txt 是我依同一手法設計、部署在自己站上的測試檔，用來分開觀察抓取、索引、檢索與 AI 自評；沒有替它編造 log 數字或回答結果。
