AI 機器人 robots.txt 的部署前審查會將一個貼上的檔案與 32 個已記載的 robots.txt 產品權杖進行比對——這些權杖由 AI 爬蟲、AI 助理、模型訓練控制項，以及 AI 相關的搜尋爬蟲所使用——並回報每個權杖的規則對你輸入的路徑是 Allow 還是 Disallow。AI Bot Robots.txt Checker 在你的瀏覽器中依據 RFC 9309 標準化的比對規則進行比對，因此結果可保持隱私且可重現。它不會擷取網站、上傳檔案或聯絡爬蟲業者；它只會評估你所提供的精確文字與路徑。要避免這次審查出錯，就必須了解每一列所代表的意義、將路徑比對視為區分大小寫、測試多個路徑，並記住「允許」的判定僅代表在已實作的協定邏輯中沒有任何 Disallow 規則符合所選路徑——並不代表業者會進行爬取、建立索引、用於訓練或遵守該檔案。請將這份報告視為發布前的健全性檢查，然後在將任何一列視為具約束力的政策前，向業者文件以及你實際上線的 /robots.txt 回應驗證關鍵權杖。
AI 爬蟲審查實際上測試了什麼
針對 AI 機器人的 robots.txt 審查比多數讀者預期的更為限縮。這個檢查工具會評估一個貼上的 robots.txt 對照一份固定的 32 筆產品權杖表，並為每一列標註其業者與用途類別（AI 爬蟲、AI 助理擷取、模型訓練控制項，或 AI 相關搜尋爬蟲），然後回報你所輸入路徑的允許或封鎖結果。它不會查詢 DNS、向任何爬蟲發出請求，也不會估計模型下游可能的行為。
這 32 列是 robots.txt 產品權杖，而非統一的 HTTP User-Agent 標頭字串列表。部分業者會發布專屬的控制權杖——Google-Extended 與 Applebot-Extended 是著名的例子——用來表達訓練或資料使用偏好；其他列則追蹤擷取產品或目錄來源條目，檢查工具會將其標示出來，而非以第一方驗證的方式呈現。由於爬蟲產品會隨時間變動，沒有任何靜態表能永遠適用；這正是為什麼報告會被定位為部署前審查，而非具約束力的稽核。將其串接起來的協定邏輯遵循 RFC 9309：user-agent 產品權杖的比對不區分大小寫，路徑則從開頭起以區分大小寫方式進行比對，最長的符合模式優先，長度相同時 Allow 規則勝過 Disallow 規則。
會讓 32 權杖報告失效的錯誤
有六種反覆出現的錯誤會悄悄讓報告失效。它們很容易犯，因為 robots.txt 看起來就像純文字，而比對規則則藏在冗長的列表背後。
把每一列都當作字面上的 User-Agent 標頭。 並非所有 32 個權杖都是 HTTP 標頭字串。有些是專屬的控制權杖；其他則來自補充目錄。表格區分了由業者記載的列與目錄來源的列，讓你能正確權衡兩者。關於此區別的專文指南請見 Are All 32 Robots.txt Tokens Literal User-Agent Headers?。
假設路徑比對不區分大小寫。 RFC 9309 將 User-agent 產品權杖視為不區分大小寫，但要求路徑比對必須區分大小寫。/Private 與 /private 是不同的路徑，在同一組規則下可能產生不同的結果，而這正是會悄悄暴露或隱藏整個 URL 樹的錯誤類型。
只測試一個路徑就以為完成了。 最長符合規則會藏住邊界情況。對首頁的測試無法告訴你 /api/ 或 /drafts/ 路徑會發生什麼事，因此在發布前值得跑幾條具代表性的路徑——若要模擬帶參數的爬蟲行為，也包括一條帶有查詢字串的路徑。
把「允許」的列視為正向證據。 「允許」的判定僅代表在已實作的邏輯下，沒有任何 Disallow 規則符合該路徑。它並不能證明業者會爬取、建立索引、引用、用於訓練或顯示該頁面。搜尋索引、摘要控制、訓練偏好與即時網路封鎖都是各自獨立的控制項。
錯誤解讀合併後的群組。 當多個 User-agent 群組指向同一個產品權杖時，其規則會合併，而特定的產品權杖群組會覆寫萬用字元群組。位於未提及你所關心權杖之群組內的特定 Allow 規則，並不會影響該權杖對應的那一列。
忽略範圍限制。 檢查工具最多接受 500 KiB 的 UTF-8 輸入與 5,000 條非空白的存取規則。即使檔案在位元組限制以內，仍可能因符合已記載的總和比對工作量上限而被拒絕，因此處於邊界的檔案在測試前應先瘦身。
在瀏覽器中執行部署前審查
一段簡短且可重複的工作流程能在發布前抓到多數問題。每一步都直接取自該工具經驗證的操作程序，因此結果在不同同事與審查之間都能保持可重現。
- 開啟 AI Bot Robots.txt Checker，並將精確的正式環境 robots.txt 文字貼入輸入框。請將檔案控制在 500 KiB 以下；若解析器觸及其已記載的總和比對工作量上限，即使在該限制內的檔案仍可能被拒絕，因此請在測試前先修剪雜訊。
- 輸入一條以斜線開頭、區分大小寫的 URL 路徑。若你想模擬的爬蟲請求包含查詢字串，請一併加入，因為檢查工具會從開頭起比對路徑，並將查詢字串視為輸入的一部分。
- 執行檢查。報告會列出全部 32 個產品權杖，附帶其業者、用途類別、來源狀態，以及對你所輸入路徑的允許或封鎖判定。請逐列檢視，並標記任何讓你意外的判定。
- 針對每一列令你意外的結果，閱讀規則鏈以找出符合的規則——先看特定產品權杖群組，再看萬用字元群組——並套用最長符合的平手規則（長度相同時 Allow 獲勝、美元符號錨定至路徑結尾、星號可符合任意序列）。
- 部署前，請將每個關鍵列與業者的現行文件交叉比對。爬蟲產品會隨時間變動，補充目錄條目僅會被標示出來，而非經第一方驗證。
解讀 32 權杖報告：快速導覽
回傳的表格為每一列提供四欄情境資訊，而非僅有判定結果。標籤組合在 32 列之間保持一致，讓你不必每次重讀工具文件即可快速掃視。
| 欄位 | 它告訴你什麼 |
|---|---|
| 業者 | 擁有該權杖的公司或專案 |
| 用途類別 | 該列屬於 AI 爬蟲、助理擷取、模型訓練控制項，或 AI 相關搜尋爬蟲 |
| 來源狀態 | 業者第一方記載、受管理的交叉參考，或補充目錄條目 |
| 結果 | 對你所輸入精確路徑的允許或封鎖判定 |
請先將表格篩選為業者第一方的列，抽樣檢視真正具有分量的政策，並將受管理與補充性質的列視為次要訊號。重大產品的最新交叉參考維護於 Cloudflare AI crawler reference，而受管理 robots.txt 行為則記載於 Cloudflare managed robots.txt reference。
報告之後：工具無法執行的即時檢查
這個檢查工具是確定性的且離線運作，因此無法偵測一類只有在檔案上線後才會顯現的問題。在報告看起來正確之後，請以爬蟲會使用的相同 scheme 與主機擷取正式環境的 /robots.txt，確認回應為純文字並回傳成功狀態，然後將該回應與你所貼上的文字逐位元組比對。即使只是一個空格的差異，也可能翻轉某個模式的判定。
這個工具也看不到重新導向、CDN 覆寫、僅對特定用戶端提供的語法、不正確的主機範圍、快取延遲，或無法連線的檔案。關於檢查工具實際檢查與不檢查項目的專文說明請見 Does the AI Bot Robots.txt Checker Fetch Your Live Website?。對於高風險路徑，請以業者端的工具（若存在）補強報告——例如 OpenAI 的發布者指南與 Anthropic 的網頁爬蟲控制項——並檢查伺服器記錄中的實際擷取流量。
Robots.txt 是自願性的。它並非身分驗證、授權、防火牆或合約性的強制系統。爬蟲可以忽略該檔案，而公開列出敏感路徑反而會將其曝光。請以伺服器端的存取控制保護機密或付費內容，並另外監控實際流量；請將這份報告視為其中一項輸入，而非證明。
值得了解的硬性限制
比對引擎強制實施三項限制，這會影響你所能貼上的內容而不致發生意外。第一項是 500 KiB 的輸入上限，呼應 RFC 9309 對解析器至少應處理該數量 UTF-8 輸入的預期。第二項是 5,000 條非空白存取規則（User-agent、Allow 與 Disallow 指令）的硬性上限，而 sitemap 或 crawl-delay 行不計入此限制。第三項是 20,000,000 次操作的總和比對工作量預算，用以防止惡意的長路徑搭配大型規則集凍結主執行緒。
在這些限制之內，路徑從開頭起進行比對，星號與結尾美元符號錨定依協定定義運作，註解在解讀前會被移除，而空白的 Disallow 值不會封鎖任何內容。若沒有適用的 Allow 或 Disallow 規則符合，結果會回報為允許。這些限制使得結果在相同的文字與路徑下可重現——當同事需要在審查中確認你的解讀時，這相當實用。