如何管理 AI 爬蟲流量：看懂 Cloudflare 爬蟲信任評等

通過身分驗證的 AI 爬蟲，就能放心放行嗎？網站營運者還要追問：它之後是否遵守網站設定、收到限速要求後有沒有降低請求。Cloudflare 於 2026 年 10 月公布 Verified Bot 信任評估，將觀察身分確認後的持續行為，並表示未來計畫在 Radar 公開評等。現階段，這項評等仍不等於所有網站都能直接使用的管理功能；網站可以先釐清自己的規則、回應方式與流量紀錄。

爬蟲有身分，為什麼還需要信任評估？

身分驗證只能回答爬蟲由誰營運或它如何表明身分，持續行為觀察才會呈現它有沒有遵守網站規則。 網站應把「辨識對象」和「決定如何處理請求」分成兩個判斷。

Cloudflare 的 Verified Bot 概念包含兩類條件：爬蟲需要以可驗證方式表明身分，也要遵守網站的 robots.txt 與抓取指示、維持合理請求頻率，且沒有已知的規避控制或攻擊行為。10 月公布的信任評估把第二類行為往時間軸延伸，觀察爬蟲是否長期依照網站偏好行動。這是產品方對自身方法的說明，並非第三方稽核結果。

這個區分很重要。請求帶有已知機器人的身分，不會自動代表每一個請求都適合放行；同一個爬蟲也可能因設定錯誤、程式缺陷或流量暴增而影響來源網站。判斷時若只看名稱、User-Agent 或驗證標記，營運者仍不知道它會抓哪些路徑、頻率多高，以及遇到網站限制後會怎麼做。

Cloudflare 在公告中將「風險」描述為特定請求或某一時點行為可能造成的傷害，將「信任」描述為長時間反覆呈現的一致行為。這表示信任評估試圖濃縮過去觀察到的行為模式，不是對未來每次請求的承諾，也不會取代網站自行設定的存取控制。網站仍須先決定哪些內容允許抓取、哪些流量需要限制，並確認決策由哪個系統執行。

「Verify, but continuously re-verify.」Cloudflare 以此概括其 Verified Bot 的持續問責方向，中文可理解為身分需要驗證，行為也要持續重新確認。出自 Cloudflare〈Continuous accountability for Verified bots〉。

身分驗證回答「它是誰」

身分驗證的功能，是讓網站或中介服務有依據地辨認機器人。Cloudflare 文件列出的驗證方式包括加密簽章、發布的 IP 清單搭配穩定 User-Agent，或反向 DNS 等。辨識方式各有條件，網站是否能取得並使用這些資訊，還要看所在網路架構、CDN 或防火牆的支援情況。

身分資料有助於把已知爬蟲和來源不明的自動請求區分開，也能減少只靠 User-Agent 字串判斷的盲點。然而，身分代表的是宣告者或營運者線索，不是該爬蟲已取得所有頁面授權的證明。網站仍需要獨立設定可讀取的路徑、可接受的請求頻率，以及何時拒絕或暫停存取。

長期行為回答「它是否遵守規則」

長期觀察將多次請求和網站回應放在一起看。若某爬蟲持續遵守限制，並在收到明確回饋後調整流量，觀察結果便能補足單次身分驗證提供的資訊；若它反覆忽略限制，則可能降低評估中的信任程度。Cloudflare 表示，其設計會呈現一個可解釋的信任區間，說明行為一致程度與參考的觀察訊號，避免把結果視為對爬蟲或營運者永久定罪。

不過，分數或區間仍是對資料的摘要。網站需要知道觀察涵蓋哪些流量、資料來自哪些網路、樣本是否足夠，以及回饋在什麼時間範圍內生效。若看不到這些脈絡，單獨拿一個評等做放行決策，容易把「曾有良好紀錄」誤讀為「此刻一定安全」。

Cloudflare 初期評估哪些爬蟲行為？

初期訊號聚焦在是否遵守網站指示，以及收到直接回饋後是否改變行為。 公告以 robots.txt 偏好和 HTTP 429 限流回應為例，沒有公布完整計分公式或所有輸入資料。

robots.txt 與網站偏好

robots.txt 是網站發布給爬蟲的路徑偏好檔案，可用 User-Agent 區分爬蟲，並以 Allow、Disallow 等規則表達哪些路徑可以或不希望被抓取。Cloudflare 表示，評估會觀察爬蟲的實際流量是否長期符合網站發布的偏好，並著重反覆忽略規則的模式，而非將個別一次性情況直接當成定論。

這份檔案有清楚的界線。IETF 的 RFC 9309 指出，Robots Exclusion Protocol 規則要求爬蟲遵循，但不構成存取授權。robots.txt 是溝通偏好的方式，不會驗證訪客身分，也不會阻擋不理會規則的程式。若頁面內容不應公開，網站必須使用登入驗證、權限檢查、網路層限制或其他存取控制保護，不能只把路徑列入 Disallow。

