llms.txt 是什麼？一份提案中的 AI 內容導覽檔
llms.txt 是一份放在網站根目錄的 Markdown 檔案，由 fast.ai 共同創辦人 Jeremy Howard 在 2024 年 9 月 3 日於 llmstxt.org 公布提案，目的是讓大型語言模型在回答使用者問題時，可以用最短路徑取得網站的核心內容索引，而不是逐頁解析 HTML。
它的副檔名是 .txt，內容卻是 Markdown 結構：必填一個 H1 主標、選填一段 blockquote 摘要、再用多個 H2 區塊列出網站關鍵頁面的連結與描述。這份檔案不是規範，也沒有任何 RFC 號碼，目前只是社群提案層級的標準。Jeremy Howard 設計它的核心動機，是 LLM 的 context window 容納不下整個網站，需要一份可機器解析、又對人類友善的「網站簡介」當作切入點。
SmartLink 在這個位置先把話講清楚：到 2026 年 4 月為止，llms.txt 仍然是「提案」而非「標準」，沒有任何主流 LLM 平台官方宣告會優先讀取它。本文要拆的不是「怎麼寫」，而是「要不要寫」，以及產業數據實際告訴我們什麼。
llms.txt 怎麼運作？格式規範與既有檔案的差異
llms.txt 的運作邏輯建立在 inference time 的索引簡化：當使用者問 LLM 一個關於某網站的問題，模型可以先抓 /llms.txt，從中拿到精煉過的網站架構與重點頁面清單，再決定要往下抓哪些連結。它的設計目標是減少 LLM 在使用者提問當下的計算與抓取成本，不是控制 LLM 訓練行為。
檔案結構：H1、blockquote、H2 連結清單
官方規範在 llmstxt.org 上以 BNF 形式列出。最小可用結構需要：第一行是 H1 標題（且只能放專案/網站名稱）、第二段選填 blockquote 寫一句摘要、第三段選填純文字段落補充背景、再用 H2 切出區塊（如「Docs」「Concepts」「Examples」「Optional」），每個區塊內以 - [連結名稱](URL)：描述 的 Markdown 列表呈現。標題若標為「Optional」，代表該段內容可被略過。
llms.txt、llms-full.txt 與 llms-ctx.txt 的角色分工
多數中文文章只談前兩者，但官方規範實際上提到四種檔案。llms.txt 是索引型，只列頁面與描述；llms-full.txt 把所有重點頁面的內容直接合併進來；llms-ctx.txt 是經過程式預處理、針對特定 LLM 優化過的版本；llms-ctx-full.txt 則是包含完整 URL 內容的最終整合包。技術文件型網站（例如 Anthropic、LangChain）通常會同時放索引型與完整型，給不同抓取成本的 LLM 選擇。
llms.txt vs robots.txt vs sitemap.xml 對照
| 檔案 | 對象 | 用途 | 是否強制 | 觸發時機 |
|---|---|---|---|---|
| robots.txt | 所有爬蟲 | 允許 / 禁止抓取路徑 | 主流爬蟲遵守，無法律強制 | 抓取前 |
| sitemap.xml | 搜尋引擎 | 提交所有可索引頁面 | 非強制，但搜尋引擎會優先採用 | 排程抓取 |
| llms.txt | 大型語言模型 | 提供 inference time 的內容索引 | 無任何主流 LLM 官方支援 | 使用者提問當下 |
| llms-full.txt | 大型語言模型 | 提供整合後的全文內容 | 同上 | 同上 |
三者解決的問題不同。robots.txt 是「禁區牌」，sitemap.xml 是「導覽圖」，llms.txt 試圖扮演的是「給 AI 的精華簡報」。從架構設計看，三者並不衝突，問題在於只有前兩者已被產業驗證有效。兩者的語法格式、crawler 控制邏輯與衝突情境，可參閱 llms.txt vs robots.txt 功能邊界完整比較。
三份根目錄檔案的對象、用途、強制力與驗證機制差異。
產業採用現況：30 萬域名研究告訴我們的事
SmartLink 的判斷向來是看數據而不看口號。SE Ranking 在 2025 年針對 300,000 個域名的研究顯示，實際部署 llms.txt 的域名比例只有 10.13%，與 directory.llmstxt.cloud 等聚合站宣傳的「超過 84 萬個網站採用」是完全不同概念的數字，後者只是收錄清單，不代表整體網路的部署率。SE Ranking 對 30 萬域名的 llms.txt 研究同時揭露，部署率在不同流量段的域名間幾乎沒有差異，意味著高流量、低流量網站的採用比例接近，這個結果反而否定了「llms.txt 是高手的競爭優勢」這類論述。
從產業類別看，技術文件型網站（API 文件、開發者社群、SaaS 文件）的部署率明顯高於整體平均，部分子集合接近 30%。相對地，電商、新聞媒體、一般企業官網的部署率都低於 8%。這個分布反映的是讀者結構：技術文件本來就被開發者拿去餵 LLM，部署 llms.txt 的邊際成本最低、邊際效益最高。
「840k 採用」與「10.13% 部署」這兩個數字會同時出現在中文社群，是因為兩者測量的對象不同。前者是「目錄收錄」，後者是「域名實際部署率」。報告引用時若不區分清楚，就會得到誤導性結論。
SE Ranking 對 30 萬域名的研究：技術文件型網站部署率約為整體 2.8 倍。
為什麼很多人說 llms.txt 沒用？兩派論點對撞
llms.txt 的爭論不是「有沒有效」，而是「在缺乏平台採用之下，自我宣告型信號是否有意義」。這是一個 SEO 產業歷史上反覆出現的辯論。
John Mueller 的 meta keywords 歷史類比
Google 搜尋倡導者 John Mueller 在 Bluesky 上把 llms.txt 比擬為 1990 年代末期的 <meta keywords> 標籤：站長宣告「我的網站關於什麼」，但搜尋引擎沒有獨立驗證機制，最後因為被濫用而被 Google 在 2009 年正式宣告排除使用。Ahrefs 整理的 llms.txt 懷疑論文章引用了 Mueller 的原話：llms.txt 與 meta keywords 的相似之處在於，兩者都是「站方說了算」的信號，而不是內容本身的可驗證屬性。
這個類比的核心不是「歷史會重演」，而是 LLM 平台與當年的搜尋引擎面對同一個結構性難題：如何在不被站長操弄的前提下，採信一份自我描述檔案。Google 當年的解法是放棄 meta keywords，改採內容、連結、行為信號的綜合評估。LLM 平台目前的選擇看起來相似：偏好 grounding 在可驗證的網頁內容上，而不是站長提交的索引檔。
SE Ranking 的 XGBoost 實證
SE Ranking 在同一份研究中用 XGBoost 模型測試 llms.txt 對 AI 引用頻率的影響。結論是：把「是否部署 llms.txt」這個變數從模型中移除，模型對 AI 引用次數的預測準確度反而上升。這代表 llms.txt 在資料中目前是雜訊，不是訊號。研究團隊也明確指出 OpenAI 與 Google 都未確認他們的爬蟲行為會優先讀取 llms.txt。
自我宣告 vs 內容驗證
從機制層看，LLM 在 grounding 階段需要的是「可驗證的事實片段」，而不是「網站方主動提交的摘要」。當 ChatGPT 或 Perplexity 引用一個來源時，引用的對象通常是具體段落、表格或數據點，這些片段必須可被反向比對到原始網頁。llms.txt 提供的是站方加工過的版本，從架構上就缺乏 LLM 想要的反向驗證能力。SmartLink 把這個視角寫進來，是為了讓讀者在LLM 引用來源的選擇邏輯中找到 llms.txt 的真正定位：不是引用來源，最多是 inference time 的索引輔助。
哪些網站該做、哪些不該做？三類場景的決策框架
llms.txt 的價值高度場景化。SmartLink 把 SERP 上常被討論的網站類型分成三類，給出產業分析師視角的判斷。
技術文件型網站：建議部署 llms-full.txt
API 文件、開發者社群、SaaS 文件站這類網站，應該同時部署 llms.txt 與 llms-full.txt。理由有三：第一，這類網站的內容本來就是 LLM 高頻引用對象，每多一個能直接讀取的純 Markdown 來源，就減少模型解析 HTML 的失敗率。第二，技術文件的更新頻率低，llms-full.txt 的維護成本可承受。第三，部署成本接近零，但若 OpenAI、Anthropic 任何一家未來宣告支援，這些網站第一時間就有資產可用。Anthropic 自家的 docs 早在 2024 年底就部署了 llms.txt，這是一個值得留意的信號。
內容媒體與部落格：只做索引型 llms.txt 即可
新聞、部落格、內容網站建議只放索引型 llms.txt，不做 llms-full.txt。原因是內容更新頻繁，full 版維護成本高且易過期。索引型則可以用自動化工具從 sitemap 直接生成，成本接近零。媒體業真正該投入的是內容本身的 schema 標註與 E-E-A-T 信號，這些目前已被驗證會影響 AI 引用，llms.txt 只是備而不用。
台灣中小企業官網：不建議優先做
SmartLink 對台灣 SMB 場景的判斷比較直接：不建議在 2026 年把 llms.txt 列為優先項目。台灣中小企業官網的痛點集中在 Schema 標記不完整、結構化資料缺漏、首頁與內頁 H 結構混亂，這些都是已被驗證會影響 Google AI Overview 與 LLM 引用的信號。把資源投在這三項，效益遠高於部署一份目前無平台支援的 llms.txt。等 OpenAI、Google 任何一方宣告支援後再補做也來得及。
部署實務：三個步驟與常見錯誤
確定要做之後，部署本身只需要三個步驟。
- 建立 llms.txt 檔案：第一行是 H1 標題（網站或專案名），緊接 blockquote 寫一句摘要，再用 H2 切出 Docs、Examples、Optional 等區塊，列表用
- [標題](URL)：描述格式。 - 放到網站根目錄：放在 https://your-domain/llms.txt 路徑下，並在 robots.txt 加入
Sitemap: /llms.txt或自訂指令引導爬蟲。注意不要用 robots.txt 阻擋 /llms.txt 自身。 - 驗證可訪問性：用 cURL 或 Firecrawl 從外部抓取，確認回傳是 Markdown 純文字而非 HTML。Anthropic、LangChain、Coinbase 都有公開的 llms.txt 可作為格式對照範本。
常見部署錯誤包含：用 .md 副檔名（規範指定 .txt）、把 HTML 內容直接放進 llms.txt（必須是 Markdown）、列表使用相對路徑（必須是絕對 URL）、忘記在內容更新時同步更新 llms.txt。多數 CMS 已有外掛可自動生成，WordPress 的 Website LLMs.txt、Drupal 的 llms_txt 模組都是常見選項。
把 llms.txt 放回 AI 搜尋信號光譜
要正確評估 llms.txt，不能只看單一檔案，要把它放回整體 AI 搜尋信號的光譜中比較。SmartLink 把目前已知會影響 AI 引用的信號分成三層。
上層信號是內容品質與 E-E-A-T。內容是否原創、作者是否可驗證、頁面是否被外部權威引用，這層信號已被反覆驗證會影響 Google AI Overview、Perplexity、ChatGPT 的引用選擇。這也是 SmartLink 在生成式引擎優化的整體框架中反覆強調的優先項目。
中層信號是結構化資料。Schema.org 的 JSON-LD 標註、Article、Product、FAQPage、HowTo 等類型，已被部分 LLM 平台採用作為 grounding 的輔助來源。Google 官方結構化資料指南仍是這層的標準參考。我們在 結構化資料對 AI 搜尋的實質影響分析中已展開過 Schema 的可驗證性優勢。
下層信號是站方自我宣告型檔案，包含 llms.txt、llms-full.txt 等。這層目前未被任何主流平台官方採用，效益主要來自「萬一未來被採用」的選擇權價值。
從預算配置看，把 80% 資源投在上中層、20% 在下層作為保險，是 2026 年較合理的做法。把 llms.txt 當主軸，反而是把選擇權買在最不確定的一層。
SmartLink 對 AI 搜尋信號的三層分層與 2026 年的建議預算配置。
llms.txt 是 Google 官方推出的標準嗎？
不是。llms.txt 由 Jeremy Howard 在 2024 年 9 月個人提出，規範託管於 llmstxt.org。目前 Google、OpenAI、Anthropic、Meta 都沒有官方文件確認他們的爬蟲會優先讀取 llms.txt。把它當成提案而非標準，比較貼近真實狀態。
部署 llms.txt 之後，ChatGPT 或 Perplexity 真的會優先引用我嗎？
沒有公開證據支持這個推論。SE Ranking 2025 年的 XGBoost 研究顯示，llms.txt 部署與 AI 引用次數沒有可測量的相關性。把它當成 inference time 的索引輔助比較合理，不是引用排名的提升器。
llms.txt 跟 llms-full.txt 一定要一起放嗎？
不一定。llms.txt 是索引型，列出網站重點頁面；llms-full.txt 把這些頁面的全文合併。內容更新頻繁的網站只做索引型即可，技術文件型網站才適合同時放兩者。
llms.txt 可以阻擋 AI 抓我的內容嗎？
不行。阻擋抓取是 robots.txt 的工作，llms.txt 設計目的是「協助理解」，不是「拒絕讀取」。要阻擋特定 AI bot，請在 robots.txt 針對 GPTBot、Google-Extended、ClaudeBot 等 user-agent 設定 Disallow。
已經有 robots.txt 跟 sitemap.xml，還需要 llms.txt 嗎？
不衝突。三者解決的問題不同：robots.txt 控制是否抓、sitemap.xml 通知有哪些頁面、llms.txt 試圖提供 inference time 的精華索引。是否補做 llms.txt，取決於網站是不是技術文件型、以及是否願意做「未來保險」型投資。
部署 llms.txt 對 Google 搜尋排名有影響嗎？
沒有直接影響。Google Search Central 沒有任何官方文件把 llms.txt 列為排名信號。如果觀察到部署後 Google 自然搜尋流量上升，更可能是同期內容品質提升或 schema 補齊的副作用，而不是 llms.txt 本身。
沒有 Markdown 結構的網站怎麼快速生成 llms.txt？
市面上有 Firecrawl、Mintlify、自架的 llms-txt 開源工具可以從 sitemap.xml 自動生成。WordPress 站可用 Website LLMs.txt 外掛、Drupal 可用 llms_txt 模組。生成後仍建議人工檢查連結描述是否正確反映頁面內容。
2026 年現在做 llms.txt 還來得及嗎？
對於技術文件型網站，現在做仍然合理，因為部署成本極低。對於一般內容網站、台灣中小企業官網，建議等到 OpenAI 或 Google 任一家官方宣告支援後再補做也來得及。SmartLink 監測的數據顯示，目前部署率在 SE Ranking 樣本中仍是 10.13%，產業還沒到「不做就被甩開」的階段。，進一步了解如何設計 llms.txt 檔案的完整規格設計方法