AI Bot Robots.txt Checker 會針對您貼上的單一 robots.txt 檔案，依據 32 個目前由 AI 爬蟲、AI 助理、模型訓練控管以及 AI 相關搜尋爬蟲所使用的 robots.txt 產品權杖進行評估。在您貼上檔案並輸入以斜線開頭的 URL 路徑後，此工具會依據 RFC 9309 所標準化的核心比對規則，回報每個權杖的允許或封鎖結果。所有處理皆在瀏覽器中進行：檔案不會被上傳、不會擷取任何實際網站、也不會聯絡任何爬蟲業者。User-agent 產品權杖的比對不區分大小寫；路徑樣式則從開頭進行比對、區分大小寫、支援星號萬用字元，並支援以美元符號作為路徑結尾錨點。當多個群組指定同一個產品權杖時，其規則會合併；符合的產品權杖群組優先於萬用字元群組，而在同一群組內，最符合的樣式優先，長度相同時則 Allow 優先於 Disallow。此檢查器最多接受 500 KiB 的 UTF-8 輸入以及 5,000 條非空白存取規則。請將其視為一個確定性的部署前審查工具，以反映爬蟲實際讀取的協定邏輯。
由於爬蟲生態已大幅擴張，2026 年的 robots.txt 審查變得更加困難。除了傳統的搜尋引擎之外，眾多的擷取型爬蟲、AI 助理擷取器以及專屬的訓練控管權杖如今都已發布各自的產品字串。僅檢查 GPTBot 或 ClaudeBot 的網站經營者，可能會在不知情的情況下忽略 Google-Extended 或 Applebot-Extended 等訓練控管權杖，或意外地全面封鎖一個用於取得即時頁面以進行資訊接地的助理。一個專門設計、一次列舉 32 個產品權杖、採用符合協定的比對方式，並標示每列資料來源狀態的檢查器，能將脆弱的人工審查轉化為單一可重複執行的步驟。
AI Bot Robots.txt Checker 的評估內容
AI Bot Robots.txt Checker 會將最多 512,000 位元組的 UTF-8 貼上 robots.txt 解析為 RFC 9309 的 user-agent 群組。不區分大小寫的重複產品權杖群組會被合併，因此同一個機器人以不同大小寫宣告兩次時，其行為會視為單一群組。當沒有任何特定群組符合時，則套用萬用字元群組 (User-agent: *)。在適用的群組內，Allow 與 Disallow 樣式會從路徑開頭進行比對，並完整支援星號與結尾美元符號錨點的樣式。最符合的樣式優先，長度相同時則 Allow 獲勝。萬用字元段落會預先編譯並安全地進行比對，相同的適用群組政策會被快取，且整體運算量設有上限，以避免長路徑搭配大量規則組合時凍結主執行緒。
存取規則上限為 5,000 條非空白指令，整體比對運算量上限為 20,000,000 次操作。即使檔案符合 500 KiB 的位元組限制，仍可能在比對開始前因安全限制而被整體拒絕。非 User-agent、Allow 或 Disallow 指令的行不會影響結果；Sitemap 與 Crawl-delay 刻意排除於存取決策報告之外，因為它們控管的是爬取排程與探索，而非存取行為。
| 32 個權杖表格中的類別 | 該列所代表的意義 | 資料來源標示 |
|---|---|---|
| 專屬訓練控管權杖 | 業者發布獨立權杖 (例如 Google-Extended 或 Applebot-Extended)，以將模型訓練或資料使用偏好與擷取行為分開表達 | 以業者第一方說明文件為主 (若可用) |
| 爬蟲與助理擷取產品 | 擷取 URL 以驅動 AI 產品的機器人與助理，包含搜尋相關的爬蟲 | 業者說明文件，並以 Cloudflare 維護的 AI 爬蟲參考資料作為交叉對照 |
| 補充型目錄項目 | 來自交叉對照目錄而非業者第一方說明文件的權杖 | 標示為補充性質，而非以第一方驗證身分呈現 |
針對您貼上的 robots.txt 執行檢查
三個有文件記載的步驟涵蓋完整的互動流程。請將其視為嚴密的部署前檢查清單，而非隨意的一次性檢查。
- 貼上您要審查的完整 robots.txt 文字，並控制在 500 KiB 限制以內。請使用您預計部署的正式檔案，而非精簡過的範例，因為任何與正式環境不同的規則都會產生與正式環境不同的結果。
- 輸入一個以斜線開頭、區分大小寫的 URL 路徑，然後執行檢查。僅在您要模擬的爬蟲請求包含查詢字串時才一併輸入，因為路徑比對是從開頭錨定，並對整個提交的字串進行運算。
- 檢視每一條符合的規則，並在部署前根據業者目前的說明文件驗證關鍵的產品權杖。一列的資料來源狀態 (業者第一方、Cloudflare 交叉對照或補充型目錄) 會告訴您需要進行多少額外驗證。
解讀 32 個權杖結果表中的每一列
每一列對應一個 robots.txt 產品權杖，不一定等同於實際的 HTTP User-Agent 標頭。檢查器會標示業者、用途類別與資料來源狀態，以便您區分擷取型爬蟲與訓練控管權杖，以及第一方驗證項目與補充型目錄項目。結果欄會告訴您：在實作的協定邏輯下，根據適用群組與路徑樣式比對規則，所提交的路徑是否會被允許或封鎖。
| 路徑樣式元素 | 在 RFC 9309 比對下的行為 |
|---|---|
| /private | 符合 /private 以及任何以 /private 開頭的更長路徑 |
| /private$ | 僅符合 /private；美元符號會將樣式錨定在路徑結尾 |
| 樣式中的 * | 符合任何字元序列 |
| /Private 與 /private | 路徑比對區分大小寫，因此兩者可能產生不同結果 |
| 空白的 Disallow: 值 | 不會封鎖任何內容；應將其視為無操作 (no-op) |
| 適用群組中無符合規則 | 存取結果回報為允許 |
當產品權杖群組與萬用字元群組同時適用時，符合的產品權杖群組優先。當多個群組宣告同一個產品權杖時，其 Allow 與 Disallow 規則會在比對前合併。註解會在解譯前被移除，因此看起來像指令的註解是無害的。這些規則加總起來，就是為何單一檔案可能針對同一個路徑產生 32 種不同結果的原因：每一列都會根據其權杖所屬的群組進行評估，僅在沒有任何特定群組適用時才回退至萬用字元群組。
在部署前測試重要的路徑
單一路徑測試通常不足以涵蓋所有狀況。多數正式環境的 robots.txt 檔案包含需要不同處理的區段：助理應能引用的首頁、絕對不應用於訓練的內部搜尋端點、甚至不應被擷取的付費內容資料夾，以及應可供擷取但應被禁止用於訓練的封存區。請為每個具代表性的路徑執行一次檢查器，並確認每個相關列的結果都符合您的預期。針對每條路徑，請自問：哪一列是擷取型爬蟲、哪一列是訓練控管權杖，以及萬用字元群組是否意外涵蓋了特定群組所遺漏的內容？
路徑的組成同樣重要。寫成 /news 的樣式會符合 /news、/news/2026/01/ 以及 /newsletter。結尾的美元符號會將其收緊為完全符合。若您只想封鎖某個目錄而不涵蓋其下任何內容，請使用錨定樣式；若您想封鎖該目錄以及其下所有巢狀路徑，請保持不錨定。查詢字串只有在您實際將其納入提交的測試路徑時，才會被視為路徑的一部分進行比對；這在爬蟲請求 /search?q=... 時很有用，但當您提交的是爬蟲根本不會請求的路徑時則毫無幫助。
根據業者說明文件交叉核對關鍵權杖
此檢查器強制執行協定邏輯，但並不保證特定業者會以您預期的方式對待特定權杖。同一類別中的兩列，在正式環境中的行為仍可能不同。OpenAI 發布了允許其網路爬蟲的指引，以及一份獨立的「發布者與開發者」FAQ，釐清其爬蟲權杖與訓練偏好之間的關係。Anthropic 則透過支援中心記錄其爬蟲控管機制。作為更廣泛的交叉對照，Cloudflare 的AI 爬蟲與機器人流量參考資料以及其託管式 robots.txt 參考資料，說明了主要產品如何分類，以及託管式 robots.txt 檔案是如何產生的。請將這些來源視為您的驗證層：當一列為業者第一方資料時，請對照業者的現行頁面進行確認；當一列為補充型目錄來源時，請將其視為需要業者確認才能成為政策的起點。
爬蟲產品會隨時間變動，因此您所依賴的任何政策都應定期重新驗證。檢查器中針對特定權杖的某一列，告訴您的是您的檔案「今天」所提出的請求；唯有業者的說明文件能告訴您該權杖「明天」實際上的作用。
檢查器無法為您看到的限制
由於此工具不會擷取 URL，因此無法偵測重新導向、CDN 覆寫、僅提供給特定用戶端的語法、不正確的主機範圍、快取延遲，或是無法存取的檔案。它也無法確認目前實際部署的內容。封鎖結果僅代表「請求不存取」：爬蟲可以忽略該檔案，而公開列出某個路徑本身就會將其揭露。如需更深入了解執行落差，請參閱robots.txt 封鎖是否確實能阻止 AI 爬蟲的指南。允許結果僅代表在實作的協定邏輯下「沒有被封鎖」；它並不證明業者將會爬取、索引、引用、訓練或顯示該頁面。robots.txt 是自願性的，它既不是身分驗證、授權、防火牆，也不是合約執行系統。請使用伺服器端的存取控制來保護機密或付費內容，並另外監控實際流量。
搜尋索引、摘要控管、訓練偏好與即時網路封鎖是獨立的控管機制，不在檢查器的評估範圍內。發布後，請從確切的 scheme 與主機擷取實際的 /robots.txt，確認回應為純文字且回應成功，並在可用的業者工具或伺服器記錄中驗證其行為。檢查器會根據相同的文字與路徑，給出確定且可重現的結果；部署驗證則補上了其餘的環節。
如果您正在權衡選項，以笛卡兒積合併 VOSviewer 的關鍵字對此有詳細說明。