Day 6 已經把 Cloudflare 2026-07-01 公告原文逐句拆解過了，包含三種分類、新網域預設、有廣告的頁面，以及 Block AI bots 開關同日棄用的細節。這些今天不重複說明。

今天處理的是另一個問題，而且是多數人真正該問的那一個：

我的 zone 已經在 Cloudflare 上跑了兩年了。9/15 那天，我這邊到底會不會受到影響？

答案是：會，但不是你以為的那件事。 而且它藏在一句很容易漏讀的句子裡。

所有引用截至 2026-09-07，以 Cloudflare 官方英文頁面為準，逐字出處請見文末證據清單。

刊出時間說明：本篇在 9/15 之前寫成，刊出時 9/15 已經過了。清單裡標示「現在」、「9/15 前」的動作，如果你還沒做，今天做仍然成立，也就是把「之前的快照」當作「今天的快照」，之後每一步照樣拿它來做比對差異 (diff)。

一、先把「適用對象」釐清

網路上關於 9/15 的轉述，過度延伸的版本很多。我只採用官方網頁實際寫的字。

官方在 Bots 文件的 Block AI bots 頁面上寫得很明確：

「On September 15, 2026, Cloudflare will set updated defaults for new domains: bots classified as Training or as Agent will be blocked on pages that display ads, and Search will remain allowed.」

更新日誌的用字一樣：「new domains onboarding to Cloudflare receive updated defaults」。

所以：新的三分類預設值，只套用在 9/15 之後新加入 Cloudflare 的網域。 你既有的 zone 不會因為日子過去就被更改設定。這一點跟 Day 6 的結論一致，我又核對了一次官方原文，規則並沒有變。

不過官方文字裡有一處我沒辦法找到合理解釋，在此誠實寫出來：同一份公告也提到「All customers can opt out of the new defaults at any time before September 15」。如果新預設只影響新網域，「所有客戶」要退出什麼？這兩句話在邏輯上有些矛盾。我查不到官方的進一步說明，所以不替 Cloudflare 找理由，也不據此推論既有 zone 會被更改設定。如果決策卡在這一點，請直接去自己 zone 的設定頁面查看實際狀態，別相信任何二手轉述，包含本篇文章。

二、但既有 zone 確實有一件事會受到影響

這才是今天的核心，而且它跟預設值無關。

同一頁上，緊接著的下一句是這樣寫的：

「Mixed-purpose crawlers that combine Search and Training will also be blocked by all configurations to block AI training, including the legacy "Block AI bots" option.」

把這句話跟舊版開關現在的運作方式對照著看，差別就出來了。舊版 Block AI bots 開關現在的定義是：

「This setting blocks verified bots that are classified as crawling for the purpose of AI training, as well as a number of unverified bots that behave similarly.」
「Note: This option excludes mixed-purpose bots that are used both for Training and for Search.」

看出來了嗎？

影響對象是任何一個現在把 Block AI bots 開啟的既有 zone。 你什麼都不用做，9/15 那天封鎖範圍就會自動變大。

方向是變得更嚴格。代價是，一隻同時做搜尋索引與模型訓練的爬蟲，以前幫你做索引的那一面會被放行，之後就不會了。如果你的內容策略是「不要被拿去訓練，但可以被搜尋引擎和問答系統引用」，這個變化剛好會阻擋你想留下的那一半。

所以第一件該做的事，就是去檢查你那個設定現在是開還是關。

三、自我檢查清單：五個步驟，每一步都有可驗證的動作

不要只在控制台上隨便看一眼。每一步都要留下可供比對的證據，9/15 之後才有基準線可以參考。

步驟 1：舊版開關現在是什麼狀態

Security > Settings > Block AI bots。

• 關閉狀態：第二段提到的變化跟你無關，直接跳到步驟 2。
• 開啟狀態：你在 9/15 的影響範圍內。現在就得決定是要接受更嚴格的封鎖，還是要在 9/15 前轉移到新的三分類設定，把 Training 和 Search 分開處理。