對營運者來說，先檢查檔案是否反映目前政策，比急著研究評等數值更實際。常見問題包括規則部署在錯誤網域、網站改版後路徑已變、正式站與測試站規則不同，或網站內部的爬蟲政策和 robots.txt 內容互相矛盾。規則表達得不一致，後續就難以區分爬蟲違規和網站設定錯誤。

收到 HTTP 429 後是否降速或暫停

HTTP 429 是「請求過多」回應碼。網站可用它告知用戶端需要降低請求速率，有時也會提供多久後再嘗試的提示。Cloudflare 說明，初期會觀察爬蟲收到這類直接訊號後，有沒有放慢速度、暫停，或仍以相同頻率持續請求；長期模式會納入信任評估。

這種回饋只有在網站端使用得一致，才容易解讀。若限流規則沒有說明觸發條件、不同伺服器回傳的等待資訊不一致，或爬蟲收到 429 後仍不停重試，營運者就要同時檢查自己的回應設計與對方的後續請求。不能看到一次 429 就假定流量已受到控制，也不能單靠狀態碼判定爬蟲的意圖。

RFC 6585 定義 HTTP 429「請求過多」狀態碼，RFC 9110 則說明一般 HTTP 語意。Cloudflare 的文章說明它如何把限流回應視為行為觀察訊號。這些 RFC 說明協定規範，沒有規定 Cloudflare 的評等機制或計分方式。

網站可以怎麼把指示與回饋納入流量治理？

先把規則、執行控制與請求紀錄串起來，再將外部信任評等當成輔助訊號。 評等無法替網站決定哪些資料應公開，也無法代替防火牆、驗證或限流政策。

先盤點允許、限制與封鎖規則

網站治理的起點是明確描述想要什麼結果。公開文章可允許哪些搜尋爬蟲存取？不希望哪些機器人抓取？特定 API 或登入後頁面需採用什麼權限？若某來源請求太密集，系統應回傳什麼狀態、多久後允許重試？這些問題要由網站管理者、資訊安全人員、內容負責人和服務供應商共同確認，不能只由一份 robots.txt 承擔所有政策。

接著要核對規則在哪一層實際執行。robots.txt 公開抓取偏好；網站伺服器、CDN 或 Web Application Firewall（網站應用程式防火牆）則能依 IP、路徑、流量特徵、身分或其他條件套用阻擋與限流。各層規則若互相覆蓋，管理者可能以為已封鎖，實際上請求仍到達來源伺服器。明確寫下每一層由誰維護，也有助於日後追查設定變更。

Cloudflare 在公告中提到，客戶現有的 Bot Management 可用於管理自動化流量，Bot Preference Sync 可協助對齊已發布的偏好與設定政策。這些是 Cloudflare 生態系中的產品能力，是否適用仍取決於方案、部署位置和組織現況；網站也可透過其他 CDN、防火牆或自建服務完成相近的規則管理。

對照爬蟲請求與限流後的變化

沒有前後紀錄，就很難判斷回饋是否有效。網站可保留時間、請求路徑、辨識到的機器人或來源、回應狀態、限制規則、重試間隔和後續頻率等必要欄位。紀錄用途是確認流量變化、排查錯誤和改善政策，保存範圍與時間則要依組織資安及隱私規範設定。

對照時可先看同一來源在收到限制前後的請求間隔、請求總量和被觸及的路徑，再核對 429 是否真的由預期規則產生。若流量沒有改變，原因可能在爬蟲忽略回饋，也可能是回應未抵達實際發出請求的程式、設定延遲或來源識別錯誤。這一步的目的在找出系統鏈上的原因，避免將所有異常都歸咎於機器人。

信任評等與存取控制各自負責什麼

工具或訊號	能協助回答	不能單獨做到
爬蟲身分驗證	請求來自哪個已知營運者或機器人	證明所有請求都合規或無害
robots.txt	網站公開表達哪些路徑可供爬取	阻止不遵守規則的爬蟲，或保護機密頁面
HTTP 429 與限流	告知用戶端請求過多、要求降低頻率	確認對方已收到訊息或已停止請求
請求紀錄	追查流量、回應與政策執行的前後變化	自動決定合理政策或辨識所有身分
信任評估	彙整一段時間觀察到的行為一致性	取代網站自身的權限、防護與風險判斷

這些措施各自處理不同層次。網站在政策上決定允許範圍，以技術控制落實規則，再以紀錄檢視控制是否生效。信任評等若能提供可理解的觀察脈絡，便可加入人工評估或流量政策的參考；若直接把評等當成通行證，網站就把自己的政策責任交給外部摘要。

• 身分驗證用來辨識機器人，不能代替網站的存取判斷。
• robots.txt 表達抓取偏好，頁面保護仍需登入、權限或網路控制。
• 429 之後要比對實際請求變化，確認限流回饋是否奏效。
• 信任評等適合作為額外觀察資訊，不能當成安全保證。

公開採用前還有哪些細節要確認？

Cloudflare 表示未來會在 Radar 公開信任分級並擴大觀察方式；公開呈現、計算方法、更新頻率、可用方案與實際採用時間，仍須依官方後續資訊確認。 RFC 文件只界定相關網路語意，不代表評等機制的產品規格。

評等公開方式、適用範圍與更新節奏

