Cloudflare 在 2026 年 7 月 1 日的 Content Independence Day 第二屆公告裡，把「AI 流量要不要擋」這件事重寫了一遍。重點不是「Cloudflare 要預設封鎖 AI」，而是它把過去那種二元判斷拆成三個獨立開關：Search、Agent、Training。
真正會影響多數站長的是 9 月 15 日的新預設值，但這個預設附了五個但書，任何一個被略過都會得到錯誤結論。五個但書裡最容易被傳錯的是多用途爬蟲連帶被擋那一條，而三分類真正給站長的，是一個過去沒有的中間開關。下面會把每個判斷條件、dashboard 實際點擊路徑、方案差異與退出機制都拆開講。
依 Cloudflare 在 Content Independence Day 公告裡的說法，今年命題跟去年明顯不同。去年（2025 年 7 月 1 日第一屆）推的是一鍵 Block AI Bots 跟 Pay-Per-Crawl 市集，那是粗工具；今年換成三分類，背後的判斷是「全部封鎖不是唯一解」。
TL;DR
新選項 Search／Agent／Training 三類獨立設定，Free 方案也通。
9/15 新預設只動新上架網域、只動廣告頁、只擋 Training＋Agent、Search 照放；擋 Training 時，多用途爬蟲（含 Googlebot）會連帶被封鎖。
content-use 訊號新欄位
use=reference，是「想被 AI 引用又要保護原創」的甜區。robots.txt 的
use=是偏好，不是強制；真正能擋的是 Cloudflare 設定本身。擋 AI 之前先問自己：我能不能承受搜尋索引受影響。
文章目錄
先校正一個觀念：這次不是「Cloudflare 要擋 AI」
很多轉發標題把這次公告總結成「Cloudflare 9/15 起預設封鎖 AI 爬蟲」。這個講法太省事，省到把最重要的條件全弄丟。Cloudflare 自己的命題剛好相反：站長要的是更細的控制，全擋或全放都只是兩個極端。
說穿了就一件事：問題從「這個 bot 是不是 AI」改成「它在站上做什麼、儲存了什麼、會怎麼重新分享我的內容」。後面所有新選項、新預設、新訊號，都是從這個分類法長出來的。它是更細的開關箱，不是更大的牆。
對中小站點的站長來說，這個視角的切換比任何單一功能都重要。多數人面對的不是「OpenAI 來偷我東西」這種二選一，而是「我想被 AI 搜尋 引用、但我也不想被永久吸收去訓練」。Cloudflare 這次想解的，就是這個「中間地帶沒有工具」的問題。
也順便校正一個常見的混淆：Cloudflare 在公告裡反覆強調，bot 業者應該「拆分爬蟲」。意思是 OpenAI、Google、Anthropic 這類公司應該讓「搜尋用 bot」跟「訓練用 bot」分開，各自獨立 User-Agent、獨立行為，讓站長看清楚單一爬蟲是為何而來。這是 Cloudflare 對 bot 業者的公開要求，站長這邊能做的，是在新分類法出現之後，開始用「它在做什麼」的視角檢查自己站上的 bot 流量，而不再死守「是不是 AI」這個已經失效的分類軸。
為什麼舊的 Block AI Bots 不夠用
回到 2025 年 7 月 1 日，第一屆 Content Independence Day 的命題是：過去三十年那套「我爬你內容、給你轉介流量」的非正式默契已經被打破。AI 拿走內容，不回送流量，對靠內容吃飯的站長來說是生存問題。當時 Cloudflare 給的工具是一鍵 Block AI Bots 跟 Pay-Per-Crawl 市集。
但一年下來，Cloudflare 發現多數站長的需求並不是「全部封鎖」。原因很現實：小站的真實兩難是「根本沒人找得到你」。要嘛出現在搜尋結果並接受被 AI 訓練，要嘛承擔失去能見度的風險。
這個兩難是結構性的，升級工具並不能解決。一個新站如果選擇封鎖所有 AI 爬蟲，等於把自己排除在 AI 搜尋 能見度之外，未來流量版圖往 AI 搜尋傾斜時，這個站就缺席了。反過來說，如果選擇全放，原創內容被吸收去訓練，等於在補貼競爭對手的模型能力。Cloudflare 在公告裡直白講：這個不對稱結構不公平地保護既有搜尋業者，同時激勵新進者用閃避手段追趕。這是這次轉向分類法的根本動機。
更麻煩的是同一個 bot 經常同時用於搜尋與訓練。如果只有「擋 vs 放」二選一，等於逼站長在「要搜尋能見度」跟「不要被吸收訓練」之間選邊站，而這兩件事不該被綁在一起決定。
換句話說，舊 Block AI Bots 只擋「為訓練而爬的單一用途 bot」。但今天的爬蟲世界早就不是那種涇渭分明的局面，這也是為什麼 Cloudflare 強烈呼籲 bot 業者主動拆分爬蟲，讓站長看清楚單一爬蟲到底是為何而來。
Search、Agent、Training 三分類實戰判斷
Cloudflare 提出的「務實分類法（pragmatic taxonomy）」聚焦三個站長都該能管理的情境：
- Search（搜尋）：爬蟲索引你的內容，之後用它回答查詢。主動建立你站台的資料庫，以便回應使用者。站長應該期待獲得轉介流量或其他合理補償。
- Agent（代理）：代替某個人去完成某件事，通常即時。包含 chat fetch bot（例如 ChatGPT-User）與 browser-use agent（例如 Gemini 或 Claude 驅動 Chrome）。另一頭通常有人在等結果。
- Training（訓練）：內容被永久吸收進模型的底層架構以提升能力。
這三類很多時候會重疊，同一個 bot 可能落在兩類以上。Cloudflare 的態度是呼籲業者拆分爬蟲，而不是讓站長面對一個「我不知道它實際在幹嘛」的黑盒子。
把這三類放進站長決策，會得到這樣的判斷表：
| 類別 | 站長應該換到的東西 | 適合放行的情境 | 適合封鎖的情境 |
|---|---|---|---|
| Search | 搜尋結果能見度、轉介流量 | 靠搜尋流量變現（多數內容站、媒體、電商） | 你完全不要被搜尋索引（極罕見） |
| Agent | 使用者導向任務完成的流量（AI 代理點你站） | 經營 AI 助理、有即時互動價值的服務頁 | 頁面被 agent 拖垮體驗或吃頻寬 |
| Training | 目前幾乎無流量回報 | 你是 AI 訓練資料貢獻者、有授權收入 | 你原創內容是核心資產、無補償 |
對積極做 AEO 的站台來說，這個分類的真正價值是：你第一次可以把「會回送流量的索引」跟「永久吸收的訓練」分開對待。在這個分類出來之前，這兩件事被綁在同一個 bot 上，你只能二選一。
以我自己在操作的站台為例，我們刻意不擋 AI 爬蟲，還在 Cloudflare 邊緣架了一個 Worker 記錄 GPTBot、OAI-SearchBot、ClaudeBot、PerplexityBot、Google-Extended、CCBot 這些 bot 誰來抓、抓多少。原因不是大方，是因為 AEO 對我們是主要任務。但在這次公告之前，我們的選項其實很有限：要嘛全放，要嘛全擋，沒有「我想被引用、但不想被永久吸收」的中間開關。
這個中間開關，就是這次三分類對 AEO 從業者的核心意義。
三分類對不同類型站點的實際影響
三分類講起來很清楚，但放進實際站點類型會長出很不一樣的設定。下面是四種常見站點的預設判斷方向，不是鐵律，是分岔點。
內容站與媒體：原創內容是核心資產，又靠搜尋與社群流量吃飯。Search 放行沒得討論，因為沒有 Google 自然搜尋等於斷炊。Training 多數會糾結，但冷靜算一下：承前述，擋 Training 會連帶封鎖 Googlebot，代價是搜尋索引受影響，收益是「內容沒被吸收去訓練」，但你的內容還是會被別的管道（RSS 聚合、社群轉載、引用）拿到，這個收益其實很有限。Agent 視互動價值決定。純內容站的預設應該往「幾乎全放」傾斜，再用 content-use 訊號設 reference 表達意願。
電商：商品頁要被搜尋索引、要被比價爬蟲看到、要被 AI 推薦引擎收錄。Search 一定放。Training 對電商的焦慮低很多，因為商品資訊本身是「要被散布」的內容，不是獨家原創。Agent 反而是新機會：未來越來越多消費者透過 AI 購物助理比價、下單，Agent 對電商等於潛在流量。電商站對三分類的預設判斷通常是「全放，加 use=reference」。
SaaS 與工具站：服務頁要被 AI 助理推薦，Agent 等於轉換入口。但 SaaS 同時有文件站、定價頁、產品規格頁，這些頁面有些適合被引用、有些是競品情報來源。SaaS 需要三分類加上路徑級別的規則才有意義，例如文件站全放、定價頁允許 Search 但封鎖 Data Collection。後面這種細粒度控制要靠 Bot Management 規則，不是單純三分類能搞定的。
品牌與企業形象站：流量來源通常來自直接拜訪、社群與公關，搜尋佔比相對低。對這類站點，AI 流量管理的重要性反而低，因為能見度本來就不是核心 KPI。預設維持原狀即可，多數不需要動 9/15 新預設。
從這個切面看，Cloudflare 的三分類對「靠搜尋與 AI 引用吃飯」的站點（內容站、電商、SaaS）影響最大，對「靠品牌直接進站」的站點影響有限。判斷自己屬於哪一邊，是動不動這套設定之前該先想清楚的事。
9/15 新預設的五條件，多數轉發都會傳錯
Cloudflare 在公告裡宣布，2026 年 9 月 15 日起要調新預設。這是整篇公告裡最容易被錯誤轉發的一段，因為它的條件有五個，少講任何一個都會誤導：
- 適用範圍只限新上架網域。原文是 “for all new domains onboarding to Cloudflare”，意思是以 9/15 為基準、新加入 Cloudflare 的網域。你既有的網域不會自動被改。
- 只在「顯示廣告的頁面」生效，不是整個站台。
- 只封鎖 Training 與 Agent，Search 預設照放。
- Search 預設允許。多數站長希望被搜尋索引，這個預設符合其利益。
- 多用途爬蟲取最嚴格規則。如果一個 bot 同時用於 Search 與 Training，會依其「所有」行為決定允許或封鎖，依最嚴格規則強制。
第五點是最容易被忽略、也是衝擊最大的一點，要完整講一次。Cloudflare 在公告裡直接點名：Googlebot、Applebot、BingBot 這類多用途爬蟲，會被選擇封鎖 Training 的客戶擋下，無論是透過新選項或舊的 Block AI Bots。原因是這些 bot 在 Cloudflare 的分類裡同時掛 Search 與 Training，分類法面對這種跨類爬蟲的處理規則是取最嚴格那一條，所以你只要封鎖 Training，它們就連帶被封鎖，沒有半開半關的選項。這是分類法面對現實爬蟲世界的必然結果。
很多站長看到「擋 Training」會直覺覺得「那我就擋」，但他們沒意識到，因為 Googlebot 跨 Search 與 Training 兩類，擋 Training 等於連 Google 搜尋索引也一起擋掉。
Cloudflare 選擇這個預設的邏輯也講一下：廣告是「站長本意要讓真人到站看到、可變現、支撐事業」的訊號。在那些放廣告的頁面，站長想要的是人類注意力，所以預設擋掉可能搶走注意力的 Training 跟 Agent。Search 維持放行，因為搜尋是最自然能把訪客導回來的行為。這個邏輯本身合理，但它建立在「廣告頁＝站長要變現的頁面」這個假設上，對某些站不一定成立（例如品牌廣告只是曝光、不靠點擊變現的頁面）。
至於 Cloudflare 怎麼認定哪些頁面算「顯示廣告的頁面」，公告並沒有給出技術定義。合理的判斷是：頁面若有投放 Google AdSense 等廣告聯播網、或主動插入廣告單元，實務上就視為廣告頁；CF 內部確切怎麼判定（是否看特定 ad tag、是否需要站長人為標記）並未公開。不要把這個判斷寫死成「CF 官方確認的規則」，目前這是一個公開資訊缺口。
站長要問的問題不是「要不要擋 AI」，而是「我能不能承受搜尋索引受影響」。如果你的站台靠 Google 自然搜尋吃飯，盲目打開封鎖 Training 的開關，可能會先把自己最穩定的流量來源打斷。這是整個決策框架的核心。
Cloudflare 也給了退出機制：9/15 之前，站長可以在 Security settings 標記「對同時用於 Search 的 Training 爬蟲不做變更」。Cloudflare 會在接近 9/15 持續通知。新預設不是黑箱，但你不動，它就會動你。
content-use 訊號：為什麼 reference 是 AEO 的甜區
三分類之外，這次公告對 AEO 從業者也補了第二個工具：content-use 訊號。Bot Management 客戶可以依「內容使用」的程度選擇或封鎖，三個等級由嚴到寬：
- immediate：互動，但不儲存、不重用任何內容
- reference（預設）：索引、摘錄並連回原站
- full：摘要並重現
reference 是那個甜區。它對應的行為是 AI 索引你、可以摘錄你、但必須連回原站。對一個積極做 AEO、希望被 AI 搜尋引用的站台，這個等級比「全放」（等於 full，內容被自由重現）或「全擋」（等於 immediate 或更嚴，連引用機會都沒有）都更合理。
要先把誠實界線講清楚：這個甜區判斷是站在「想被 AI 引用」的站長角度，目前還沒有 AI 搜尋業者公開的資料證實 reference 等級實際換到的引用頻率。它是邏輯上合理的偏好聲明，不是已經被第三方資料驗證過的贏家公式。
在 robots.txt 上的對應寫法是新的 use 欄位。Cloudflare managed robots.txt 從原本：
User-agent: *
Content-Signal: search=yes,ai-train=no
Allow: /加上 content-use 後變成：
User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /如果你要自己寫，欄位名是小寫 use，值是 immediate／reference／full。已啟用 managed robots.txt 的客戶，現在會自動加上 use=reference。
content-use 可以跟分類組合出更細的規則。例如「允許所有 Search／SEO／Ads Verification 的 bot，但只到 reference 使用等級」。這個組合是給那種「我歡迎搜尋類 bot 索引我，但我不希望你把內容整段重現」的站長用的，對內容站特別實用。
但這裡有個誠實界線要講清楚。robots.txt 的 use= 跟其他欄位一樣，表達的是站長的偏好，不是直接封鎖。它靠 bot 業者配合。Cloudflare 自己有配套：BotBase 開始為每個 bot 追蹤 content use，發現 bot 濫用這些訊號會喪失 Verified 身分；目前「會完整重現的 bot 無法取得 Verified」。這是嚇阻力，不是絕對保證。
老實說，看到 use=reference 時，最該問的問題是：「我設了這個就安全了嗎？」答案：你表達了意願，Cloudflare 用 Verified 機制去約束業者，但 bot 要不要照辦，最終還是 bot 的事。真正能強制執行的，是你在 Cloudflare 設定面板上對特定 bot 的封鎖，而不是 robots.txt 那行字。
content-use 訊號是「公開聲明我的底線」。它跟「裝了就鎖住的保險箱」是兩回事。
Verified 定義變了：以前放行，現在只是「有資格被放行」
「Verified bot」這個詞的意義也悄悄變了。過去的規則是所有 Verified bot 預設允許，這反映在 Bot Fight Mode 與企業規則範本裡。新定義是：未驗證 bot 仍然預設封鎖，但 Verified 不再等於預設允許。
新的意思是：Verified 標籤代表「可在其相關類別中被允許」。實際會不會被允許，由你設定的「被允許的類別」決定（例如你允許 Search，那 Verified 的 Search bot 才會進來）。Verified 從「通行證」降級成「資格考通過」。
配套措施有兩個。第一，Cloudflare 開放並透明化「成為 Verified」的流程。業者得如實表明身份，且不濫用這分信任換來的存取。第二，濫用訊號會失 Verified，會完整重現的 bot 不能 Verified。這跟 content-use 訊號的嚇阻力綁在一起。
失去 Verified 身分在 Cloudflare 背後波及的範圍相當大。依 Cloudflare 在 Content Independence Day 公告 裡的數字，這個身分失效會波及 Cloudflare 背後超過 20% 的網域，這是 Cloudflare 給的嚇阻力，但不是絕對保證。
對企業客戶來說，這次還多了一個 BotBase。BotBase 是 Enterprise Bot Management 的新功能，Cloudflare 追蹤所有已知 bot（含 Verified bot 與 agent）的資料庫，在 dashboard 提供完整、可搜尋的檢視。企業客戶可看到所有 Verified bot／agent 完整目錄及其在新分類法中的歸類，可篩選特定 bot 流量、複製 detection ID 用於 Security rules。入口在 Bot Management configuration card。現已上線。
注意方案別：BotBase 是 Enterprise Bot Management 功能，多數中小站點在 Free／Pro，用不到 BotBase。但三分類新選項跟 9/15 預設對所有方案（含 Free）都生效。如果你是中小站長，影響你的是後者，不是前者。
BotBase 現階段先做可見度（visibility first），今年稍晚會擴充成已知自動化內容的直接控制中心。它是「先看清楚，再控制」的兩步走。
在 Cloudflare dashboard 實際怎麼點
講了這麼多設定邏輯，實際進 Cloudflare 後台該從哪裡點，是另一件事。路徑依 2026 年 7 月官方文件與公告整理，Cloudflare 介面會改版，確切的按鈕標籤與分頁順序可能調整，但入口都在 Security → Bots 這一層。
主入口是固定的：登入 Cloudflare dashboard → 選擇帳號 → 選擇網域（zone） → Security → Bots。Block AI Bots、Bot Fight Mode，以及新的 Search／Agent／Training 三分類管理，都在這一層。Cloudflare 在 Bot Fight Mode 的入門文件 裡給的步驟就是這個順序：登入、選帳號、選網域、進 Security > Bots、把 Bot Fight Mode 切到 On。Block AI Bots 的 managed preset 跟三分類管理共用同一個入口。
9/15 新預設的退出標記也在 Security settings（Security → Bots 這層）裡。如果你有新網域要上架、那個網域會放廣告、又希望 Training 爬蟲能進來，9/15 之前要在這裡標記「對同時用於 Search 的 Training 爬蟲不做變更」。Cloudflare 會在接近 9/15 持續通知，不會靜默套用。
方案差異要看清楚，這是免費方案用戶最常踩到的疑惑。Bot Fight Mode 是 Free 方案就有的單一開關，整域一鍵挑戰偵測到的 bot；Super Bot Fight Mode 是 Pro／Business 方案，可依 bot 類別設動作、支援 WAF custom rule 例外；Bot Management 與 BotBase 則是 Enterprise 限定，提供 per-request bot score、自訂規則、per-endpoint 處理與詳細分析。如果你是 Free 或 Pro 用戶，在後台找不到 Bot Management configuration card 是正常的，那是 Enterprise add-on 才會出現的卡片。影響 Free／Pro 站長的是三分類與 9/15 預設，不是 BotBase，而新的三分類管理依公告對所有方案（含 Free）開放。關於三個 bot 產品的範圍與差異，Cloudflare Bots 總覽 有完整說明。
設定改完要驗證才算數。Security → Events 可以看實際 bot 流量事件，這個面板所有方案都有（Free 的 log 是取樣、保留約 24 小時）。想看更細的 bot 流量趨勢分析要用 Bot Analytics，但 Bot Analytics 是 Business 與 Enterprise 方案才有，Free／Pro 用戶在後台找不到這個面板是正常的。對 Free／Pro 站長來說，靠 Security → Events 的取樣資料判斷設定有沒有生效，是夠用的起點。
再提醒一次誠實界線：Cloudflare 介面改版頻繁，分頁順序、按鈕的精確標籤、某個 toggle 的中文翻譯都可能調整，上面給的是依 2026 年 7 月官方文件與公告的路徑，不是永遠不變的硬編路徑。只要記住主入口在 Security → Bots 這一層，確切按鈕找一下就能對上。
遞移信任與 Forwarded header：當 agent 不是打造它的公司在跑
分類法跟 content-use 都還是「你對單一 bot」的控制。公告裡還有另一個更前沿的問題：來敲門的 bot 或 agent 往往不是打造它的公司在跑，平台同時為數千個不同業者跑自動化。你信任 Stripe，但不一定信任每個把 Stripe 工具接進週末專案的人。這種「站長信任 bot 業者，bot 業者又服務終端使用者」的鏈，叫做遞移信任（transitive trust）問題。
Cloudflare 在提案裡沿用 RFC 7239 定義的 Forwarded header 嘗試解這個問題，範例寫法是 Forwarded: for="openai";use="reference"，讓每一層中介在 header 裡累積資訊，站長看得到請求背後的 operator 鏈，而不只看最外層 User-Agent。這套機制目前還在實驗階段，對中小站長是未來式，現在還不用動手設定；當 agent 不再只來自少數幾家大公司、而是無數個體開發者用大公司 SDK 組合出來的長尾應用時，傳統 User-Agent 分類會失效，那時 Forwarded header 才會變成主力識別機制。對企業安全團隊來說，這是未來幾季該追蹤的方向。Cloudflare 自己也誠實交代了限制：當 bot 流量與真人流量混雜時，這套機制未必能擴及所有「負擔得起被識別」的使用者以外，小流量來源的隱私需求它現在還覆蓋不到。
Pay-Per-Crawl 跟新分類法是兩件事
第一屆推的 Pay-Per-Crawl 市集今年還在，它跟新分類法解決的問題不同，很多讀者會搞混。Pay-Per-Crawl 的命題是「補償」：AI 業者要來抓你內容，付錢，本質上是交易機制；三分類的命題是「控制」：你能不能選擇讓 bot 做什麼，本質上是許可機制。兩者互補不衝突，理論上可以同時做，但 Pay-Per-Crawl 假設你站內容夠有價值、AI 業者願意付費取得，這對頭部媒體、大型資料站、專業內容供應商成立，對長尾內容站不一定成立。Pay-Per-Crawl 對中小站點的現實意義有限，該認真研究的還是三分類跟 9/15 預設，Pay-Per-Crawl 留給高流量、高價值內容站台考慮。
跟其他 AI 流量管理手段的比較
三分類跟 content-use 是 Cloudflare 自己系統內的工具。站長手上其實還有其他手段，搞清楚它們的差別，才知道什麼時候用什麼。
傳統 robots.txt allow／disallow：最老牌、最通用，所有 bot 業者理論上都會讀。問題是它是「全有全無」的二元工具，要嘛允許要嘛禁止，沒有「允許但只能 reference」這種層次。Cloudflare 的 content-use 訊號（use= 欄位）是對傳統 robots.txt 的延伸，但只有配合的 bot 業者會遵守。
Server-side WAF 規則：在 nginx、Apache、或主機商防火牆層級根據 User-Agent、IP、行為特徵攔截。強制力最高，但設定成本也最高，且需要持續維護（bot 業者換 User-Agent 就要跟著改）。對小站長來說通常不划算。
Cloudflare 新分類法：在 Cloudflare 邊緣生效，介於 robots.txt（軟）跟 server-side（硬）之間。強制力比 robots.txt 高，因為 Cloudflare 直接在邊緣攔截；設定成本比 server-side 低，因為 Cloudflare 維護 bot 資料庫。代價是你要在 Cloudflare 後面。
Forwarded header 未來機制：還在推動階段，目前是承諾而不是實施。等於「未來的基礎建設」，現在用不到。
| 手段 | 強制力 | 設定成本 | 細粒度 | 適用範圍 |
|---|---|---|---|---|
| robots.txt allow／disallow | 軟（靠 bot 配合） | 低 | 二元 | 所有站長 |
robots.txt use= 訊號 | 軟（靠 bot 配合） | 低 | 三級 | 所有站長（理念上） |
| Server-side WAF 規則 | 硬（直接攔） | 高 | 高（規則自訂） | 有技術力的站長 |
| Cloudflare 三分類＋面板封鎖 | 中（邊緣攔） | 中 | 中（情境分類） | Cloudflare 客戶 |
| Forwarded header | 未來式 | 未來式 | 未來式 | 業者配合才生效 |
對多數中小站長，組合會是：robots.txt 表達意願（包括新的 use=reference），Cloudflare 面板做實際封鎖，server-side 規則留給特殊需求。把這三層想成「聲明、執行、補強」，會比「哪一個最強」更接近現實。
不是 Cloudflare 用戶的站長也不是完全用不到這次公告的東西。robots.txt 的 use= 是 Cloudflare 推動的開放訊號，理念上任何站長都可以寫進自己的 robots.txt；content-use 三等級（immediate／reference／full）是對「內容被 AI 用到什麼程度」這個問題的清晰分類，這個分類邏輯即使你不挂 Cloudflare，也可以拿來檢視自己對 AI 流量的真實偏好。
站長的決策流程
把上面這些放進一個可執行的流程，大致是這樣：
| 步驟 | 動作 | 判斷標準 |
|---|---|---|
| 1 | 確認站台是否在 Cloudflare 後面 | 沒有就跳過 9/15 新預設三分類這整段，但可參考 content-use 訊號邏輯 |
| 2 | 看目前 Block AI Bots 是開或關 | 開著的代表你過去選擇封鎖訓練用途 bot |
| 3 | 評估站台是否靠搜尋流量、是否有廣告 | 兩個都「是」的話，封鎖 Training 要非常小心連帶封鎖 Googlebot 的成本 |
| 4 | 決定 Search／Agent／Training 各自策略 | Search 多數放行；Training 視內容資產價值；Agent 視頁面性質 |
| 5 | 評估是否設 use=reference | 經營 AEO 又要保護原創，設 reference；純封鎖站台可不設 |
| 6 | 9/15 前決定是否退出新預設（針對新網域） | 若新網域會放廣告且希望 Training 爬蟲能進來，記得到 Security → Bots 標記 |
幾個判斷要展開講。
第 3 步是真正的分岔點。多數中小站點（內容站、媒體、品牌站、電商）都靠 Google 自然搜尋吃飯。對這類站台，封鎖 Training 而連帶封鎖 Googlebot 的成本，遠大於「擋掉 AI 訓練」的收益。你的核心資產是能見度，不是「內容沒被吸收」。如果不確定，預設應該往「不擋」傾斜。
第 4 步的 Agent 是新聞題。多數站長這次會第一次認真想「Agent 要不要放」。如果你經營的是工具型服務頁、SaaS、有 AI 助理會過來抓資料的頁面，Agent 等於流量來源，放行合理。如果你的頁面被 agent 大量造訪會拖垮體驗或吃頻寬，那就要選擇性封鎖。
第 5 步的 content-use 對 AEO 站台最相關。以我們自己為例，因為 AEO 是主要任務，我們的站台會維持刻意開放 AI 爬蟲的既有策略，content-use 訊號對我們來說是「額外聲明意願」的層次，不是替代既有的開放政策。對非 AEO 站台來說，這個訊號幫助有限，因為你連 Search 都不一定想全放。
第 6 步是 9/15 前的硬截止。如果你公司下半年會在 Cloudflare 上架新網域，而且那個網域會放廣告、又希望 Training 爬蟲能進來（這個組合罕見但存在，例如某些 AI 訓練資料貢獻型站台），9/15 前要到 Security → Bots 主動標記。其他多數站長的預設動作是「不動作」，但要清楚不動作會帶來什麼。
設定改完不是終點，要驗證才有意義。Cloudflare dashboard 的 Security → Events 跟 Bot Analytics 可以看實際 bot 流量變化，這是驗設定有沒有生效的第一手訊號。如果你像我一樣想看更細的資料，特別是想知道「到底哪些 AI bot 在敲我、抓了多少」，在邊緣架一個 Worker 記請求 header 是可行的路徑：攔下 User-Agent、IP、請求路徑，寫進 D1 或任何你可以查的儲存，就能看到 GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBot 這類 bot 的實際造訪模式。這不是 Cloudflare 的內建功能，是自己架觀測層，但對認真做 AEO 的站台，這個觀測本身就是判斷要不要調設定的依據。
要特別提醒一個常被忽略的盲點：bot 流量數字本身沒有判斷價值，除非你跟自己的內容產出節奏對照看。例如某個月 GPTBot 來抓的次數暴增，要看的是那段時間你有沒有出新文章、有沒有被外部高權重站連結，而不是單看數字焦慮。同理，某個 bot 造訪減少也不一定是壞事，要看你的搜尋能見度跟 AI 引用是否同步變化。判斷的時候把數字擺進脈絡裡看，別被單一數字牽著走。
常見誤解與限制
下面整理幾個會在論壇、社群、轉發文裡看到的誤解。
「9/15 Cloudflare 要預設擋 AI」：錯。五個條件缺一不可，新網域、廣告頁、擋 Training＋Agent、Search 照放、多用途爬蟲連帶被擋。任何少講一個的轉發都可以跳過。
「設了 use=reference 就安全了」：錯。use= 是 robots.txt 偏好，靠 bot 配合。Cloudflare 用 Verified 機制嚇阻濫用，但這是嚇阻力，不是絕對保證。要真正強制，得在 Cloudflare 面板對特定 bot 做封鎖。
「Block AI Bots 等於擋全部 AI」：錯。舊的 Block AI Bots 只涵蓋「為模型訓練而爬資料的單一用途 bot」，新三分類才是更廣的控制。但它們疊加起來會對多用途爬蟲產生連帶封鎖效果。
「我是 Free 方案，這些對我無感」：錯。新三分類與 9/15 新預設含 Free 方案。只有 BotBase 限 Enterprise。
「不是 Cloudflare 用戶，這跟我無關」：半對。Cloudflare 的分類法跟 content-use 訊號是給 Cloudflare 客戶的工具，但 robots.txt 的 use= 欄位是 Cloudflare 推動的開放訊號，理論上任何站長都可以照這個邏輯調 robots.txt。實際效果還是靠 bot 業者配合，但理念可以借鏡。
「Verified 一定安全」：錯。Verified 從「預設允許」改成「有資格被允許」。會完整重現的 bot 不能 Verified，濫用訊號會失 Verified。Verified 是資格門檻，不是通行證。
「擋掉 Googlebot 就不會被 AI 訓練」：錯。Googlebot 是 Google 搜尋的索引爬蟲，擋掉它你失去的是搜尋能見度。要把「不願被訓練」跟「不願被搜尋索引」分開想，前者看 Training 開關，後者看 Search 開關，雖然目前 Googlebot 在 Cloudflare 分類裡跨兩類（這個連帶效果前面講過），但邏輯上這是兩件不同的事。
幾個限制也講清楚。Forwarded header 在 bot 流量與真人流量混雜時未必能擴及所有場景，小流量來源的隱私需求它現在還覆蓋不到。BotBase 是企業方案才有的可見度工具，中小站長看得到介紹但用不到。9/15 預設的「廣告頁」判定邏輯由 Cloudflare 內部決定，公開資訊沒有說明是否需要特定廣告標記或人為標記，實務上可用工啟發式判斷（頁面有投放 AdSense 等廣告聯播網或主動插入廣告單元就視為廣告頁），但這是站長側的判斷，不是 CF 公開的技術定義，你未必能精準知道哪些頁面被 Cloudflare 歸進來。
給不同成熟度站台的優先順序
三分類跟 content-use 對不同成熟度的站台，優先級不一樣。把它想成「先做哪一件事投資報酬率最高」，會比一次想做完所有設定更實際。
剛上線的內容站（0 到 6 個月）：什麼都不要擋。這個階段核心問題是「沒人認識你」，任何阻擋都是在砍自己的能見度。robots.txt 維持允許所有 bot，加上 use=reference 表達意願即可。9/15 新預設即使套用到你身上，因為這階段通常還沒放廣告，影響有限。
成長期站台（6 到 24 個月）：開始用三分類檢視實際 bot 流量，但預設仍然偏開放。如果這階段開始放廣告變現，要認真評估 Training 開關對 Googlebot 的連帶效果。content-use 訊號設 reference 是這階段最值得做的單一動作，投資報酬率最高。
成熟的內容資產站（24 個月以上）：這時才有本錢認真考慮封鎖 Training。搜尋能見度已經穩定、品牌直接流量也占一定比例，承受 Googlebot 連帶被封鎖的能力比新站高。但即使如此，封鎖前還是要做流量交叉比對，確認搜尋流量不會被影響。企業級站台這時才考慮 BotBase 做精細可見度控制。
三分類不是每個站台都該立刻設好的工具。不同階段有不同的最佳解，照單把每個開關都打開通常不是好主意，依站台所在階段判斷才準。很多站長會在讀完這類公告後衝動地把所有開關都調一遍，但實務上，多數站台在前 12 個月根本還沒走到需要細粒度控制的階段，過早設定只是在增加自己未來除錯的難度。
常見問題
9/15 之後我既有的站台會被影響嗎？
不會自動被影響。9/15 新預設只針對新上架到 Cloudflare 的網域。你既有的網域維持現狀，除非你主動去調整設定。
我是 Free 方案，能用三分類設定嗎？
能。新的 Search／Agent／Training 三分類對所有客戶開放，含 Free 方案。只有 BotBase 是 Enterprise Bot Management 功能，Free／Pro 用戶在後台看不到 Bot Management configuration card 是正常的。
擋了 Training 會連帶擋到 Google 嗎？
會。Cloudflare 在公告裡把 Googlebot 與其他多用途爬蟲並列為「同時用於 Search 與 Training」的類型，所以擋 Training 會連帶封鎖 Googlebot。分類法面對這種跨類爬蟲的處理規則是取最嚴格那一條，沒有半開半關的選項。如果你的站台靠 Google 自然搜尋流量，這個連帶效果要先算進決策。
use=reference 跟 Block AI Bots 衝突嗎？
概念上不衝突，但作用層次不同。Block AI Bots 是 Cloudflare 設定面板上的強制封鎖，針對訓練用途 bot；use=reference 是 robots.txt 上的偏好聲明，靠 bot 業者配合。前者是牆，後者是標示。可以同時用，但要清楚哪個是強制、哪個是意願。
我已經開了 Block AI Bots，9/15 之後要怎麼調？
如果你是既有網域、且 9/15 之前就開啟了 Block AI Bots，9/15 新預設不會自動覆蓋你的選擇，你維持現狀。但建議重新評估：舊 Block AI Bots 只封鎖「為訓練而爬的單一用途 bot」，新三分類讓你看到更廣的控制面。你可以關掉 Block AI Bots、改用新三分類，得到更細的控制；也可以維持原狀，但要記得舊設定對多用途爬蟲會產生連帶封鎖。
Cloudflare managed robots.txt 跟自己寫 robots.txt 差在哪？
managed robots.txt 是讓 Cloudflare 幫你維護 robots.txt，優點是它會自動加上新的 content-use 訊號（如 use=reference），隨訊號標準演進自動更新；缺點是你要放棄一部分控制權。自己寫的話，你有完全控制權，但要自己追蹤新訊號、自己更新。對大多數站長，managed 是合理選擇；對有特殊 robots.txt 需求的站長，自己寫更適合。
不是 Cloudflare 用戶，這些對我有影響嗎？
三分類跟 9/15 預設對你沒直接影響，因為那是 Cloudflare 內部機制。但 robots.txt 的 use= 訊號是開放格式，理論上任何站長都能寫進自己的 robots.txt，意願表達靠 bot 業者配合。如果你在乎 AEO，理解這個訊號的邏輯對你還是有價值。
我做 AEO，到底該怎麼選？
核心判斷：想被 AI 引用、又要保護原創，reference 是甜區。Search 放行換能見度，Training 視內容資產價值決定，Agent 視頁面性質決定。如果你過去完全不擋是因為沒有工具，這次三分類給了你中間選項，認真考慮把 Training 拆出來單獨處理。記得一個原則：先想清楚你站台的變現模式跟核心資產，再回頭看三分類怎麼設，不要反過來。也要記得，reference 等級實際換到多少 AI 引用頻率，目前沒有 AI 搜尋業者公開的資料證實，這個甜區判斷是站長側的合理推論，不是已驗證的贏家公式。
這套設定多久該檢視一次？
AI 爬蟲的版圖變化比傳統搜尋快很多。Cloudflare 自己也在公告裡說，BotBase 現階段先做可見度，今年稍晚會擴充成控制中心，這意味著分類法跟訊號都還在演進。建議的檢視節奏是：每次 Cloudflare 發布 Content Independence Day 之類的重大公告（通常一年一度）、每次 BotBase 有實質功能更新、以及每次你自己站台策略有重大調整（例如新增廣告、新增服務頁、轉換商業模式）時，重新檢視一遍三分類設定跟 content-use 訊號。把這個檢視排進 SEO 例行稽核的行事曆，比憑直覺調整可靠。
結論：這次公告真正改變的是什麼
Cloudflare 這次公告真正改變的，不是「多了一道牆」，而是把原來那道二元牆拆成三個開關。對站長來說，影響最直接的兩件事是：9/15 新預設（只動新網域、只動廣告頁、只擋 Training＋Agent，但多用途爬蟲連帶被擋），以及 content-use 訊號（讓 reference 等級成為 AEO 的甜區）。
如果你只記一句話，記這句：問題從「這個 bot 是不是 AI」改成「它在站上做什麼」。後面所有新工具，都是從這個分類法長出來的。
給你三個下週就能執行的下一步。第一，登入 Cloudflare dashboard，到 Security → Bots 確認目前的 AI bot 管理狀態，順便看 Security → Events 跟 Bot Analytics 建立基準。第二，如果站台靠 Google 自然搜尋吃飯，封鎖 Training 之前先確認能承受 Googlebot 連帶被封鎖的風險。第三，評估是否在 robots.txt 加上 use=reference，把它當成對 AI 業者的公開意願聲明，而不是保險箱。
這套工具會繼續演進，9/15 也不會是最後一次調整。把判斷邏輯建立清楚，下次 Cloudflare 改規則時你才有能力自己重新評估，而不是又跟著轉發標題走。下一次 Content Independence Day 公告出來時，回來用同一套框架（分類軸變了沒、預設條件幾個、哪個方案受影響、Verified 跟 content-use 怎麼演進）重跑一遍，這才是面對這類公告真正該建立起來的能力。