步驟 2：新的三分類現在是什麼狀態

Security Settings > Configure AI bot policies。

三類各自有三個選項，官方逐字說明：

• Block (on all pages)：「Issues the block across the entire zone.」
• Block on pages with ads：「Uses Cloudflare automated detection for pages that display ads on your zone to block only on those pages.」
• Allow (do not block)：「Does not add any blocking.」

三類的定義也逐字抄一次，因為判斷時會用到：

• Search：「crawlers that collect or index your content to answer questions about it later.」
• Agent：「automated activity acting in real time on a person's behalf, such as chat fetch bots and browser-use agents.」
• Training：「crawlers taking your content to train or fine-tune a model, including mixed-purpose crawlers that are used both for Training and for Search.」

Training 的定義裡明寫混合用途爬蟲被包含在內，這正呼應了第二段提到的新版行為變化。舊版開關是往新機制的行為靠攏，而不是新增了一個獨立的規則。

還有一句影響範圍很大，千萬別漏掉：「Each blocking option will block Verified bots classified with that behavior, plus additional unverified bots that fall under these classifications.」 擋的不只是已驗證的爬蟲，還包含被歸類到同性質的未驗證流量。

步驟 3：你的 robots.txt 現在回傳什麼

一行指令就能驗證，而且結果常常出乎意料：

curl -sS https://你的網域/robots.txt

Day 6 講過：免費方案的網域如果既沒有自己的 robots.txt，也沒開啟 Managed robots.txt，爬蟲會拿到 Cloudflare 預設的 Content Signals Policy。很多網站管理員不知道自己的網域正在回傳一份從沒寫過的檔案。

把輸出結果存起來。 9/15 之後再跑一次做比對，這是成本最低的變更偵測方式。

步驟 4：鄰居開關

昨天 (Day 9) 提到的那三個設定。它們跟 AI 設定屬於不同的層級，而且會在更早的階段把爬蟲擋掉：

• Browser Integrity Check (預設開啟)
• Bot Fight Mode (免費方案，WAF 的 Skip 對它無效)
• Super Bot Fight Mode 的 Verified bots 設定 (Pro / Business)

在 AI bot policies 上把 Search 設成 Allow，不代表 Search 類爬蟲就一定進得來。前面幾層先放行，後面的設定才有意義。

步驟 5：存一份目前的快照

清單裡最重要，也最常被跳過的一步。

# 1. robots.txt 現況
curl -sS https://你的網域/robots.txt > robots-before.txt

