Googlebot 一支爬蟲身兼搜尋索引與訓練資料蒐集兩種工作，過去站長只有兩個選項：兩者都要，或兩者都不要。Cloudflare 從 9 月 15 日起把這支爬蟲拆成三種可辨識的行為，讓「只退出訓練、留住搜尋」第一次有機會成真——前提是，對方爬蟲的操作者願意遵守你寫進 robots.txt 的偏好。
想被搜尋，不想被訓練
Googlebot 抓一次網頁，內容可能同時用在兩個地方：進搜尋索引，或者進訓練資料集。這兩件事對站長來說風險完全不一樣——退出搜尋等於從網路上消失，退出訓練只是不想讓內容被拿去練模型。Cloudflare 從 9 月 15 日起把這類爬蟲的行為拆成三種可辨識的類別，並把「一支爬蟲同時做好幾件事」這件事正式取了名字。
Cloudflare 把爬蟲行為分成三類：searchCrawling to build a search index.、trainingCrawling to train or fine-tune a model.，以及agentUser-directed agents visiting a page on behalf of a human, such as chat fetch bots and browser-use agents.（游標停在詞上可以看到 Cloudflare 自己的原文定義）。Cloudflare 也承認同一支爬蟲常常同時符合好幾種行為，把這種爬蟲取名叫 mixed-use crawler——一支爬蟲同時做 Search 與 Training。過去要擋掉其中一種行為，很容易連帶擋掉另一種。
Cloudflare 自己的說法是「some of the largest organizations on the Internet use mixed-use crawlers」——搜尋引擎這個生意做得最大的幾家，剛好也是把訓練資料蒐集綁在同一支爬蟲裡的幾家。
對正在幫公司網站設定 CDN 或 WAF 的工程師來說，這不是可以晚點再看的設定。Cloudflare 在 9 月 15 日把舊的二元開關淘汰，代表任何還停留在舊介面、以為自己已經設定好「擋 AI」的網站，實際上可能連 Search、Training、Agent 這三種行為都還沒被正確分流。
下面這張表先攤開七家的位置：各自用什麼機制退出訓練、退出訓練會不會傷到搜尋、現在能不能用——後面四段再逐一拆開細節。
click column header to sort · 5 columns × 4 rows
| 陣營 | 退出訓練的機制 | 是否影響搜尋 | 現在能用嗎 | 備註 |
|---|---|---|---|---|
| Google-Extended（robots.txt token） | 不影響 | 現在 | 沒有獨立抓取行為，只控制既有結果的用途 | |
| Apple | Applebot-Extended（robots.txt token） | 不影響 | 現在 | 官方範例示範子路徑封鎖，不是整站 |
| Microsoft | NOARCHIVE（頁面 meta tag，逐頁設定） | 不影響 | 現在（NOARCHIVE）／robots.txt 版本 2027 年初 | 先靠 NOARCHIVE 過關，robots.txt token 化是補課 |
| Amazon・Anthropic・Meta・OpenAI | 獨立 Training 爬蟲（防火牆直接攔截） | 不影響 | 現在 | 搜尋與訓練是兩支獨立的爬蟲，不靠宣告 |
Accountable 的四道門檻，兩條路都要過
Cloudflare 把「可以信任」的爬蟲操作者稱作 Accountable，自己訂了四條門檻：一是能透過 robots.txt，或「類似的標準」，退出 AI 訓練；二是能直接向操作者退出 AI 摘要，Cloudflare 說明年會多一條透過 Cloudflare 本身操作的路徑；三是網址層級的可見度，能看到哪些頁面被開放給訓練用，並附上內容在搜尋結果裡的表現指標；四是保證退出訓練不會影響傳統搜尋結果。第三條與第四條放在一起最有意思——前者要求「看得到」，後者要求「不傷搜尋」，兩條合起來，退出訓練才不再是一場賭博。
照 Cloudflare 的說法，Apple、Google、Microsoft 這三家 mixed-use 爬蟲的操作者都已經符合 Accountable 資格；Amazon、Anthropic、Meta、OpenAI 這四家也一樣被列進 Accountable 名單，路徑卻完全不同——前三家靠同一支爬蟲疊加一層可以退出的偏好，後四家則是用兩支不同身分的爬蟲，分別處理搜尋與訓練。第一條門檻寫的是「robots.txt 或類似的標準」，這幾個字才是 Microsoft 今天也能站上 Accountable 名單的原因：它靠的是 NOARCHIVE。本文接下來聚焦門檻一與門檻四，因為蒐集到的材料裡，七家在門檻二（AI 摘要退出）與門檻三（URL 層級可見度）的逐家實作細節都不完整——門檻二目前要直接找操作者處理，Cloudflare 說明年會多一條透過自己操作的路徑，但那條路徑今天還不存在。
9 月 15 日這天，Cloudflare 自己的 Bot Management 與 AI Crawl Control 產品也跟著動了一輪：原本的 Block、Block on pages with ads 設定過去不涵蓋 mixed-use 爬蟲的行為細節，這天起開始套用到 Applebot、Bingbot、Googlebot 這三支被明確點名的爬蟲；舊的二元開關「Block AI Bots」被更細的 Search、Training、Agent 三種控制取代，Cloudflare 的原話是「Block AI Bots will be deprecated in favor of the more granular Search, Training, and Agent controls」；原本管理 robots.txt 的 Managed Robots.txt 功能，也改名為 Bot Preference Sync。Cloudflare 的原話是「customers onboarding a new domain will be offered one of two preset configurations」——新網域上線時，某些情境下 Disallow AI Training 會被直接放進推薦設定，不用站方自己翻找開關。今天寫進 robots.txt 的那條規則，背後是 Cloudflare 重寫了一整組既有產品的行為。
已經打開舊版「Block AI Bots」的網站，這次淘汰保留了原本的意圖。Cloudflare 說得很具體：「Nothing, in almost every case. Your current settings carry over on their own.」，而且公布了明確的新舊對照——「Previous Training selections of Block or Block on pages with ads will migrate to Disallow AI Training」，等於是把舊的二元開關直接映射到新的 Disallow AI Training 選項上，不需要站方手動搬家。
前三家的機制具體長什麼樣子，可以自己動手試：選一家廠商，切換要不要在 robots.txt 寫入 Disallow AI Training 的偏好，看搜尋與訓練兩欄各自怎麼變。
選廠商、切換 robots.txt 偏好，看搜尋與訓練狀態怎麼變 · 3 家爬蟲
搜尋這一列，三家、開關開或關，狀態都不變——真正會動的只有訓練那一列
Google、Apple 開關一開，訓練被擋、搜尋不受影響；同一顆開關對 Microsoft 目前沒反應，要等 2027 年初。
上面這個模擬器只涵蓋前三家，因為只有它們是同一支爬蟲、靠 robots.txt 這層偏好分流；Google 和 Apple 打開開關之後，訓練確實被擋下來，搜尋的狀態列完全不動。換到 Microsoft，同一個動作看起來一樣，結果卻不一樣——這正是後面要細看的地方。
Google 與 Apple：token 寫進 robots.txt，搜尋照樣收錄
Google 自己的開發者文件說得很白：Google-Extended「doesn't have a separate HTTP request user agent string」，抓取用的還是 Googlebot 既有的 user agent，robots.txt 裡的 Google-Extended 這個 token 只是「used in a control capacity」——它不決定抓不抓，只決定抓回來的內容能不能被拿去訓練未來的 Gemini 模型。官方範例長這樣：
user-agent: Google-Extended
allow: /archive/1Q84
disallow: /archive/搜尋這一端完全不受影響，Google 自己寫的是「Google-Extended does not impact a site's inclusion in Google Search nor is it used as a ranking signal in Google Search」。
Google 官方文件把用途寫得比 Cloudflare 的分類更具體——不是泛稱的 training，是「training future generations of Gemini models」。這個差異提醒一件事：Disallow AI Training 這顆開關擋下來的，是抓取內容進入模型訓練這個環節本身，跟 Gemini 產品本身要不要引用內容做即時摘要，其實是兩回事，後者屬於 Accountable 門檻二管的 AI 摘要退出，機制完全不同。
Apple 的說法在機制上幾乎一樣，用詞卻不太一樣。Apple 官方支援文件把 Applebot-Extended 稱作「a secondary user agent」，但接著解釋「Applebot-Extended does not crawl webpages」——它一樣不實際發送請求，只決定 Applebot 已經抓到的資料「how to use the data crawled by the Applebot user agent」。官方給的 robots.txt 範例示範的是封鎖單一子路徑，不是整站：
User-agent: Applebot-Extended
Disallow: /private/搜尋端的保證是「Site rules for Applebot-Extended are not considered in ranking for Search」，甚至延伸到 Spotlight、Siri、Safari——退出訓練，這幾個介面也不受影響。
兩份官方範例本身也值得多看一眼，兩份都不是整站封鎖。Google 的範例示範的是更細的組合——在 /archive/ 底下先用 allow 開一個例外路徑 /archive/1Q84，再用 disallow 擋掉整個 /archive/，等於是「一個目錄裡大部分不給訓練用，但留一個特定頁面例外」；Apple 的範例只有一行 disallow，封鎖 /private/ 底下的內容，不需要額外的 allow 例外。兩家官方文件都沒有示範整站封鎖要怎麼寫，站方如果想做到那個效果，得自己把 Disallow 的值換成整站的斜線。維運 robots.txt 的工程師，實際工作量不大——加兩行文字，設定就算完成，真正要跟團隊裡負責法務或內容授權的人解釋清楚的，是這兩行文字的性質：一份對外公開的聲明，效力完全取決於 Google、Apple 願不願意讀它、信不信任它。能主張權利的依據，是官方文件裡白紙黑字的搜尋條款。
兩家的用詞不完全一樣——Google 說自己「沒有獨立 user agent」，Apple 說自己「有一個 secondary user agent，但不實際抓取」——機制上其實是同一件事：多一個 robots.txt token，不多一次網路請求。這個「不多一次請求」的細節很重要，因為它同時是保證的來源，也是弱點的來源：保證是因為根本沒有第二支爬蟲要單獨攔截；弱點是因為站方永遠沒辦法在網路層驗證對方是不是真的照著這個 token 做，只能相信對方公開的文件。
Microsoft：先靠 NOARCHIVE 過關，robots.txt 要等 2027
Microsoft 也在 Cloudflare 認定的 Accountable 名單裡，用的卻是第三種機制。Cloudflare 的說法是「Site owners can currently express AI training preferences through Bing's NOARCHIVE meta tag」——這是頁面層級的 HTML meta 標籤，意味著要逐頁加，沒有一次寫進 robots.txt 就整站生效的選項；對頁面數量龐大的網站，逐頁維護就是實際的工程負擔；合理的推測是，這也是 Microsoft 表示要把偏好搬到 robots.txt 層級的原因之一。搜尋端的保證跟另外兩家一樣：用 NOARCHIVE「will not impact search ranking」。
驗證 Microsoft 有沒有遵守，比驗證 Google、Apple 更繁瑣。Google、Apple 的 robots.txt 規則是網域層級，站方要檢查的地方只有一個檔案；NOARCHIVE 是逐頁的標籤，要確認每一頁都正確生效，理論上得逐頁抽查，這比檢查單一檔案要花更多力氣。這段驗證成本，正是 Cloudflare 把 Managed Robots.txt 改成 Bot Preference Sync 想解決的部分——把偏好集中管理，至少讓站方不用在 Cloudflare 後台跟自己網站的頁面模板之間來回核對。
robots.txt 層級的版本還在路上。Cloudflare 引述 Microsoft 的說法是目前「currently building the mechanism to also respect a 'no training' preference in robots.txt at the domain/site level, targeted for early 2027」——「targeted for」這個用詞本身就是個 hedge，這個日期是目標，不是承諾。從今天到那個目標之間，Bingbot 是三家裡唯一一個，同一顆「Disallow AI Training」開關寫進 robots.txt 也不會有任何反應的。
這也是為什麼 Bingbot 這段空窗期特別尷尬。Cloudflare 的 Block 設定現在會套用到 mixed-use 爬蟲，如果站方想徹底擋掉 Bingbot 的訓練用途，用 Block 整支擋掉是目前唯一的網路層手段——但 Bingbot 同時也是 Bing 搜尋的索引來源，整支擋掉會連搜尋收錄一起犧牲。對 Google 和 Apple，這個兩難已經被 robots.txt token 解開了；對 Microsoft，今天要嘛忍受訓練持續蒐集，要嘛犧牲 Bing 搜尋——這正是全篇一開始講的 mixed-use 問題，Bingbot 至今還沒走出來。
拖動手把看不同時間點的狀態 · 2026-09 到 2027-03
拖到 2027 年初那個標記可以看到，Microsoft 屆時要做的事，其實就是把 Google、Apple 已經做完的事再做一次。
Amazon、Anthropic、Meta、OpenAI：架構本身就分好了
第四種路線完全不靠 robots.txt 裡的 token。Cloudflare 的說法是「These organizations separate their Search and Training crawlers, so Cloudflare can block the Training crawler without affecting search」——Amazon、Anthropic、Meta、OpenAI 各自跑兩支不同身分的爬蟲，一支負責搜尋，一支負責訓練，兩者在網路層就是可以分辨的兩個實體。要擋訓練，不需要新增任何 robots.txt 規則，Cloudflare（或任何懂得辨識這兩支爬蟲身分的防火牆）直接擋掉訓練那支的流量就夠了。
這跟 Google、Apple、Microsoft 的差別，在於保證從哪裡來。Google 和 Apple 的保證來自對方文件裡白紙黑字的承諾，前提是對方確實遵守自己在 robots.txt 裡讀到的偏好；Amazon、Anthropic、Meta、OpenAI 的保證來自架構本身——兩支爬蟲是分開的兩個身分，攔截這件事直接發生在網路層。把七家攤開來看，真正的差異在爬蟲身分的數量。
這個差異在驗證上會落成完全不一樣的體驗。要確認 Google 或 Apple 有沒有遵守，站方唯一能做的是等——等一段時間後觀察訓練用途的蒐集是否真的停止，或是等對方依 Accountable 門檻三公布 URL 層級的指標，才有間接的證據可看。驗證 Amazon、Anthropic、Meta、OpenAI 這條路線不一樣：防火牆的攔截紀錄本身就是證據，擋掉的流量是不是真的來自 Training 爬蟲的身分，是可以直接稽核的網路層事實。
分離四家的架構保證也有一個前提：Cloudflare 必須正確辨識出哪些流量屬於 Training 爬蟲、哪些屬於 Search 爬蟲。如果辨識出錯，把 Search 流量誤判成 Training 擋掉，一樣會傷到搜尋收錄，這個風險的來源從「對方遵不遵守」換成了「分類辨識準不準」。
七家的爬蟲身分數量
點任一列看細節
Google 的保證來自 robots.txt 這一層宣告，前提是 Google 自己遵守。
Apple 的保證同樣來自宣告，範例示範的是子路徑封鎖，不是整站。
Microsoft 的 robots.txt 版本還沒上線，今天只能靠逐頁的 NOARCHIVE。
分離四家的保證不靠宣告，靠的是兩支爬蟲在網路層是可以分辨的兩個身分。
mixed-use 陣營——Google · Apple · Microsoft
- 門檻一：退出訓練的機制
- robots.txt token（Google-Extended、Applebot-Extended），或 Microsoft 目前的 NOARCHIVE meta tag。
- 門檻四：搜尋是否受影響
- Google、Apple 官方文件都給了明確保證；Microsoft 的保證目前只看得到 Cloudflare 引述的說法，不是 Microsoft 自己的文件；三者的前提都是對方確實讀取並遵守這個宣告。
分離爬蟲陣營——Amazon · Anthropic · Meta · OpenAI
- 門檻一：退出訓練的機制
- 不需要新 token——Training 爬蟲是獨立身分，防火牆直接攔截即可。
- 門檻四：搜尋是否受影響
- 保證來自架構本身，兩支爬蟲是分開的，不依賴對方讀取任何宣告。
兩條路殊途同歸，付出的代價卻不一樣——一條路要相信對方的 robots.txt 解讀器，一條路要相信防火牆辨識爬蟲身分的準確度。重要的是搞清楚自己網站前面擋的是哪一種爬蟲、能打開的是哪一種開關。
站長今天能打開哪些開關
如果內容前面掛的是 Cloudflare，新的 Disallow AI Training 設定今天就能用——對 Google 和 Apple 立刻生效，退出訓練，搜尋收錄不受影響，這是兩家官方文件白紙黑字的保證。同一個開關對 Amazon、Anthropic、Meta、OpenAI 的訓練爬蟲同樣有效，因為 Cloudflare 能直接辨識並攔截那支獨立的訓練爬蟲。
唯一還沒補齊的是 Microsoft。今天寫進 robots.txt 的偏好，Bingbot 目前不會有反應；要退出訓練，只能回頭用頁面層級的 NOARCHIVE，逐頁維護，直到 2027 年初那個「targeted」的日期真的兌現。這段空窗期，是 Microsoft 自己承認還沒做完的部分。
更根本的一點是：不管是哪一家，這整套機制的本質是發布偏好。robots.txt 的 Disallow，或是防火牆辨識到的爬蟲身分，站長能做的只有把偏好講清楚——真正照不照辦，決定權在對方。
如果對方選擇不遵守，會發生什麼事？合理的推測是，技術層面上不會發生任何事——robots.txt 是公開文件，任何爬蟲都可以讀取也可以忽略，本文查到的材料裡沒有任何一家提到強制執行的機制；Cloudflare 的防火牆攔截同樣只對它辨識出來的爬蟲身分有效，一支偽裝成瀏覽器、不表明身分的爬蟲理論上可以繞過整套系統。真正給這套機制份量的，是 Google、Apple、Microsoft 這種規模的公司公開發布的官方保證——文件白紙黑字寫了「不影響搜尋排名」，之後如果被抓到說一套做一套，付出的會是商譽代價。這也是為什麼 Accountable 門檻三的 URL 層級可見度重要：它把「有沒有遵守」從單方面的信任問題，變成有數字可以核對的問題。
設定 Cloudflare 帳號時，具體的檢查清單並不長：先看 AI Crawl Control 裡的爬蟲分類，確認站上出現的是 Search、Training 還是 Agent 流量；再看 Disallow AI Training 這個開關有沒有打開；最後回頭看 robots.txt 的實際內容，確認 Google-Extended、Applebot-Extended 這兩行有沒有正確寫進去，也順便看一眼帳號介面裡是不是還留著「Managed Robots.txt」這個已經淘汰的舊名稱。三件事都做完，才算是把今天能拿到的保證真正兌現。
The call：今天就能打開的開關，是 Google、Apple 的 robots.txt token，以及對 Amazon、Anthropic、Meta、OpenAI 訓練爬蟲的直接攔截；Microsoft 要等 2027 年初，這段時間只能靠頁面層級的 NOARCHIVE 頂著——而不管打開哪一顆開關，能不能生效，最後都要看對方爬蟲願不願意遵守。