有一個檔案,超過四分之一的網站已經默默放上去了,Google 卻在官方文件裡親口說:放了不會幫你、不放也不會扣你的分。這個檔案就是 llms.txt。
聽過它的人通常都卡在同一個地方,知道它號稱是「給 AI 看的網站地圖」,也看過教學說建立起來只要幾分鐘,可是沒人講清楚——它到底有沒有用、值不值得你現在花這個工夫去做。llms.txt 是一個放在網站根目錄的純文字 Markdown 檔,用來主動告訴 AI 模型「這個網站裡哪些內容最重要、最該被引用」,可以把它想成你親手為 AI 整理的一份重點導覽。問題是,它目前還只是一個提案中的標準,沒有任何一家主流 AI 服務正式承諾會讀它。
所以這篇不打算只教你怎麼貼一個檔案上去,而是先帶你看懂它的運作邏輯,再用一張表把它跟 robots.txt、sitemap.xml 的職責分清楚,最後給你一套判斷框架——哪些網站現在就值得做,哪些網站做了也是白忙。先從它想解決什麼問題講起。
llms.txt 是什麼?為什麼會冒出這個檔案
llms.txt 是一個放在網站根目錄、網址長得像 yourdomain.com/llms.txt 的純文字檔案,用 Markdown 格式寫成,內容是一份精選過的重點清單,告訴大型語言模型(LLM)與 AI 代理:這個網站在做什麼、哪幾個頁面最值得讀、該怎麼正確引用你。
它的源頭很清楚。這個提案由 Jeremy Howard 在 2024 年 9 月正式提出,他是 fast.ai 的共同創辦人,也是機器學習圈相當有份量的人物。會有這個構想,是因為 AI 在讀網站時遇到一個實際的瓶頸。
現在很多網頁內容其實不是寫給 AI 看的。一個頁面裡可能塞滿選單、橫幅廣告、彈出視窗、追蹤碼、JavaScript 動態載入的區塊,真正有用的那幾段文字,被埋在一大堆雜訊中間。AI 模型的上下文視窗(一次能讀進去的資訊量)又有限,要它把這種複雜的 HTML 一頁一頁爬乾淨、再從裡面挑出重點,既費力又容易出錯。
llms.txt 想做的,就是繞過這段麻煩。與其讓 AI 自己摸索,不如你主動遞給它一張乾淨、好讀的地圖:這裡是核心服務、這裡是產品說明、這裡是常見問題,每一條還附上一句話說明這個連結在講什麼。AI 不必再去猜,直接照著這份清單去找它要的內容就好。
追根究下去,它的設計哲學其實跟我們已經用了二十幾年的網站檔案是同一套延伸——既然我們會用 robots.txt、sitemap.xml 幫搜尋引擎理解網站,那為什麼不為 AI 也準備一份對應的檔案?這個邏輯聽起來很順,但魔鬼藏在「主流 AI 有沒有真的在讀」這個細節裡,等一下會拆開來看。
llms.txt、robots.txt、sitemap.xml 三個檔案各自管什麼
最容易搞混的一點,是很多人第一次看到 llms.txt,會直覺以為它是「AI 版的 robots.txt」。這個理解其實不準。這三個檔案放在同一個網站根目錄,職責卻完全不同,互相不能取代。
先用一句話把三者的本質分開:robots.txt 管的是「擋」、sitemap.xml 管的是「找」、llms.txt 管的是「挑」。
| 比較項目 | robots.txt | sitemap.xml | llms.txt |
|---|---|---|---|
| 主要讀者 | 所有爬蟲(傳統搜尋與 AI 都會看) | 傳統搜尋引擎(Google、Bing 等) | 大型語言模型、AI 搜尋與 AI 代理 |
| 核心目的 | 規定爬蟲「能去哪、不能去哪」 | 列出網站「所有公開網址」確保被完整收錄 | 提供「重點摘要與精選連結」幫 AI 正確理解 |
| 檔案格式 | 純文字指令 | XML 結構化標記 | Markdown(人也讀得懂) |
| 對內容的態度 | 排除:擋掉不想被爬的區塊 | 收錄:把每一頁都攤開讓人找得到 | 策展:只挑最重要的端出來 |
把它們想成一間店的三種角色,會更好懂。robots.txt 像門口的管制人員,規定哪些區域訪客可以進、哪些是員工專用;sitemap.xml 像一份完整的庫存清單,把店裡每一樣商品都登記在冊,確保盤點時不會漏;llms.txt 則像櫃台給你的一張精選導覽——不是把全部商品塞給你,而是告訴你「這幾樣是我們最推薦、最值得看的」。
所以這三個檔案不是誰升級版誰,而是各管一段、彼此補位。robots.txt 處理權限,sitemap.xml 處理完整收錄,llms.txt 處理重點策展。你的網站如果經營得夠完整,理論上三個都會有,只是它們解決的根本不是同一件事。
也正因為 llms.txt 走的是「策展」而不是「全收」,它的寫法跟 sitemap.xml 剛好相反。sitemap.xml 求全,網站有幾百頁就列幾百頁;llms.txt 求精,通常只挑十到三十條最關鍵的連結。把每一篇文章都塞進 llms.txt,反而是最常見的錯誤——它不是又一份網站地圖,而是一份「最佳精選」。
llms.txt 怎麼運作?一個檔案大致長什麼樣子
llms.txt 的運作其實沒什麼神祕之處——它就是一份用 Markdown 寫的純文字清單,AI 在讀取時,會把它當成理解你網站的入口。
一個基本的 llms.txt 大致是這樣的結構——最上面用一級標題寫網站或品牌名稱,接著一段引言用一兩句話交代這個網站是做什麼的、服務對象是誰,再來用幾個區塊分類列出重點連結,每一條連結後面附上一句簡短說明。比方說一個提供線上服務的網站,可能會列出「核心服務頁」「方案與定價」「常見問題」「聯絡方式」這幾個區塊,每個區塊底下放兩三條最關鍵的連結。
重點不在於把所有網址都塞進去,而是清楚告訴 AI:這個網站是誰、提供什麼、哪幾頁最重要、該怎麼正確描述你。一份寫得好的 llms.txt,篇幅通常很小,控制在 10KB 以內,目的就是讓 AI 在最短時間內抓到全貌。
除了 llms.txt,有些技術文件平台還會額外準備一個 llms-full.txt。兩者的差別在資訊的深度。llms.txt 是精簡的索引,只給重點連結與摘要;llms-full.txt 則把大量內文整理成一份完整純文字,方便 AI 一次讀進更多細節,常見於 API 文件、開發者文件這種重內容的場景。對絕大多數一般網站來說,有 llms.txt 就夠了,llms-full.txt 是給內容量特別大、又希望 AI 讀得更深的網站準備的。
為什麼選 Markdown 而不是像 sitemap.xml 那樣用 XML?因為 Markdown 是大型語言模型在訓練階段就大量接觸、最熟悉的格式,AI 解析起來最省力、理解也最準確。XML 對傳統搜尋引擎的資料庫很好用,但對 AI 來說,多出來的標籤反而會耗掉額外的運算成本。換句話說,llms.txt 從格式到內容,整套都是為了「讓 AI 用最低成本看懂你」而設計的。
理解了它怎麼運作,接下來才是真正讓人猶豫的問題——這套設計理論上很美,但 AI 到底有沒有在讀它?
llms.txt 真的有用嗎?目前最大的爭議在這裡
先把結論講在前面。到目前為止,沒有任何一家主流 AI 服務正式承諾會讀取 llms.txt,也沒有可信的數據能證明放了它就能提升你被 AI 引用的機會。這也是它最大的爭議所在。
OpenAI、Anthropic、Google 這幾家,都沒有把 llms.txt 納入官方的爬蟲協定。一個很扎心的觀察是,把 llms.txt 放上去之後去看伺服器的存取紀錄,大多數情況下,根本沒有任何 AI 爬蟲來讀過它。SEO 工具商 Ahrefs 針對大量網站做過一次調查,發現在那些已經放了有效 llms.txt 檔案的網域裡,高達九成七在一整個月內,這個檔案收到的請求次數是零——沒有任何機器人、也沒有任何人來讀。
更關鍵的是 Google 的態度。Google 在更新後的 AI 搜尋優化指南裡,把話講得非常白——你不需要為了出現在 Google 搜尋(包含它的生成式 AI 功能)而建立任何 machine-readable 檔案、AI 文字檔或特殊標記,因為 Google 搜尋本身不會使用它們。Google 還補了一段說明,大意是:如果你決定為其他會用到這些檔案的服務維護 llms.txt,完全沒問題,但這對你在 Google 搜尋的能見度與排名「既不會有幫助、也不會有傷害」,因為 Google 搜尋直接忽略它。
這裡有一段插曲,正好是混亂的來源。Chrome 的 Lighthouse 工具在更新後,把一項檢查 llms.txt 是否存在的稽核項目,從實驗性質提升進預設配置裡。時間點剛好卡在 Google 搜尋文件說「不需要 llms.txt」的前後,於是看起來像是 Google 一邊說不需要、一邊又偷偷把它當成評分項。實際上這是兩套不同的系統——Google 搜尋的排名,和 Chrome Lighthouse 的稽核,並不是同一回事。Lighthouse 那項檢查只是看「如果你有放這個檔案、它能不能正常開啟」,沒放也只會標示為不適用(N/A),不是排名扣分。Google 的工程師後來也補充說明,llms.txt「不是為了搜尋而做的」,它比較像給 AI 工具解析開發者文件時「省一點 token 的暫時性權宜手段」,還拿它類比早年那個早已被棄用的 keywords meta 標籤。
那為什麼還有超過四分之一的網站把它放上去了?答案其實有點微妙——大家都想影響自己在 AI 時代的能見度,卻又缺乏真正有效的工具,於是只要出現一個「感覺像是能掌控一點什麼」的做法,就會有人搶著做。換句話說,目前 llms.txt 的高採用率,很大一部分是被「萬一以後 AI 開始讀了呢」的心態推動的,而不是因為有人證明它現在真的有效。
不過,把話說死成「完全沒用」也不公平。下一節就來看,它確實對某一類網站有實際價值。
哪些網站值得優先做 llms.txt?哪些做了是白忙
把上面的爭議攤開來看,會發現 llms.txt 不是「該不該做」這種一刀切的問題,而是「對你這種網站值不值得做」的問題。判斷的關鍵,在於你的內容是不是真的會被 AI 拿去解析、而且解析正確與否對你很重要。
從目前實際採用的情況可以看出一個很清楚的規律:率先把 llms.txt 用起來的,幾乎清一色是開發者工具、雲端服務與技術文件平台。像 Anthropic、Stripe、Cloudflare、Vercel、Supabase、GitHub 這類公司,它們的共同點是——內容大量、結構複雜、而且服務對象本來就常常透過 AI 工具來查資料。當工程師用 AI coding 助理去問某個 API 怎麼用,這份整理乾淨的純文字文件就真的派得上用場,因為 AI 是直接、即時地去讀它。
所以如果你想要一個簡單的判準,可以這樣分。以下這幾類網站,做 llms.txt 比較可能划得來:
- 技術文件、API 文件、開發者文件——讀者本來就常用 AI 助理查,AI 即時讀取的機率高。
- SaaS 或軟體產品官網——服務說明、定價、整合方式這類資訊,最怕 AI 講錯。
- 內容結構清楚、有明確主題分類的知識型網站——本來就適合用一份精選清單導覽。
- 內容量大、又希望 AI 讀得更深的網站——可以再進一步搭配 llms-full.txt。
反過來,這幾種情況現在做 llms.txt,多半是把時間花在看不到回報的地方:
- 只有幾頁簡介、內容更新很少的小型網站——沒什麼好讓 AI 精選的,放了形同空殼。
- 內容會頻繁變動的網站,例如電商的庫存、價格、促銷——llms.txt 一旦沒同步更新,反而會餵給 AI 過時的錯誤資訊。
- 含有會員資料、客戶資訊或敏感內容的頁面——llms.txt 是公開檔案,誰都能打開來看,這類內容本來就不該寫進去。
- SEO 基礎還沒打穩的網站——內容深度、原創性、作者權威都還沒做好之前,先去糾結一個成效未明的檔案,順序是反的。
特別要提醒最後這一點,因為它最容易被忽略。如果你現在的網站連基本的內容品質、結構化資料、頁面權威都還沒顧好,llms.txt 不會回頭幫你解決這些問題。它頂多是在你已經有好內容的前提下,多遞一張導覽給 AI;它本身不會無中生有地創造價值。Google 在那份指南裡其實也給了同樣方向的建議——與其把資源砸在 llms.txt 這種成效未明的檔案,不如把力氣放在頁面內容的深度與作者權威的建立上。
還有一個台灣網站主特別會關心的角度。對經營繁體中文內容的網站來說,llms.txt 有一個比較在地化的潛在用處。目前主流的大型語言模型,訓練資料裡繁體中文的比重相對偏低,AI 在描述台灣的品牌、在地服務或專有名詞時,偶爾會出現語意偏差、用詞不道地、甚至張冠李戴的情況。透過在 llms.txt 裡用標準、準確的繁體中文,主動寫清楚品牌的正式名稱、服務範圍、在地用語,理論上可以幫 AI 校正一部分理解,降低它把你講錯的機率。這個用途目前還缺乏大規模實證,但它至少是一個對繁中網站合理的著力點。
做 llms.txt 之前,先想清楚這件事
llms.txt 的真實定位,比它被包裝出來的樣子要樸素得多。它不是一個能讓你在 Google 排名往上跳的捷徑,也不是放上去就能保證被 AI 引用的魔法檔案。它就是一份你主動寫給 AI 看的網站重點導覽——目前還在提案階段,主流 AI 也還沒正式承諾會讀。
所以與其問「該不該做」,更實際的問法是:你的內容是不是常被 AI 解析、解析正確對你重不重要、以及你手上更該優先處理的事是不是已經做好了。如果你經營的是技術文件、開發者工具或結構清楚的知識型網站,花一點時間建一份 llms.txt 是合理的投資;如果你的網站還在打內容地基,那這份檔案可以先放著,等真正的需求出現再做也不遲。
工具會一直冒出來,但讓你被 AI 看見、被搜尋看見的根本,從來不是某一個檔案,而是你內容本身的份量。把該做好的內容做扎實,llms.txt 這類檔案要補,隨時都補得上。
