超過四分之一的網站，已經在根目錄放了一個叫 llms.txt 的檔案；但攤開最新的追蹤數據，這些檔案裡有九成七，從頭到尾沒被打開過一次。一邊是穩定往上衝的採用率，一邊是幾乎掛零的實際使用，這個反差，正好說明「llms.txt 到底該不該做」這個問題，答案一直很分裂。
llms.txt 是什麼？它是一個放在網站根目錄、用 Markdown 格式寫成的純文字檔，目的是主動告訴大型語言模型（LLM）「這個網站在做什麼、哪幾頁最值得讀」，理論上讓 AI 不必自己在選單、廣告與雜訊裡摸索重點。這個構想立意良善，問題出在「理論上」三個字——Google 最新的官方文件已經把立場說得很清楚，做不做，對你在搜尋結果裡能不能被看到，完全沒有差別。
只是官方講的是排名，現實還有更細的層次：誰真的在讀這份檔案、Chrome 為什麼又在稽核它、什麼樣的網站現在做才划算，很少有人把證據攤開來講清楚。先從這個檔案原本想解決什麼問題講起，再一路拆到你該怎麼判斷。
llms.txt 是什麼？跟 robots.txt、sitemap.xml 有什麼差異？
這個提案的源頭很明確，由 fast.ai 共同創辦人 Jeremy Howard 在 2024 年 9 月正式提出。他觀察到一個實際的瓶頸，大型語言模型的上下文視窗（context window）有限，一次能讀進去的資訊量是有上限的，而現在很多網頁裡塞滿選單、廣告橫幅、彈出視窗與 JavaScript 動態載入的區塊，真正有用的內容反而被埋在一堆雜訊裡。與其讓 AI 自己一頁一頁爬、再自己判斷哪裡是重點，不如由網站主動遞出一張乾淨、好讀的地圖，這裡是核心服務、那裡是產品說明，哪個頁面在講什麼，一句話交代清楚。
格式本身並不複雜。一份 llms.txt 只有一個 H1（網站或專案名稱）是必填欄位，通常會再加一段引言式摘要，接著用幾個 H2 區塊列出重點連結，每條連結後面附一句簡短說明。它其實常被拿來跟另外兩個檔案搞混，但三者的職責完全不同，放在同一個網站根目錄，卻各管一段。
robots.txt 管的是「能不能爬」，規定搜尋引擎與各種爬蟲哪些路徑可以抓、哪些不行；sitemap.xml 管的是「有哪些網址」，把網站所有公開頁面列成一份清單，方便搜尋引擎完整收錄；llms.txt 管的則是「挑重點」，通常只列出十幾到幾十條真正值得 AI 優先讀的連結，不是又一份網站地圖。也因為這樣，把每一篇文章都塞進 llms.txt，反而是最常見的錯誤，它從來就不是拿來求全的檔案，硬要塞滿，只會讓「精選」這件事失去意義。
Google 搜尋排名不看這個檔案，官方講得很直接
很多網站主想做 llms.txt，動機其實很單純，就是怕別人做了、自己沒做會吃虧。但 Google 在 2026 年 6 月底更新的官方指南〈Optimizing your website for generative AI features on Google Search〉裡，已經把這件事講得非常明確。這份指南有一段專門「破除迷思」的內容，直接點名 llms.txt，白紙黑字寫著，你不需要為了出現在 Google 搜尋（包含它的生成式 AI 功能）而建立任何機器可讀檔案、AI 文字檔、標記或 Markdown，因為 Google 搜尋本身根本不會用到它們。
指南接著補了更關鍵、也最常被誤讀的一點。如果你決定為其他會用到這類檔案的服務或系統建立並維護 llms.txt，完全沒問題，這麼做既不會傷害、也不會幫助你在 Google 搜尋的可見度或排名，因為 Google 搜尋會直接忽略它。也就是說，「Google 不用」跟「做了會扣分」是兩件不同的事，很多人把這兩者混在一起，才會愈想愈焦慮。
Google 搜尋關係團隊的兩位發言人，說法也一致。Gary Illyes 公開表示過，Google 目前沒有支援 llms.txt 的計畫。John Mueller 則從伺服器紀錄的角度切入，觀察後直言，沒有任何 AI 服務公開說自己會讀取這個檔案，連檢查都沒檢查過。他還把 llms.txt 拿來類比早已被 Google 棄用的關鍵字 meta 標籤，理由很直白，網站主自己宣稱的重點，不代表事實真的是那樣，比起相信一份自我宣告，AI 更傾向直接把網站內容讀一遍、自己驗證。他也補充，這份檔案的設計初衷本來就不是為了搜尋而生，比較像是給 AI 寫程式工具解析開發文件時，省一點 token 的過渡性做法，一般網站主不需要太緊張。
官方講的是排名這一塊，答案已經很清楚。但現實還有更細的層次，值得往下拆一層。這份檔案就算沒人為了排名去做，會不會真的有其他人在讀？下一段的數據，會給出比官方說法更具體的答案。
一份追蹤 13.7 萬個網站的調查，把現實攤開來看
SEO 分析平台 Ahrefs 在 2026 年 5 月做了一份研究，範圍是 137,210 個有實際流量的網域，用三個條件判斷一個網站是不是「真的有」有效的 llms.txt：伺服器要回應 HTTP 200、內容要是真正的 Markdown 格式而不是 HTML 頁面、還要排除那種軟性 404（回傳「找不到頁面」訊息）的假檔案。符合這三個條件的樣本，才會被算進統計裡。這份研究把「有沒有放」跟「有沒有人看」拆成兩個問題分開看，答案很不一樣。
採用率一年成長 8.8 倍，多數網站還是沒放
先看採用率。Ahrefs 的樣本裡，大約 28% 的網域已經發布了 llms.txt，換算下來超過三萬八千個網站有這份檔案。另一份追蹤逾三百萬個網站的獨立調查也顯示，同一段期間內，llms.txt 的採用數量成長了 8.8 倍，速度不算慢。只是 Ahrefs 這份樣本本身偏向技術能力比較高的網站主，畢竟是 Ahrefs 的付費客戶，放到整個網路的平均值來看，實際比例很可能更低。
這裡要先提醒一件容易被混在一起的事：「愈來愈多人放」跟「放了真的有用」是兩個完全不同的問題，前者是趨勢，後者才是重點。下一段的數據，會直接回答第二個問題。
打開檔案的讀者裡，真正的 AI 只占一小部分
這是整份研究裡最關鍵、也最少被講清楚的一段。在那三萬八千個有效檔案裡，97% 在整整一個月裡收到的請求次數是零，沒有任何機器人、也沒有任何人打開過。真正有動靜的，只剩下大約一千一百個網域，加總起來也只有兩萬兩千次請求，分散到全網的規模來看，等於幾乎沒有存在感。
更值得細看的，是這剩下的少數請求，到底是誰發出的。占比最高的一類，其實是 SEO 稽核工具，大約兩成二；再來是難以歸類的雜項機器人，接近一成五；接下來是一般的網路爬蟲，一成三左右；還有專門偵測網站用了哪些技術的工具，一成一出頭。把所有跟 AI 沾得上邊的請求全部加起來，包括負責幫產品做整合的 AI 代理工具、拿內容去訓練模型的 AI 訓練爬蟲、各類 AI 助手，以及最貼近「使用者當下問問題、AI 立刻去查資料」情境的即時檢索機器人，四類合計也只占整體請求的一成九左右。而其中最後那一類，也就是像 OAI-SearchBot、PerplexityBot 這種真正會在使用者提問當下去查資料的檢索機器人，占比只有整體請求的約百分之一。
換句話說，多數點開 llms.txt 的，根本不是要引用你內容的 AI，而是在檢查你有沒有做這個檔案的各種監測工具與同業。這也解釋了為什麼「放了會不會被 AI 引用」跟「有沒有放這個檔案」，目前幾乎測不出關聯。
同樣是 Google，Search 與 Chrome 為什麼各說各話？
看到這裡，你可能會有一個疑問。既然 Google 搜尋團隊都說不需要了，為什麼 Google 自家的 Chrome 瀏覽器，卻在最新版的 Lighthouse 稽核工具裡，把 llms.txt 檢查放進了預設項目？這聽起來像是自相矛盾，但拆開來看，其實是兩個團隊在回答兩個完全不同的問題。
Chrome 官方文件把話說得很清楚，llms.txt 是一項「新興慣例」，用來提供網站內容的機器可讀摘要，設計對象是大型語言模型與 AI 代理程式；如果網站沒有這個檔案，代理程式可能得花更多時間檢索整個網站，才能搞懂它的高層結構與主要內容。這段話的重點，其實不是「排名」，而是「AI 代理程式讀你網站的效率好不好」，跟搜尋結果完全是兩碼事。
而且這項稽核的「罰則」其實很輕。只有在抓取 llms.txt 時真的發生伺服器錯誤，Lighthouse 才會標記出來；如果檔案根本不存在、回傳 404，結果會被歸類成「不適用」，因為目前提供這個檔案仍然是選用做法，不是硬性規定。整個「Agentic Browsing」這一整類稽核，官方也標得很清楚，目前仍屬實驗性質，還在持續調整。
簡單整理一下分工。Google 搜尋關心的是「你要不要靠這個檔案，出現在搜尋結果與 AI Overviews 裡」，答案是不需要；Chrome 關心的是「你的網站，對瀏覽器裡跑的 AI 代理程式好不好讀」，這是另一件事。同一家公司裡，兩個產品團隊本來就在解決不同的問題，不是誰推翻誰的說法。那如果這份檔案真的不是為了排名而生，它原本設計的使用情境是什麼、現在誰用得上，才是更值得往下問的問題。
真正用得上的場景，只剩開發文件和 AI 寫程式工具
這份提案的原始說明裡寫得很清楚，設計者一開始設想的使用時機，是「使用者當下需要時」，也就是某個工具在你發問的那一刻，即時去查一份文件，而不是 AI 事先把整個網路爬過一遍、拿去訓練模型。這個區分很關鍵，也剛好呼應前面數據裡的一個現象，占比相對高的 AI 代理工具與 AI 助手，多半屬於「當下查」這一類；至於「事先訓練」那一類的 AI 爬蟲，反而占比更低。
具體套進真實情境會更好懂。舉例來說，假設你是工程師，正在用一套 AI 寫程式工具開發，把某個技術文件站指給它當參考，這時候，一份乾淨的 llms.txt 能讓工具很快找到重點頁面，不必自己在一堆導覽列、樣式表與行銷文案裡摸索。這也是為什麼率先採用 llms.txt 的，幾乎清一色是技術文件站、API 文件、雲端服務這類網站，像 Anthropic、Cloudflare、Stripe 這種內容量大、服務對象本來就常用 AI 工具查資料的公司，都能在自己的網域找到這份檔案。這不是說這些公司做得比較好，而是它們的讀者組成，剛好就是這份檔案原本設計要服務的那群人。
有一件事也值得提醒，避免你誤會得太樂觀。連 Anthropic、OpenAI 自己都各自維護了 llms.txt，但這只代表它們把自己的文件整理成這種格式，並不等於它們的爬蟲會主動去讀「別人網站」的 llms.txt。根據公開資訊，OpenAI 的爬蟲遵守 robots.txt 的規則，但沒有正式表態會使用 llms.txt；Anthropic 發布了自己的檔案，卻也沒有聲明旗下的爬蟲把這個標準當成讀取依據。換句話說，「自己有做」跟「主動去讀別人的」，是兩件不能畫上等號的事，這也是這份檔案目前最容易被過度解讀的地方。
你的網站，現在該不該做這個檔案？
把前面幾節的證據放在一起看，與其糾結「該不該做」這種是非題，不如換成三個問題問自己，答案會清楚很多。
第一、你的內容主要是寫給誰看的？ 如果你的網站本來就是技術文件、API 文件，或是開發者會拿去查閱的知識庫，llms.txt 的建置成本很低，也有明確對得上的使用情境，做了無妨。如果你經營的是一般的形象官網、部落格或電商，讀者是一般消費者而不是工程師，這份檔案目前能帶來的效益，趨近於零。
第二、你真正在意的是排名，還是被 AI 工具正確理解？ 如果目標是被 Google 搜尋看到，官方已經說得很明確，這條路走不通，該把力氣放回內容本身的深度、結構化資料，以及既有的技術 SEO 上，這些才是 Google 真正會用來判斷你的依據。如果目標是讓 AI 寫程式工具或技術類代理程式更容易讀懂你的文件，這才是這份檔案原本設計要解決的問題，值得花時間做好。
第三、你的網站內容變動快不快，有沒有機密或會員資料？ llms.txt 是完全公開的檔案，任何人都能打開來看。內容變動快的網站，像是價格、庫存、促銷活動這類經常更新的頁面，一旦檔案沒同步更新，反而會讓 AI 讀到過時的錯誤資訊；含有客戶資料、內部文件或商業機密的頁面，更是完全不該被寫進這份公開清單。這兩種情況，維護一份可能過時、甚至不該公開的摘要，風險本來就大於好處。
三個問題問完，答案通常已經很明顯。對絕大多數一般網站主而言，眼前的機會成本，不是「做了會不會有害」，而是把同一段時間拿去做內容本身、拿去把既有的技術基礎打穩，報酬率高得多。
llms.txt 本身沒有錯，它想解決的問題也是真的存在的問題。不過真正該被質疑的，從來不是這個檔案本身，而是把它當成不用驗證就能相信的捷徑這種心態。它比較像是一份寫給少數會讀它的工具看的備忘錄，不是寫給 AI 搜尋的通行證，這兩者的差別，值得每個猶豫要不要做的人先想清楚。
如果哪天主流 AI 真的公開承諾會讀取這個檔案，數據會很快告訴大家，不需要誰替你猜。在那之前，把時間花在讀者與 AI 都讀得懂、也查得到出處的內容本身，報酬率高得多，這條路，從來就沒有捷徑可抄。