2026 年 7 月 1 日，Cloudflare 在官網發布新聞稿〈Cloudflare Allows the Agentic Internet to Flourish with a Simple Philosophy: Your Content, Your Rules〉，宣布 Cloudflare AI 爬蟲控制已拆成 Search、Agent、Training 三種用途，並預告 9 月 15 日調整預設與遷移舊設定；但更值得看的，是 8 月官方更新至少已改寫新客戶的 onboarding 流程。
原始故事很有力：搜尋可以進來，訓練與代理程式在含廣告頁面先被擋下，混合用途 crawler 也不能再用搜尋身分打包通行。然而，這不是一條已經穩定落地的單一路線。本文會先忠實還原 7 月方案，再把較新的 8 月公告與現行 API 欄位放在一起核對，最後回答網站經營者與 Agent 開發者真正該調整什麼。
7 月原案：Cloudflare AI 爬蟲拆成三種用途
Cloudflare 在同日技術文章中，將 bot 行為分成三類：
- Search：主動抓取並建立網站資料庫或索引，供之後回答查詢。
- Agent：在真人當下提出要求後，代替使用者讀取頁面或執行任務。
- Training：取得內容，用於模型訓練或微調。
同一篇文章還把「爬蟲做什麼」與「內容抓回去後怎麼用」分成兩條軸：immediate 代表互動但不保存重用，reference 代表索引、摘錄並連回原站，full 則可摘要與重現。Cloudflare 當時把 content-use 選項與 use 訊號寫成正在建置或測試的能力，不能當成已普遍可用的標準；但這個設計恰好證明，crawler 行為與下游用途本來就不是同一件事。
依 7 月公告，9 月 15 日起，新客戶與既有客戶新加入的網域，會在 Cloudflare 判定含有廣告的頁面允許 Search、封鎖 Training 與 Agent；未在期限前更改設定的既有 Free 客戶也被新聞稿列入自動調整範圍。這不是全站不可更改的禁令，網站管理者仍可在 dashboard 把每一類改成允許、只在廣告頁封鎖或全站封鎖。
“At any time these settings can be changed by customers in their dashboard.”
中文：「客戶隨時都能在 dashboard 更改這些設定。」
Cloudflare，2026 年 7 月 1 日原始新聞稿
“An ad is a signal that a website owner meant for a person to land there and see it.”
中文：「廣告是一個訊號，代表網站經營者原本希望真人到站並看見它。」
Cloudflare，〈Content Independence Day〉
這句話就是原案的商業假設：如果頁面靠廣告變現，繞過真人到站的自動讀取可能破壞交換關係。對同時被標成 Search 與 Training 的 crawler，7 月文件採最嚴格規則；只要 Training 被封鎖，共用身分的 Search 請求也可能一起被擋。
8 月更新：硬封鎖之外，多了一條 Disallow 路線
如果只讀 7 月新聞稿，很容易把 9 月 15 日理解成一次統一切換。但 Cloudflare 8 月 21 日發布的Bot Preference Sync 公告，提供了不同的新客戶 onboarding 路線：選擇「I monetize from pages with ads」的 publisher，會把 Training 預設設成 Disallow；非 publisher 的新客戶則不預先加入任何 block 或 disallow。該文的示意範例同時把 Search 與 Agent 設為 Allow。
“There’s no single right answer, which is exactly the point.”
中文：「沒有一個適用所有人的唯一正解，而這正是重點。」
Cloudflare，〈Bot Preference Sync〉
Disallow 與 Block 不是同義詞。前者會把訓練偏好同步到 robots.txt；願意配合且符合透明度要求的混合用途 crawler，可以承諾不把內容用於 Training，同時保留 Search 抓取，執行力依賴 crawler 遵守。RFC 9309 的 Disallow 本身只規範 URI 路徑的抓取偏好；「不訓練」語意來自 Cloudflare 產生的 bot 規則與業者承諾，不是 REP 建立的標準授權。後者才是在 Cloudflare 邊緣直接拒絕請求。現行 Bot Management API也同時列出 disallow、block 與 only_on_ad_pages，證明偏好聲明與網路層阻擋已成為兩種不同狀態。
Cloudflare 給 Search＋Training 混合 crawler 的透明度例外有四道門檻：遵守 robots 中的 no-training 偏好、讓網站退出 AI 摘要、提供 URL 級訓練可用性與搜尋結果指標，並公開證明關閉 Training 不會傷害傳統搜尋結果。這比只看 user agent 嚴格得多，但門檻、認證與撤銷仍由 Cloudflare 管理。
| 適用情境 | 7 月公布方案 | 8 月較新公告 |
|---|---|---|
| 新客戶 onboarding 網域 | 含廣告頁面允許 Search，封鎖 Agent、Training | 廣告型 publisher 可選 Training：Disallow；非 publisher 不預加 block 或 disallow |
| 既有客戶新增網域 | 比照新客戶的廣告頁預設 | 未在該公告交代 |
| 未調整設定的既有 Free zone | 新聞稿列入 9 月 15 日遷移範圍 | 未在該公告交代 |
| 混合 Search＋Training crawler | 硬封鎖時採最嚴格規則 | 若透明且承諾遵守用途限制，可保留 Search 存取 |
| 強制力 | Block 可在邊緣拒絕流量 | Disallow 主要依賴 crawler 自律 |
因此，本文不把 9 月 15 日寫成「所有 Cloudflare 網站已照 7 月方案全面切換」。本文在台北時間 2026 年 9 月 15 日 06:37 查核時，舊金山仍是 9 月 14 日 15:37，Cloudflare 也沒有在公告中指定生效時刻或時區；Block AI bots 文件仍以 will set 描述原定方案。這個未來式不證明 rollout 延誤，只表示查核時還不能證明它已完成。再加上 8 月公告另給出新客戶路線，最負責任的結論是：日期已宣布，但實際套用到哪一類帳戶、哪一個選項，必須以每個 zone 的 dashboard 與請求紀錄確認。
Cloudflare AI 爬蟲的真正難題：抓取後拿去做什麼
單看一個未驗證的 HTTP 請求，只能看見對方自我標示的身分；即使再用簽章、公開 IP 或 reverse DNS 提高身分可信度，也很難單靠封包證明內容抓回去後是拿去搜尋、生成摘要、即時回答，還是訓練。這也是 Cloudflare AI 爬蟲分類最重要、也最脆弱的地方：身分與用途並不是同一件事。
OpenAI以 OAI-SearchBot、GPTBot、ChatGPT-User 分開搜尋、訓練與使用者觸發的存取；Anthropic也分成 Claude-SearchBot、ClaudeBot 與 Claude-User。這讓網站可以表達不同選擇，但僅由 user agent 仍無法證明下游用途。
更麻煩的是，業界對真人觸發 Agent 是否遵守 robots 也沒有一致做法：OpenAI 文件說 ChatGPT-User 可能不一定受 robots 規則約束，Anthropic 表示三種 crawler 都會遵守，Perplexity則說 Perplexity-User 通常會忽略 robots。這些都是各公司對自身產品的公開聲明，不是獨立稽核結果，卻足以說明「Agent」尚未形成一套共同契約。
Google 走的是另一條路。Google-Extended不是獨立 HTTP user agent，而是控制 Google 如何使用既有 Google user-agent strings 抓取的內容，包括 Gemini 模型訓練與部分 Gemini、Vertex AI grounding；Google 又在 2026 年 8 月 31 日全球推出 Search generative AI control，可另外排除 AI Overviews、AI Mode 與 Discover 的生成式用途，而不影響其他搜尋收錄。這直接說明：Search 與 Training 的用途分離，不一定要求同一頁被兩個 crawler 重抓，重點是下游用途能否被驗證、遵守與稽核。
“These rules are not a form of access authorization.”
中文：「這些規則不是存取授權機制。」
RFC 9309：Robots Exclusion Protocol
這句 RFC 規範替整場爭論畫出邊界：robots.txt 是給合作 crawler 的偏好，不是門鎖。Cloudflare 的邊緣 Block 把善意請求變成可執行政策，確實比單寫一行 robots 規則更有力量；但官方功能文件描述的是進站請求的執法，沒有提供追回既有副本或自動約束內容離站後用途的機制。
AlphaLab 的判讀：這是治理層升級，不是內容主權的終點
一、Cloudflare 解決了「偏好沒有執行力」
這是最實質的進步。網站經營者不再只能期待 crawler 自律；對可辨識 bot，CDN 可以在 origin 之前直接阻擋，減少原站負載與設定範圍內的存取。Cloudflare AI 爬蟲控制也把 Search、Agent、Training 從模糊的「AI bot」拆開，提高透明業者申報身分與用途的誘因。
二、可信身分仍不等於可信意圖
簽章、固定 IP 或 reverse DNS 能提高「操作者身分」可信度；公開 user agent 只提供自我標示，單獨不能驗真。即使身分可信，也不會自動證明資料後來沒有流入另一個索引、摘要系統或訓練管線。真正可靠的用途隔離還需要產品控制、保存期限、稽核紀錄與違規後果。否則分類只是業者申報與 Cloudflare 判定的治理標籤。
三、允許 Search、封鎖 Agent，不必然比較「以人為本」
Cloudflare 將 Search 定義到供日後回答的網站資料庫與索引，這些系統可能直接在平台內生成答案；Agent 則可能是某位真人當下委託的研究、購物或無障礙助手。前者不保證帶回點擊，後者也不必然是無人濫抓。把廣告視為真人意圖的代理訊號有商業道理，但訂閱站、公益文件、第一方贊助與人類委託 Agent 都可能落在這個簡化模型之外。
四、控制權增加，同時也集中到新的 gatekeeper
Cloudflare 同時負責分類 bot、辨識身分、偵測廣告頁、執行封鎖、量測流量，並發展內容付費基礎設施。這不代表它的政策有不當之處，卻表示一家公司正在替大量網站定義「什麼算 Search、Agent、Training」。所謂 your rules，仍建立在 Cloudflare 提供的選項與辨識能力之上。
五、8 月新增的例外，比一刀切更精確
7 月方案以最嚴格規則處理共用 Search＋Training 身分，藉此施壓 mixed-use crawler 提供更清楚的用途分流；8 月則增加一條接受可驗證 downstream control 的路線，讓符合條件的 Search＋Training 業者未必需要為兩種用途重複下載同一份內容。這個修正比只看 crawler 名稱更精確，也更接近真正問題。
英國競爭與市場管理局（CMA）2026 年 1 月 28 日的 Google-specific 暫定分析也提出相同反方：強制把用途拆成不同 crawler 可能造成重複抓取，增加網站負載與能源成本；改善 downstream-use controls 可能以較低成本達到目的。部分成本輸入來自 Google，CMA 的估算也屬示意，因此這不是可外推全網的實測結果；它只能作為不要求 crawler 物理分家的政策反例。
我同意的部分：網站應能分別決定搜尋曝光、模型訓練與人類委託 Agent 的存取；可調整預設與邊緣封鎖，也確實替出版者增加談判籌碼。
我仍存疑的部分：Cloudflare 已提供 crawler 與部分 referral 的觀測工具；但截至 2026 年 9 月 15 日本文查到的官方材料，尚未公布廣告偵測的 precision／recall，或用途遵循的獨立稽核結果。至於新預設對 referral、出版者收入與市場公平的影響，查核時尚未進入 Cloudflare 所在地的 9 月 15 日，本來就只能列為上線後的觀察指標，不能先下結論。Cloudflare 把 robots.txt 的善意請求推進成可執行政策，是重要一步；但它帶來的是槓桿，不是完整的內容主權。
網站經營者與 Agent 開發者現在該做什麼？
網站經營者：先稽核，再選政策
- 逐 zone 檢查：不要只看新聞稿；核對 Cloudflare dashboard、Bot Preference Sync 產生的
robots.txt、WAF 優先順序與實際請求紀錄。 - 按內容決策：首頁、公開文件、商品頁、廣告內容與付費牆不必採同一政策。先寫清楚你要的是曝光、引用、真人到站、授權收入，還是降低抓取成本。
- 分開檢查 mixed-use 控制：Googlebot 等共用 crawler 不能只看 user agent；還要確認 Google-Extended、Search generative AI control 等下游用途設定。
- 機密與付費內容用真正授權：登入、token、paywall 與 origin access control 才是門鎖，
robots.txt不是。若想理解「付費一次存取」與「後續使用權」為何不同，可延伸看 x402 與 Cloudflare Agent 付款完整拆解。
Crawler 與 Agent 團隊：把用途做成可驗證契約
- 公開可辨識身分：為 Search、Training、真人觸發存取提供明確名稱、文件、IP／reverse DNS 或簽章驗證方式。
- 讓用途能被稽核：即使 Search 與 Training 共用一次抓取，也要把下游資料流、保存期限、訓練開關與刪除流程分開記錄。
- 尊重多層訊號：同時處理 robots、rate limit、Cloudflare 自建的 Content Signals、登入與付費牆；不得把第三方 fetcher 當成繞過拒絕的後門。
- 保留來源價值：Agent 回答應顯示來源與可點連結，並支援 ETag、If-Modified-Since 等機制降低重複抓取。若還不熟悉 Agent 如何代替真人讀取與行動，可先讀 AI Agent Harness 是什麼。
接著閱讀
左右滑動查看更多推薦
最值得立刻做的不是按下「全部封鎖」，而是截下目前三個選項與方案可查看的 bot 流量快照，之後用相同觀測窗口比較搜尋收錄、AI 引用、真人流量與伺服器成本。政策名稱會再變，但「誰來、為何來、抓走後做什麼、違規如何處理」這四個問題，才是長期不變的控制面。