# 2. 各家爬蟲 UA 的可達性矩陣
for UA in "GPTBot/1.2" "OAI-SearchBot/1.0" "ChatGPT-User/1.0" \
          "ClaudeBot/1.0" "PerplexityBot/1.0" "CCBot/2.0" \
          "Googlebot/2.1" "Google-Extended/1.0"; do
  CODE=$(curl -sS -o /dev/null -w '%{http_code}' -A "$UA" https://你的網域/)
  echo "$CODE  $UA"
done | tee ua-matrix-before.txt

# 3. 設定頁截圖：Block AI bots、Configure AI bot policies、Bot traffic 三張

為什麼一定要現在做： Security Events 在免費版與 Pro 版只保留 24 小時，Business 版 3 天，Enterprise 版 30 天。9/15 之後才想回頭比對之前的狀態，資料早就已經不在了。花五分鐘，換取你唯一的基準線。

第五段會用到它。

四、混合用途爬蟲：怎麼判斷誰是誰

既然變化的核心是混合用途爬蟲，就必須知道哪些算在內。

官方沒提供名單，給的是判定原則：混合用途爬蟲會 according to all of their behaviors 來判定，也就是根據它的所有行為來算。這是行為導向，不是單純查表。

實務上就問一句：同一個 User-Agent (UA) 拿到的內容，會不會被用在超過一種用途上？

對照 Day 2 的圖鑑，粗略的分野是：

• -Bot 結尾的訓練型爬蟲 (GPTBot、ClaudeBot、CCBot)，這類單一用途明確，一直都在舊開關的封鎖範圍內。
• -SearchBot 或 -User 這類 (OAI-SearchBot、ChatGPT-User、Perplexity-User)，偏向索引與即時檢索，對應新版設定的 Search 與 Agent 類別。
• 中間地帶，若一家公司用同一隻爬蟲同時執行索引與模型訓練工作，這才是「混合用途」要處理的對象。

但有個事實你得接受：分類是 Cloudflare 做的，而且它不公開每隻爬蟲的分類結果。 你沒有可以事先核對的對照表。

這正好帶到下一節，你能拿到的，是每一個請求上那個分類欄位的實際數值。

五、cf.verifiedBotCategory 的數值該怎麼看

Day 8 那支 Worker 裡有一個欄位當時說「先照原樣存下來」，現在來處理它：request.cf.verifiedBotCategory。

它是 Cloudflare 在邊緣節點告訴你這隻已驗證機器人屬於哪一類的欄位，在 WAF 規則語言裡對應 cf.verified_bot_category，官方定義是「Provides the type and purpose of a verified bot.」

麻煩的地方在於：它可能出現的值有新舊兩組，而官方文件沒有明講欄位實際會回傳哪一組。

新的行為分類 (2026-07-01 起，共 11 類)：

舊的分類字串 (仍為 WAF custom rules 保留相容，共 17 個)： Academic Research、Accessibility、Advertising & Marketing、Aggregator、AI Assistant、AI Crawler、AI Search、Archiver、Feed Fetcher、Monitoring & Analytics、Page Preview、Search Engine Crawler、Search Engine Optimization、Security、Social Media Marketing、Webhooks、Other。

官方對這兩組的關係只說了一句：新分類「are not individual fields in WAF custom rules, but have backwards-compatible categories from the original taxonomy of Verified bots」。

所以工程上正確的作法只有一個：不要把條件寫死 (hardcode) 來比對這個欄位，請把原始字串原樣存下來。

理由不只是有兩組可能的值。這個欄位的文件說明一直不夠完整，Cloudflare 自己的 GitHub 儲存庫上有過一個 issue，抱怨官方文件沒列出開發者實際要拿來比對的字串值，還點出一個具體的差異，官方文件寫小寫的 preview，但 Worker 實際取得的卻是大寫開頭的 Preview。該 issue 雖已關閉，但所有可能的值仍然沒被完整列在欄位參考頁面上。

一個 if (cat === "AI Crawler") 在你寫的那天可能是對的，但在 Cloudflare 調整分類的那天就會默默失效，它不會報錯，只會少跑一行邏輯。

還有一個很具體的坑，我在 Day 8 本機實測時遇到：沒有值的時候，這個欄位是空字串 ""，而不是 undefined 或 null。

// 這樣寫，以為存 null，實際上存了 ""
verified_bot_category: cf.verifiedBotCategory ?? null,

?? 只對 null 和 undefined 生效，對 "" 完全沒有作用。之後你在資料庫下 WHERE verified_bot_category IS NULL 想撈出沒被驗證的請求，一筆都撈不到。

(我實測到的是本機 wrangler dev 環境的行為；正式的邊緣環境對非已驗證機器人回傳的是空字串還是 undefined，我還沒在自己的 zone 上實機確認。這正是建議「保留原始值」的另一個理由：對於不確定的內容，不要在寫入資料庫前就擅自修改。)

六、改完之後，怎麼證明它真的生效了

改設定很快，證明改對了才是難的部分。三個層次，由粗到細：

層次一：UA 矩陣的修改前後比對

步驟 5 存的那個 ua-matrix-before.txt 現在派上用場：

# 改完設定之後重跑同一個迴圈
for UA in ...; do ... ; done > ua-matrix-after.txt
diff ua-matrix-before.txt ua-matrix-after.txt

差異 (diff) 就是這次改動的實際效果。空的差異也是一種結果，代表你改的東西沒影響到這幾隻爬蟲，可能是改錯地方了。

但要記住 Day 9 的教訓：這是你用 curl 測試的結果，不是爬蟲真實的遭遇。 它是必要的快速檢查訊號，不是最終的證據。

層次二：Security Events 的 Service 欄位

Security > Analytics > Events。 這一欄直接告訴你是哪個功能擋的，包括 Bot Fight Mode、Super Bot Fight Mode、Browser Integrity Check、WAF custom rules，各自都會對應不同的數值。

改完設定之後去看，原本被某一項擋掉的請求應該消失，或換成別的 Service 數值。

限制還是那個 24 小時 (Free / Pro)。當天查，不然就查不到了。

層次三：你自己的紀錄 (唯一的最終證據)

Day 8 那支 Worker 記下的每一筆都有 crawler 和 verified_bot_category。這是唯一能回答「真實的爬蟲有沒有進來」的依據，裡面記錄的是真實流量，而不是你手動發出的測試請求。

改完設定之後，關注三個問題：

1. 原本會出現的爬蟲名字，還在不在？ 消失就是被擋了。
2. verified_bot_category 的數值分佈有沒有變？ 這是分類端改變最直接的訊號。
3. 總量的變化，是不是跟你的預期同方向？ 你打算放行卻沒變多，或打算收緊卻沒變少，都代表改的不是你以為的那一層。

有個時間差要有心理準備：AI 爬蟲不會每天來。 訓練型爬蟲的回訪節奏動輒以週來計算 (Day 22 的題目)。改完兩天內看不到變化，很可能只是它還沒回來。別在 48 小時內太早下結論，更別因此又把設定改回去。

七、9/15 那一週的時間表

回顧一下這波變動的幾個核心結論：

1. 新的三分類預設值只套用新網域。 官方原文只寫 "new domains onboarding to Cloudflare"，過度延伸的二手資訊請勿採用。同一份公告裡「所有客戶都可以退出」那句跟這點有些矛盾，我查不到進一步的說明，所以不替它找理由，也不據此推論。
2. 既有 zone 真正會受到影響的是這件事： 9/15 之後，混合用途爬蟲會被所有封鎖 AI 訓練的設定擋下，包含舊的 Block AI bots 開關，而那個開關現在是排除它們的。開啟這顆開關的既有 zone，什麼都不做，封鎖範圍就會擴大。
3. cf.verifiedBotCategory 有新舊兩組可能的值，而且文件沒明講回傳哪一組。 別把條件寫死做比對，請原樣存下來；沒值的時候是空字串，?? 會攔截不到。
4. 改完之後的驗證有三個層次，只有第三層 (你自己的紀錄) 算最終證據。而且要耐心等待，別在 48 小時內下結論。

最後講一件比 9/15 更長遠的事。Cloudflare 過去 14 個月改了至少五次 AI 相關的產品面貌，連名字都換過。 我寫這篇的時候一直有個不太舒服的感覺：今天查到的每一句原文，半年後可能都要重新確認一次。

所以真正能撐住的，不會是「我這次設定對了」。是你手上有一份自己的紀錄，能隨時回答現在到底發生什麼事，無論設定頁面怎麼改版都不影響它。那正是 Day 8 那支 Worker 存在的理由。

明天 (Day 11) 換探討一個更底層，也更常被忽略的變數：灰雲跟橘雲對 AI 爬蟲觀測到底差在哪裡。 今天講的每一個設定，都有一個共同前提，也就是請求必須先進到 Cloudflare 的邊緣節點。有一整類主機名稱，在結構上從來沒進去過。

本文是「你的第一本 AEO x GEO 教戰手冊」系列第 10 天。系列實測與數據由 arrivl 整理，這是一個專注於 Growth Analytics for the Agentic Web 的工具。