當你檢查 AI 機器人的 robots.txt 檔案時，32 個產品權杖中任何一個的結果都由四個細節決定：規則所在的大小寫不敏感 User-agent 群組、你輸入的大小寫敏感路徑、在 RFC 9309 下最長匹配的 Allow 或 Disallow 模式，以及路徑是否以斜線開頭。只要這四個細節中任何一個弄錯了，報告中每一列都會跟著改變，無論檔案其餘部分寫得多麼仔細。
這個 AI 機器人 Robots.txt 檢查工具會讀取你貼上的一份 robots.txt 檔案，並針對 32 個有記載的產品權杖進行比對，這些權杖被 AI 爬蟲、AI 助理、模型訓練控制項，以及 AI 相關搜尋爬蟲所使用。每個重要細節都源自 RFC 9309 的標準化匹配規則，但檢查工具也會顯示每個權杖的來源標籤，以區分第一方業者文件與目錄來源的參考資料。某一列顯示為「允許」或「阻擋」，取決於你貼上的文字加上你輸入的路徑，而非實際的網站。這種分離讓你能在檔案發布前私下反覆修改規則，但也意味著最重要的細節，就是你撰寫的規則、測試的路徑，以及報告回傳後你對照的業者文件。
32 個權杖以及為何它們並非全部都是相同的 User-Agent
報告中的 32 列是 robots.txt 的產品權杖，並非保證每個項目都會以 HTTP User-Agent 標頭的形式逐字出現。有些業者會發布專屬的控制權杖，例如 Google-Extended 與 Applebot-Extended，用以表達與檢索獨立的模型訓練或資料使用偏好。其他列則代表會自行發送 User-Agent 字串的爬蟲或助理檢索產品。表格會標示每個業者、用途類別與來源狀態，讓差異一目了然。在可取得的情況下，會優先採用 OpenAI 與 Anthropic 產品的第一方業者文件，並透過來源標籤引導讀者前往 OpenAI 的 publishers FAQ 以及 Anthropic 的 crawler controls 文件。補充的 Cloudflare Radar 目錄權杖會依此標示，而非以業者第一方驗證的身分呈現。每列的來源標籤本身也是需要閱讀的細節，因為關於訓練資料退出（opt-out）的決策，取決於專屬的控制權杖，而非檢索爬蟲權杖。
決定每個結果的路徑匹配細節
有五個路徑層級的細節會悄悄決定每個權杖的結果。路徑匹配時區分大小寫，因此 /Private 和 /private 可能產生不同的結果。你輸入的路徑應該以斜線開頭。查詢字串可以附加在後以模擬爬蟲請求，但前提是該字串是你實際收到的請求的一部分。在適用的群組內，Allow 與 Disallow 模式會從路徑開頭進行比對。星號可匹配任意字元序列，模式結尾的美元符號則用於將其錨定到路徑結尾。空白的 Disallow 值不會阻擋任何內容；它只是業者選擇不發布任何阻擋的記錄。註解會在解譯規則前被移除，因此看起來像阻擋的註解絕對不是阻擋。如果沒有適用的 Allow 或 Disallow 規則匹配，存取會被回報為允許 —— 這本身就是值得注意的細節，因為預設是「允許」而非「阻擋」。
使用 AI 機器人 Robots.txt 檢查工具執行檢查
- 貼上你想檢視的完整 robots.txt 文字，並將輸入控制在 500 KiB 上限以內。500 KiB 上限符合 RFC 9309 要求解析器至少須處理的容量，因此檔案必須已可在單一 scheme-and-host 來源上部署。
- 輸入以斜線開頭且區分大小寫的 URL 路徑，僅在你要模擬的請求包含查詢字串時才附加，然後執行檢查。
- 檢視每一條匹配的規則。對於關鍵的產品權杖，請在發布檔案前，將該列與業者的最新文件進行比對。檢查工具不會擷取網站或聯絡業者，因此驗證仍然是你自己的責任。
需驗證的規則專屬性、優先順序與來源標籤
兩個 robots.txt 欄位決定排序：User-agent 產品權杖群組，以及 Allow 或 Disallow 模式。User-agent 產品權杖的匹配不區分大小寫，因此 GPTBot、gptbot 與 GPTBOT 會解析到同一個群組。當多個群組指向同一個產品權杖時，它們的規則會合併。比對到的產品權杖群組優先於萬用字元群組，而萬用字元群組僅在沒有特定群組匹配時才適用。在適用的群組內，最長的匹配模式獲勝；當 Allow 與 Disallow 規則匹配長度相同時，根據 RFC 9309，Allow 獲勝。這種合併效果意味著單一行規則就可能改變報告中數十列的結果，這也是為什麼匹配引擎本身，是根據你關心的實際路徑進行測試時最關鍵的細節。
| 細節 | 行為 |
|---|---|
| User-agent 產品權杖比對 | 不區分大小寫 |
| 路徑比對 | 區分大小寫，從開頭開始評估 |
| 星號 (*) | 匹配任意字元序列 |
| 美元符號 ($) | 將模式錨定至路徑結尾 |
| 群組優先順序 | 特定產品權杖群組優先於萬用字元群組 |
| 等長匹配的決勝規則 | Allow 優先於 Disallow |
| 註解行 | 在解譯前移除 |
| 空白的 Disallow 值 | 不會阻擋任何內容 |
| 無匹配規則時的預設 | 回報為允許 |
檢查工具會強制執行有記載的總體匹配工作量上限，以避免冗長的對抗式路徑加上大量的規則集導致主執行緒卡住；在 500 KiB 位元組上限內的檔案，仍可能因這項安全檢查而被拒絕，連同任何包含超過 5,000 條非空存取規則的輸入也會被拒絕。不是 User-agent、Allow 或 Disallow 指令的行 —— 包括 Sitemap 與 Crawl-delay —— 不會影響存取判斷，即使這些行對特定爬蟲仍可能具有意義，但不在本報告的涵蓋範圍內。
檢查工具無法看見的細節：實際部署與行為
部署前的檢閱只能涵蓋書面上的檔案。發布後，請從完全相同的 scheme 與 host 擷取實際的 /robots.txt，確認回應為純文字且成功回傳，然後在可用的業者工具與伺服器記錄中驗證行為。檢查工具永遠不會擷取 URL，因此無法偵測重新導向、CDN 覆寫、僅針對特定用戶端提供的語法、不正確的主機範圍、快取延遲，或無法連線的檔案。它也無法確認目前部署的內容。這些限制使該工具能保持私密且具決定性，同時讓結果能輕鬆從相同輸入文字與路徑重現。將報告視為檔案的屬性而非網路的屬性，是讓其餘工作流程能夠整合在一起的關鍵細節。
在發布任何政策前，有一個獨立但更重要的細節值得注意：robots.txt 是自願性的。它不是身分驗證、授權、防火牆或合約強制執行系統，爬蟲可以忽略該檔案。公開列出某個路徑也可能將其洩漏。檢查工具僅回報在已實作的協定邏輯下，你貼上的規則是否對所選路徑要求阻擋；「允許」的結果並不證明業者會爬取、索引、引用、訓練或顯示該頁面，而「阻擋」的結果也不證明已強制執行或已從索引中移除。如需更清楚了解阻擋與實際爬蟲行為之間的關係，請參閱Robots.txt 阻擋是否真的能阻止 AI 爬蟲？。請以伺服器端的存取控制來保護機密或付費內容，並另外監控實際流量 —— 這才是能提供可強制執行保護的唯一層級。
若想深入了解，請參閱使用 HTML 頁面權重分析工具時的重要細節。