當貼上的檔案依照 RFC 9309 進行解析、您輸入的路徑與真實爬蟲所請求的完全一致，且每一個 32 個 product-token 的結果在部署前都與該操作方的最新說明文件交叉核對時，AI 機器人 robots.txt 檢查才算正確。AI Bot Robots.txt Checker 完全在瀏覽器中套用該協定的比對邏輯，因此結果可以重現，且不依賴即時擷取。這使得「正確性」取決於三件事：您貼上的內容、您測試的路徑，以及您之後如何處理這份報告。乾淨的執行本身並非即時行為的證明，但它是不碰正式環境所能取得最強烈的發布前信號。下列步驟會將貼上並點擊檢視的流程，轉化為一個小型且可重複的稽核：貼上與正式環境完全一致的文字、輸入能反映真實爬蟲請求的路徑、依據 RFC 9309 的同分決勝規則逐條檢視每筆比對結果、以操作方自身的說明文件驗證任何關鍵的 token，並在部署後確認即時回應。
在針對 AI 爬蟲進行 robots.txt 檢視時，大多數錯誤來自於誤讀協定的同分決勝規則、將路徑視為不區分大小寫、混淆萬用字元群組與特定 product-token 群組，或假設那 32 個列出的 token 就是字面上的 User-Agent 標頭字串。本文將逐步說明檢查工具實際套用的比對邏輯、會改變結果的輸入項目，以及將貼上並點擊檢視轉化為可靠的部署前稽核所需的驗證步驟。
為何 AI 機器人 robots.txt 檢查的正確性比經典爬蟲更難
經典的 robots.txt 檢視通常只關注單一 user agent，例如 Googlebot。AI 時代的 robots.txt 檢視如今橫跨一組混合的檢索爬蟲、助理檢索產品，以及專屬的訓練控制 token，這些皆受相同的 RFC 9309 比對規則規範，但各自擁有不同操作方的政策。一個對某個產品行為可預測的檔案，若缺少單一 product-token 群組，或被萬用字元群組意外覆寫，就可能對另一個產品表現得無法預測。
正確的檢查之所以更困難，也因為 robots.txt 本身是自願性質。報告中的「blocked」列僅代表貼上的規則在所實作的協定邏輯下要求阻擋，並不能證明強制執行、從索引中移除，或是 AI 公司會尊重該要求。「allowed」列僅代表該檔案未對該產品在該 URL 路徑上要求阻擋。請將此檢查工具視為對規則的部署前檢視，而非對操作方實際作為的保證。
RFC 9309 檢查工具實際套用的比對規則
RFC 9309 將機器人排除協定標準化。檢查工具會嚴格遵循這些規則，因此理解它們是正確解讀報告的最快途徑。最常改變 AI 機器人 robots.txt 結果的規則包括：
- User-agent product token 的比對不區分大小寫。寫成 GPTBot 或 gptbot 會指向同一個群組。
- 比對到的 product-token 群組優先於萬用字元群組。當沒有特定群組比對成功時，才會套用萬用字元群組。
- Allow 與 Disallow 樣式會從路徑的開頭開始比對。路徑的比對區分大小寫，因此 /Private 與 /private 可能產生不同結果。
- 最特定的比對樣式優先獲勝。特定性以比對樣式的長度來衡量，其中 * 可比對任意字元序列，而結尾的 $ 會將樣式錨定至路徑末端。
- 當同樣特定的 Allow 與 Disallow 規則同時比對成功時，Allow 獲勝。這就是為什麼一個較長的 Allow 能夠在某個長度相同的 Disallow 原本會阻擋的路徑上予以放行。
- 空白的 Disallow 值不會阻擋任何內容。沒有路徑的 Disallow 會被視為「無規則」，而非「阻擋一切」。
- 若沒有適用的 Allow 或 Disallow 規則比對成功，存取結果會回報為允許。預設為允許，而非阻擋。
- 註解會在規則解譯前被移除。以 # 開頭的行不會影響結果。
這些規則並非僅供參考。它們就是檢查工具所實作的內容，若您的預期與之有任何出入，表現出來的「錯誤」結果，實際上是符合協定的結果。
如何正確檢查 AI 機器人 robots.txt
執行正確的檢查意味著提供工具乾淨的輸入，並依據操作方公布的行為逐一檢視每筆比對結果。請依序執行下列步驟。
- 貼上您想檢視的 robots.txt 完整文字。請原封不動地複製正式環境的檔案。檢查工具接受最多 500 KiB 的 UTF-8 輸入以及 5,000 條非空白的存取規則；即使在該位元組大小範圍內的輸入，仍可能因為總體工作量安全上限而被拒絕，因此請貼上檔案最小且忠於原貌的版本。
- 輸入一個以斜線開頭、區分大小寫的 URL 路徑。請使用能反映真實爬蟲請求內容的路徑，包括該請求中包含的任何查詢字串。由於路徑從開頭開始比對，因此當規則使用錨定或結尾 $ 時，/blog 與 /blog/ 可能會產生不同的結果。
- 執行檢查。檢查工具會將檔案解析為 user-agent 群組、合併不區分大小寫的重複 product-token 群組、僅在沒有特定群組比對成功時才退回到 User-agent: *，接著評估路徑對每一個 32 個 product token 的結果。
- 在信任該列結果之前，逐條檢視每筆比對規則。針對每個 product token，請確認所套用的 user-agent 群組、最長比對到的 Allow 與 Disallow 樣式，以及哪一條規則獲勝。即使已有特定群組比對成功，也不要略過萬用字元群組的行為檢視。
- 依據操作方最新說明文件驗證關鍵的 product token。爬蟲產品會隨時間變動。請將任何控管高風險路徑的列視為尚未確認，直到它在操作方自身的參考資料中出現為止。OpenAI 與 Anthropic 皆發布第一方說明文件；Cloudflare 維護了許多操作方的交叉對照，而來自補充型目錄的 token 則會在報告中相應標示。
- 為每一個重要路徑重複檢查。請執行第二個理應被允許的路徑、第三個理應被阻擋的路徑，以及第四個針對已知邊緣情況的路徑，例如結尾斜線的標準化、查詢字串，或深層巢狀的私密區域。
- 與正式部署實際提供的內容進行比對。發布後，請從完全相同的 scheme 與主機擷取 /robots.txt，確認回應為純文字 200，並對該回應主體重新執行相同的檢查。
這個流程讓結果具有決定性。兩位審閱者只要貼上相同的文字並輸入相同的路徑，就會在每一個欄位看到相同的列，這就是您能取得最便宜的正當性信號。
依據操作方說明文件驗證結果
報告中的 32 列是 robots.txt 的 product token，而非保證每個字串都會原樣作為 HTTP User-Agent 標頭出現。有些操作方會公布專屬的控制 token，例如 Google-Extended 或 Applebot-Extended，專門用於模型訓練或資料使用偏好；其他列則代表檢索產品。將專屬的訓練控制 token 視為與檢索 token 相同，是 AI 機器人 robots.txt 檢視最常出錯的方式之一。
請使用表格中的操作方、目的類別與來源狀態，來決定該列「正確」對您而言代表什麼。針對 OpenAI 產品，主要的操作方說明文件應能釐清任何疑義。Anthropic 直接公布其網路爬蟲控制方式。針對跨操作方的問題，Cloudflare 的 AI 爬蟲參考資料以及其代管的 robots.txt 說明文件都是有用的起點；任何源自目錄來源而非操作方第一方說明文件的列，都會在報告中標示出來，以便您規劃後續的核對。
在信任報告之前的部署前檢查清單
在將檔案上線之前，請逐一檢視下表並確認每個項目。請將任何未確認的項目視為該特定列的阻斷因素，而非整個檔案的阻斷因素。
| 項目 | 需確認內容 | 在報告中的呈現位置 |
|---|---|---|
| 正式環境文字與貼上文字一致 | 沒有尾端空白、沒有編輯器自動加入的註解、沒有複製貼上造成的換行變動 | 來源端：您貼上的完整檔案 |
| 每個關鍵 token 都存在對應的特定群組 | 有比對到的 product-token 群組，而非僅有 User-agent: * | User-agent 欄位 |
| 萬用字元群組的退回行為是有意為之 | 您清楚哪些列會退回至 *，以及哪些列是您忘了涵蓋 | 來源狀態欄位 |
| 路徑輸入與爬蟲實際請求的完全一致 | 區分大小寫的路徑，包含任何查詢字串，且以 / 開頭 | 結果欄位僅適用於此路徑 |
| 已套用最長比對與 Allow 獲勝的同分決勝規則 | 報告中顯示的獲勝規則為最長比對，且在長度相同時 Allow 獲勝 | 每一列的比對規則細節 |
| 已依操作方文件驗證關鍵 token | 高風險 token 已與操作方當前頁面交叉核對，而非僅參考第三方摘要 | 來源狀態欄位 |
| Sitemap 與 Crawl-delay 行另作註記 | 這些行不會影響存取判定，且未與 Allow 或 Disallow 混淆 | 不會出現在報告中；請於來源端確認 |
檢查工具無法告訴您的事
此檢查工具僅分析貼上的文字與輸入的路徑。它不會擷取您的即時網站，因此無法偵測部署問題、重新導向、CDN 覆寫、僅對特定用戶端提供的語法、不正確的主機範圍、快取延遲，或是無法連線的檔案。它同樣無法確認您伺服器上目前部署的內容。這些限制讓此工具得以保持私密且具決定性，但也代表一份乾淨的報告本身並非即時行為的證明。
robots.txt 並非身分驗證、授權、防火牆，也無法證明內容不會進入 AI 模型。爬蟲可能會忽略該檔案，而公開列出某個路徑反而會暴露它。針對機密或付費內容，請使用伺服器端的存取控制並另行監控實際流量。搜尋索引、建立摘要的控制、訓練偏好，以及即時網路封鎖，都是獨立於本報告之外的機制。
報告之後：確認實際部署
報告看起來正確後，下一步是確認實際提供的是什麼內容。從爬蟲會看到的相同通訊協定和主機擷取 /robots.txt，確認回應為純文字且成功返回，然後使用實際回應再次透過檢查工具執行相同的路徑。這能抓出已暫存但從未部署的編輯、建構管線重新編寫時變更的換行字元，以及 CDN 邊緣覆寫。如需針對每列與操作方文件對照閱讀的結構化逐步指引，請參閱驗證逐步說明。
如果報告中的某一行看起來有誤，最常見的原因有三種：路徑輸入的大小寫或結尾斜線與規則預期不符、缺少特定的產品權杖群組而導致靜默套用萬用字元群組，或操作方自上次更新報告的來源清單後已更新其權杖。請重新貼上檔案、重新測試路徑，並在變更正式環境規則之前，重新檢查操作方目前的文件。
正確的 AI 機器人 robots.txt 檢查並非單純的貼上並點擊。它是一個小型稽核：貼上正式環境的文字、測試重要的路徑、閱讀符合的規則、根據操作方自身的頁面驗證權杖，並確認實際部署與您審閱的內容一致。這個流程才能讓 AI 機器人 Robots.txt 檢查工具中的 32 個產品權杖作為部署前審查而非猜測而發揮作用。如需更廣泛的跨操作方脈絡，了解阻擋與各操作方政策如何互動，Cloudflare AI 爬蟲參考資料是與操作方自身文件搭配的實用交叉參照。
如果您正在權衡選項，llms.txt 是否取代 robots.txt 或 sitemap.xml？說明對此進行了詳細說明。