home / notes / AI 搜尋改的不是一個檔案，而是網站資訊架構
Note
AI 搜尋改的不是一個檔案，而是網站資訊架構
網站要被 AI 正確理解，改的不是單一 llms.txt，而是索引、表徵、存取與治理四層。llms.txt 可以幫 AI 知道有哪些權威頁，但不能保證它讀到的是乾淨主內容，也不能決定哪些頁面適合被引用。我的判斷是，AI 搜尋把網站從「給人點、給搜尋引擎爬」推向「可被 AI 發現、讀取、受控引用、持續治理」的系統。
普遍看法：把 AI 搜尋問題縮成 llms.txt
目前常見的討論，會把 AI 搜尋能見度收斂成幾個單點工具：加一個 llms.txt、準備 Markdown 版本、調整 robots.txt。這些都重要，但我認為這種說法不完整，因為它把不同層次的問題混在一起。
llms.txt 原始提案站把焦點放在讓 LLM 更容易取得網站資訊；OpenAI 的開發者文件則把 llms.txt放在完整 documentation index 的語境中。這代表它比較像「AI 從哪裡知道有哪些頁面」的索引線索，而不是完整的網站治理答案。
同樣地，Markdown 版本解決的是內容表徵問題；robots.txt解決的是 crawler 存取邊界問題。把三者都叫做「AI 搜尋優化」，容易讓創辦人低估實際改版範圍。
我的模型：索引、表徵、存取、治理四層
我認為比較有用的判斷方式，是把 AI 搜尋下的網站架構拆成四層。這不是正式標準，而是一個用來估算改版範圍的創辦人模型：先問 AI 如何發現權威頁，再問它讀到什麼格式、能不能存取、以及這些內容之後如何維護。
| 層次 | 要回答的問題 | 公開資訊中的對應元件 | 若只做這層的風險 |
|---|---|---|---|
| 索引 discovery / index | AI 從哪裡知道哪些頁面是權威入口？ | llms.txt、documentation index | 找得到頁面，但不代表內容乾淨或版本正確 |
| 表徵 representation | AI 讀到的是不是可解析、低雜訊的主內容？ | Markdown 版本、乾淨的文件內容 | 入口存在，但 AI 仍可能讀到導覽、樣板或不完整內容 |
| 存取 access control | 哪些頁面可被 crawler 抓取，哪些不應抓？ | robots.txt、crawler 規則 | 能限制合規 crawler，但不能當成強制安全邊界 |
| 治理 governance | 版本、過期頁、例外頁與可引用內容如何維持一致？ | 發布流程、退場規則、內容責任歸屬 | AI 可能取得已過期、重複或不適合回答的內容 |
從公開文件推導：三個工具其實在回答三個問題
從目前公開資訊來看，OpenAI 的開發者文件寫明完整 documentation index 可見 llms.txt，也寫明 documentation pages 的 Markdown 版本可透過在頁面 URL 後附加 .md 取得。這裡同時出現兩個層次：一個是索引，一個是表徵。
Cloudflare 的文件則把問題再往存取控制推進：它提供 documentation index 的位置，並說明可使用 robots.txt 控制 AI crawler 可存取哪些頁面。同一頁也說，允許 AI crawler 抓取文件，可以讓終端使用者在 ChatGPT 或 Gemini 等工具中擷取有用資訊。
我的判斷是，這些公開文件共同指向一個趨勢：網站不再只服務兩種讀者，也就是人類訪客與傳統搜尋引擎 crawler；它還要面對會擷取、摘要、轉述內容的 AI 工具。不過，這還不能推論成「只要有 llms.txt，AI 搜尋排名就會提升」。本次來源沒有支持這種強因果說法。
為什麼只做 llms.txt 不夠
llms.txt比較像是告訴 AI「這裡有一組重要頁面」。但網站被正確理解，至少還需要另外三件事：AI 讀到的內容是否乾淨、哪些頁面不該被抓、以及過期內容如何退場。
舉例來說，若網站有新版文件、舊版文件、beta 文件、部落格舊文與支援文章，單一索引檔只能表達「有哪些入口」。它不一定能處理版本衝突，也不一定能阻止 AI 工具拿到不適合對外回答的頁面。這一段是我的推論，不是來自排名或引用成效的實測。
robots.txt也不該被過度神化。Cloudflare 文件明確說明，crawler 不被強制遵守 robots.txt，但許多由 Google、OpenAI 等主要公司營運的 crawler 會尊重它。換句話說，它是合規 crawler 的協調機制，不是授權、付費牆或資安邊界。
不確定性與邊界
這個四層模型有邊界。第一，本次來源主要來自 developer documentation 情境，不能直接推論到電商、媒體、SaaS landing page 或社群平台都應採用同一套架構。文件型網站的內容穩定度、頁面結構與使用意圖，和交易型或社群型網站不同。
第二，目前公開資訊不足以判斷所有 AI crawler 是否會讀取或遵守 llms.txt。也不足以判斷 llms.txt 是否會被各家 AI 搜尋或 AI 答案引擎納入排名、引用或答案生成的正式訊號。
第三，傳統 XML sitemap、HTML 導覽、內部連結、canonical 與 SEO 基礎不應被草率宣告過時。我的判斷是，AI 可讀架構比較像是在既有網站架構上增加新的讀者與治理層，而不是把原本的資訊架構整套替換掉。
對創辦人與團隊的意涵
對文件型產品與開發者工具公司而言，AI 搜尋帶來的不是一個行銷小任務，而是產品、工程、內容與治理的交界問題。內容團隊要決定哪些頁面代表官方答案；工程團隊要讓這些內容有穩定、可讀的表徵；負責風險的人則要判斷哪些頁面不該進入 AI 的回答材料。
對 SEO、AEO 或 GEO 負責人而言，下一個值得區分的問題是「被抓到」與「被正確引用」不是同一件事。前者偏向索引與存取，後者還牽涉表徵與治理。若只看 AI crawler 流量，很容易把能見度誤判成理解度；這也是我在另一篇談 AI crawler 與 AI 能見度漏斗時想分開處理的問題。
接下來值得觀察的，不只是哪些平台支援 llms.txt，而是 AI 工具是否開始偏好更乾淨的文件表徵、是否尊重更細緻的 crawler 規則、以及網站是否能把過期內容從 AI 可讀入口中退場。這些變化若成立，網站架構的重心會從單頁 SEO 擴大到整體 AI 可讀資訊治理。
結論：把 AI 當成新的讀者，但不要把工具當成架構
我的結論是：AI 搜尋確實讓網站多了一種重要讀者，但網站不該只用一個檔案回應這件事。llms.txt、Markdown 版本與 robots.txt各自有角色；真正的改版範圍，是讓權威內容可被發現、可被乾淨讀取、可被適度限制，並且能在版本變動時持續治理。若只追求被 AI 抓到，網站最多獲得入口；若要被 AI 正確理解，架構必須升級成一套可治理的資訊系統。
常見問題
只做 llms.txt 夠不夠？
不夠。llms.txt可以作為索引或入口，但它不等於乾淨內容表徵、crawler 存取控制，也不等於版本治理。本次來源也不能證明 llms.txt會帶來 AI 搜尋排名或引用提升。
robots.txt 能完全阻止 AI crawler 嗎？
不能把它當成完全阻止。Cloudflare 文件說明 crawler 不被強制遵守 robots.txt，但許多由 Google、OpenAI 等主要公司營運的 crawler 會尊重它。
Markdown 版本為什麼重要？
從 OpenAI 開發者文件的做法來看，Markdown 版本提供一種更直接、較少版面雜訊的文件表徵。我的判斷是，這對 AI 讀取主內容可能比只提供人類閱讀版頁面更穩定。
這套四層模型適用所有網站嗎？
不一定。本篇依據主要來自文件型網站情境；電商、媒體、社群平台或高度個人化網站，可能需要不同的索引、表徵與存取策略。