Cloudflare 的公告說明了評估方向與初期訊號，也提到未來在 Radar 分享分數並擴充衡量方式，但沒有交代完整的計算公式、觀察期間、最低樣本、資料來源、更新節奏或申訴流程。公告發布日的說法也不是使用資格公告。實際採用之前，網站需要確認正式上線範圍、免費或付費方案差異、是否提供 API 或可供自動化政策使用的欄位，以及變更通知方式。

這些細節會影響信任訊號的用途。若結果只提供公開趨勢，營運者可能只適合用來理解爬蟲生態；若能在網站控制台或 API 中取得、並能和自家請求對應，才可能進一步納入治理流程。即使資料可用，仍須知道分級如何處理新出現的機器人、短期故障、版本更新與大量使用者共用的代理服務。

觀察訊號的限制與網站自身責任

Cloudflare 信任評估依賴其可觀察到的流量與資料，不必然等同每一家網站能看到的完整請求。網站還要考慮流量是否經由代理、快取或其他 CDN，該爬蟲實際抓取內容的範圍，以及自己是否能以穩定方式識別機器人。信任區間提供的是特定訊號的整理，不能替代網站對內容授權、隱私、服務負載和安全風險的評估。

IETF 的 RFC 9309 定義 robots.txt 的語法與爬蟲應遵循的規則，RFC 6585 定義 HTTP 429，RFC 9110 說明一般 HTTP 語意。這些 RFC 可以支撐對「網站如何表達偏好」和「429 代表什麼」的說明，卻沒有規範 Cloudflare 對機器人的信任評分方式。Cloudflare 自身的公告應視為產品方對其機制的描述，不應延伸成獨立驗證、產業共同標準或安全認證。

「These rules are not a form of access authorization.」RFC 9309 以此界定 robots.txt 的邊界：抓取規則不是存取授權。網站若要保護內容，仍須在實際存取路徑上執行權限與安全控制。

網站營運者現在可以先做哪些準備？

先確認 robots.txt 表達正確、限流回應一致，並能從請求紀錄看出爬蟲收到限制後的行為。 這些工作可以獨立改善既有治理，將來也更容易判斷外部評等是否有助於自己的決策。

建立爬蟲身分、規則與請求紀錄的檢查清單

1. 整理政策。 列出網站希望允許、限制及禁止的爬蟲類型與路徑。
2. 核對規則。 確認 robots.txt、伺服器權限、CDN 和防火牆規則彼此沒有衝突。
3. 核對身分。 確認目前用哪些方式辨識自動化流量，哪些訊號可驗證、哪些只是請求自我宣告，並記錄無法辨識或代理來源的限制。
4. 檢查回饋。 針對流量門檻設定清楚的 429 回應與重試提示，確認記錄中看得到回應產生的時間與套用規則。
5. 比對前後行為。 以同一來源的請求紀錄觀察收到 429 前後的頻率與路徑變化，若未降速，先釐清回應是否到達對方及限流控制是否生效。
6. 設定採用條件。 等 Cloudflare 公開評等的呈現方式與適用條件後，再評估資料是否能對應網站流量、解釋是否足夠，以及哪些決策仍需由網站自行執行。

盤點不必等 Cloudflare 公布評等才開始。先確認網站要保護什麼、哪個元件負責執行規則，以及哪些資料可以證明規則有效；取得公開分級後，再以觀察模式對照自家紀錄，評估是否納入放行或封鎖流程。

常見問題

Cloudflare 公告表示未來計畫在 Radar 公開評等，公告未列出正式開放時間、採用資格或完整計分方法。 採用條件應以後續官方資訊為準。

Q1: Cloudflare 爬蟲信任評等現在已經公開開放了嗎？

Cloudflare 在 2026 年 10 月 16 日的公告說明評估方向，並表示未來會在 Radar 分享評等。該公告未列出公開日期、可用方案與網站端採用方式，因此不能將它視為已全面開放的功能。

Q2: robots.txt 能阻止 AI 爬蟲讀取網站內容嗎？

不能。robots.txt 用來公布網站對爬蟲的抓取偏好，RFC 9309 明確指出規則不構成存取授權。保護非公開內容要透過身分驗證、權限控管或網路存取限制。

Q3: 收到 HTTP 429 後，爬蟲一定會降速嗎？

不一定。429 表示請求過多，可要求用戶端降低頻率；網站仍需從後續請求紀錄確認對方是否放慢、暫停或繼續請求，也要檢查回應與限流規則是否正確送出。

Q4: 信任評等可以代替網站的資安工具嗎？

不可以。信任評估整理特定時間內觀察到的行為訊號，網站仍須自行設定權限、限流、封鎖與資料保護措施，並判斷外部評等能否對應自身流量。

Q5: RFC 9309 或 RFC 9110 是否規定 Cloudflare 評分方式？

沒有。RFC 9309 說明 robots.txt 的抓取規則及其授權界線，RFC 6585 定義 HTTP 429，RFC 9110 說明一般 HTTP 語意。Cloudflare 的分級邏輯、計算與公開方式需依其官方產品資訊確認。