機器人營運者長期面對一個困境：提交自己的爬蟲或代理程式給網站主審核後，就像把資料丟進黑洞。沒有狀態查詢、沒有拒絕原因、沒有編輯入口，只能寫信給支援團隊追問。Cloudflare 在 2026 年 8 月 28 日推出的 BotBase for Operators，正是針對這個斷層設計。
從黑箱到透明：提交歷史與狀態
過去，BotBase 的提交表單藏在「Manage Account → Configurations」底下，與機器人生態系毫無連結。現在，它搬到「Protect & Connect → Application Security → BotBase」，與其他信任工具並列。
新的 Submission history 分頁列出帳號下所有提交，每個項目都有明確狀態：Waiting for review、Accepted、Rejected。被拒絕的提交會附上具體原因與可執行的修正步驟，而不是一句籠統的「不符合規範」。營運者也能看到 Cloudflare 是否調整了機器人的分類方式。
Cloudflare 團隊在部落格中寫道，過去營運者必須寫信給支援團隊才能知道審核進度，現在這個缺口被補上了。
編輯與取消：讓資訊保持最新
機器人的識別細節會隨時間改變。例如，網站改版後 IP 清單可能移到新的端點，或者從 IP 允許清單改用 Web Bot Auth 簽章。以前遇到這種情況，只能重新填寫整份表單、建立全新條目。現在可以直接編輯已提交的內容，也能取消仍在等待審核的提交。
Cloudflare 強調，準確的資訊是機器人獲得並維持 Verified 狀態的關鍵。Verified 狀態會影響網站主是否願意根據行為放行流量，但最終決定權仍在個別網站主手上。
新的分類法：行為、內容使用、營運者
新的提交表單不再要求營運者把機器人塞進單一標籤，而是描述三個面向。
第一，機器人做什麼。可以複選，例如建立搜尋索引、代表使用者執行動作、收集資料、訓練模型、支援 SEO 工具等。
第二，如何使用讀取的內容。這與網站主在 robots.txt 中設定的 Content-Signal 模型對齊。例如，網站主可以宣告 Content-Signal: search=yes, ai-train=no, use=reference，表示允許搜尋索引與參考用途，但禁止用於模型訓練。機器人的內容使用宣告會與這類偏好進行比對。
第三，誰在營運。直接營運（direct）指營運者從自己的基礎設施發送流量，例如搜尋引擎建立自己的索引。中介（intermediary）則是指平台承載其他公司的流量，但並非發送請求的決策者。例如，通用 AI 助理的營運者提供基礎設施，但實際觸發請求的是另一個建構在 API 上的產品。
自動化審核：從人工瓶頸到可擴充流程
Cloudflare 指出，新提交的機器人數量自 2023 年以來成長約七倍，人工審核無法跟上。新的流程會自動執行一系列檢查：是否與現有條目重複、使用者代理字串是否足夠精確、驗證方法是否真的有效。系統會自動抓取 IP 清單、確認反向 DNS、驗證 Web Bot Auth 簽章。
通過檢查的提交可以立即被追蹤；需要人工介入的案例會被標記具體原因後轉給團隊，而不是以空白佇列的形式等待。對營運者來說，這代表多數提交的處理速度比以往更快。
下一步：從可見性到對話
Cloudflare 將這次發布定位為可見性（visibility）的起點。接下來的目標是所有權與可觀測性（ownership and observability），讓營運者能認領機器人、管理線上目錄條目、了解網站如何對待自己的流量。更長期的目標是對話（conversation），讓機器人營運者能在證明價值的基礎上，向網站主請求放行。
這個方向把單向提交轉變為持續的關係。對產品建構者而言，BotBase for Operators 示範了一個實用的模式：把審核流程從黑箱變成可追蹤的狀態機，並用結構化分類取代模糊標籤。如果你的產品涉及爬蟲、代理程式或自動化流量，值得參考這種做法來降低與外部生態系的摩擦。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。