首頁 / 技術文章 / AI 爬蟲爬取對引薦比怎麼算：站主用自家數據重算的四步驟判讀流程

技術文章

AI 爬蟲爬取對引薦比怎麼算：站主用自家數據重算的四步驟判讀流程

要算出不誤導的爬取對引薦比，分子應該用成功取得內容的請求，分母要標註 Referer 缺失可能造成的低估，訓練用和搜尋用爬蟲要分開算，最後附上統計期間與口徑。直接拿總請求除以總引薦，分子和分母兩邊的誤差會同時把比例放大。下面整理一套站主可以照做的計算規格，也說明這個比例量不到什麼。

發布 2026-10-24更新 2026-10-24topcc.me 編輯部

爬取對引薦比是什麼：Cloudflare 定義的指標，不是標準規格

爬取對引薦比（crawl-to-refer ratio）是 Cloudflare 在 Radar 的 AI Insights 頁面公開的指標，用來比較某個 AI 平台爬取網站的頻率，和它實際把使用者導回網站的頻率。依 Cloudflare 官方部落格的說明，計算方式是某平台爬蟲的 HTML 請求數除以該平台帶來的引薦請求數。Cloudflare 的結論是：和 AI 機器人抓取網站的頻率相比，真正點進網站的使用者非常少。

這個指標由單一廠商提出、維護，不是標準組織制定的規格。相較之下，規範 robots.txt 的 RFC 9309 是 IETF 在 2022 年 9 月發布的 Standards Track 文件，延伸了 Martijn Koster 在 1994 年提出的方法。爬取對引薦比沒有這種共同定義，所以「HTML 請求怎麼算、引薦怎麼認定、時間窗多長」都由各方自己決定。這正是數字常常對不上的原因。

指標的意義在於搜尋生態的交換關係變了。搜尋爬蟲抓取內容後會用連結換回流量，所以請求量大通常代表曝光多。AI 爬取以訓練為主，回答又多半在 AI 介面裡完成，請求量和回流就脫鉤了。本站認為，判讀重點因此要從「被抓了多少」轉成「抓取和回流的比例」，前提是這個比例算得對。

為什麼直接相除會失真：分子偏大、分母偏小

Search Engine Journal 整理了約 13 個月內被歸於 Cloudflare 的 Anthropic 爬取對引薦比，報導中出現過 70,900:1、38,000:1、23,951:1、11,122:1、10,300:1、4,580:1、2,237:1。其中兩個數字宣稱是同一個月份，彼此卻差了約 17 倍。該文的判斷是：「Nobody lied, and that is the part worth understanding.」同一個指標、同一個發布者，只要口徑和時間窗不同，數字就能差到約 30 倍。

全網數字已經這麼不穩定，站主自己算時又多了兩個方向的偏差。分子如果直接用總請求，會把被擋下、出錯、沒有拿到內容的請求也算進去，平台實際取得的內容量就被高估了。分母依賴 Referer 等訊號，不帶 Referer 的導流根本不會被計入，引薦量就被低估了。分子偏大、分母偏小，兩個誤差疊在一起，比例只會往上偏。

四步驟判讀流程

步驟一：分子只算成功取得內容的請求

Cloudflare AI Crawl Control 的 Overview 分頁把請求分成總請求數、允許的請求數（allowed）和未成功的請求數（unsuccessful）。分子應該用 allowed，不用總請求。本站的判斷是：unsuccessful 請求代表爬蟲這次沒有取走內容，把它算進「爬取」，等於把被擋在門外的次數也算成平台拿走的內容。如果用伺服器紀錄自己算，對應做法是只算回應 2xx 的 HTML 頁面請求，並排除靜態資源與 robots.txt。

另外要注意，User-Agent 可以偽造。正式列入分子之前，最好先做爬蟲身分驗證。如果網站前面有 CDN，邊緣和源站看到的請求數也不一樣，兩層日誌要先對帳，才知道分子取自哪一層。

步驟二：在分母旁標註「Referer 缺失、可能低估」

Cloudflare 在後續文章中提到，原生 App 不帶 Referer 標頭，會讓比例被高估。目前沒有來源能量化低估多少，所以合理的做法是不要自己猜一個修正係數，而是在分母旁固定加上註記。

伺服器紀錄裡有幾個訊號可以輔助判斷低估程度，但都只是旁證，不能直接換算成引薦數：沒有 Referer、直接落在深層內容頁的人類工作階段；某頁被 AI 爬蟲抓取後，同一頁的無來源流量是否跟著出現波動；連結上附帶的查詢參數。這些訊號只能說明分母大概偏小，不能用來改寫分母。

步驟三：訓練用與搜尋／檢索用爬蟲分開算

Cloudflare 指出，到 2025 年年中，訓練用途約占 AI 爬取的近 80%。本站的推論是：訓練爬蟲依設計本來就不是為了帶回點擊，它的比例偏高幾乎是必然的。把它和搜尋或即時檢索爬蟲合併成一個數字，會讓「預期中不導流」和「應該導流卻沒導流」混在一起，數字看不出意義。

AI Crawl Control 是依營運者（OpenAI、Microsoft、Google、ByteDance、Anthropic、Meta）分組顯示，不是依用途分組。同一家營運者可能同時有多支用途不同的爬蟲，站主要依各營運者公開的用途說明，自己把 User-Agent 拆成訓練組和檢索組。有些爬蟲沒辦法乾淨拆開：Search Engine Journal 轉述 Cloudflare 的說法，Googlebot 同時為搜尋索引和 AI 訓練爬取內容，封鎖其訓練用途可能影響搜尋可見度。這類爬蟲建議單獨列一組，不要硬歸到任何一邊。用途和 robots.txt 的對應做法，可以參考允許 AI 搜尋、封鎖訓練的設定與限制。

步驟四：每個比例都附上期間、資料層級與口徑

既然同一平台的數字可以差到數十倍，沒有附上條件的比例就無法比較。建議內部報告和對外引用都使用固定格式：

爬取對引薦比：［數值］:1
平台／爬蟲：［營運者名稱］／［User-Agent］
用途分組：［訓練｜搜尋／檢索｜混合用途］
統計期間：［YYYY-MM-DD］至［YYYY-MM-DD］（時區：Asia/Taipei）
資料層級：［單站：example.com｜全網：Cloudflare Radar］
分子口徑：［AI Crawl Control allowed 請求｜伺服器紀錄 2xx HTML 請求，已排除靜態資源］
分母口徑：［AI Crawl Control 總引薦數｜Referer 符合平台網域的請求］
分母註記：Referer 缺失的導流未計入，比例可能高估
身分驗證：［已驗證 IP／DNS｜僅依 User-Agent］
資料取自：［CDN 邊緣｜源站］

免費方案：改用伺服器紀錄自行計算

AI Crawl Control 的總引薦數只有付費方案才看得到。免費方案的站主在同一個介面只看得到請求面，看不到引薦面，必須自己從伺服器紀錄計算。以下指令稿適用 Nginx／Apache 的 combined 日誌格式，每次只算一支爬蟲和一個引薦網域，正好符合步驟三的分組原則：

#!/usr/bin/env bash
# 用法：./crawl_refer.sh access.log "ExampleBot" "example.com"
# 參數：日誌檔、爬蟲 User-Agent 樣式、AI 平台引薦網域樣式
# 假設日誌為 Nginx / Apache combined 格式
set -euo pipefail
LOG="$1"
UA_PATTERN="$2"
REF_PATTERN="$3"

# 分子：指定爬蟲、回應 2xx、排除靜態資源與 robots.txt
crawl=$(awk -F'"' -v ua="$UA_PATTERN" '
  $6 ~ ua {
    split($3, s, " ")
    split($2, r, " ")
    if (s[1] ~ /^2/ && r[2] !~ /\.(css|js|png|jpe?g|gif|svg|webp|ico|woff2?|xml|txt)(\?|$)/) n++
  }
  END { print n+0 }' "$LOG")

# 分母：Referer 符合平台網域、回應 2xx 的請求
refer=$(awk -F'"' -v ref="$REF_PATTERN" '
  $4 ~ ref {
    split($3, s, " ")
    if (s[1] ~ /^2/) n++
  }
  END { print n+0 }' "$LOG")

echo "成功爬取請求（2xx、排除靜態資源）：$crawl"
echo "可歸因引薦（Referer 符合 $REF_PATTERN）：$refer"
if [ "$refer" -eq 0 ]; then
  echo "比例：無法計算（分母為 0；Referer 可能缺失，不代表零導流）"
else
  awk -v c="$crawl" -v r="$refer" 'BEGIN { printf "比例：%.1f : 1（分母可能低估）\n", c / r }'
fi

這個指令稿只依 User-Agent 和 Referer 字串比對，沒有做身分驗證，也看不到 CDN 邊緣直接回應、沒有回源的請求。輸出結果要套用上一節的引用格式，並在「身分驗證」和「資料取自」兩欄如實填寫。

三種常被混用的指標

新聞裡的爬蟲排名常被拿來和爬取對引薦比並列，但兩者量的東西不同。Search Engine Journal 報導的 Cloudflare Year in Review，統計範圍是 2025 年 10–11 月的成功 HTML 請求，指標是觸及樣本中不重複網頁的比例：Googlebot 11.6%、GPTBot 3.6%、Bingbot 2.6%，Meta-ExternalAgent 和 ClaudeBot 各 2.4%，PerplexityBot 0.06%。這是「覆蓋範圍」，不是請求數，也不是回流比例。

適用範圍與限制

就算照四步驟算，這個比例還是有幾個量不到的地方。第一，內容被拿去訓練，或在 AI 回答中被引用卻沒有帶來點擊，這部分的品牌曝光價值不會出現在比例裡，目前也沒有來源提出量化方法。第二，單站比例和 Radar 全網彙總值之間落差有多大，現有來源沒有說明，所以不能拿自己網站的數字去驗證或推翻 Radar。第三，比例只描述現況，不會告訴你封鎖之後會失去什麼。

商業面上，Cloudflare 指出，對新聞網站來說，大量機器人請求伴隨的是更少真實讀者點擊，也就是更少廣告點擊和訂閱轉換機會。這讓比例對出版者特別敏感。但本站認為，比例偏高的爬蟲是否該封鎖是策略判斷，需要一起考量爬蟲用途、搜尋可見度、AI 回答中的引用機會，以及分母低估的程度。至於 robots.txt 能不能控制抓取頻率，RFC 9309 的範圍是存取控制、錯誤處理和快取，本文依據的資料無法支持「可以用 robots.txt 限制頻率」的說法，需要另外查核一手原文。

常見誤解

誤解一：某平台的比例是固定、權威的數字。同一平台在約 13 個月內被報導過從 2,237:1 到 70,900:1 的數字，而且全部歸於 Cloudflare。沒有期間和口徑的比例不能引用。
誤解二：比例高就代表平台完全沒帶回讀者。不帶 Referer 的導流不會被計入分母，比例偏高不等於零導流。
誤解三：爬蟲排名可以直接和比例比較。觸及不重複網頁比例和以請求數為分子的比例是兩種指標。
誤解四：Radar 的全網比例可以代表自己的網站。全網彙總值和單站數字的落差目前沒有可靠說明，自己的網站要用自己的數據算。

判斷：比例要拿來比較，不是拿來下結論

爬取對引薦比最有用的情境，是在同一網站、同一口徑、同一用途分組下比較不同期間的變化，或在同一期間比較不同爬蟲的差異，而不是拿一個數字判斷某平台「只拿不給」。站主接下來該留意三個訊號：檢索類爬蟲的比例在固定口徑下是否持續惡化；無 Referer 的深層頁流量是否隨 AI 抓取同步變動；以及 AI 平台是否開始提供可歸因的導流標記，讓分母的低估縮小。在這些訊號明朗之前，封鎖決策應該以用途分組後的比例為準，並把分母低估寫進每一份報告。

常見問題

免費方案的 Cloudflare 使用者能在 AI Crawl Control 看到爬取對引薦比嗎？

不能直接看到。AI Crawl Control 的總引薦數只限付費方案，免費方案要從伺服器紀錄自己計算：分子算指定爬蟲的 2xx HTML 請求，分母算 Referer 符合該 AI 平台網域的請求。

分子為什麼要用 allowed 請求，不用總請求？

總請求包含未成功的請求，這些請求並沒有取得內容。把它們算進分子，會高估平台實際拿走的內容量，讓比例偏高。

比例很高，是不是就該封鎖那支爬蟲？

不一定。先確認它是訓練用還是搜尋／檢索用，再考慮 Referer 缺失造成的分母低估、在 AI 回答中被引用的機會，以及像 Googlebot 這類同時服務搜尋與訓練的爬蟲對搜尋可見度的影響。

新聞裡 Anthropic 的比例為什麼每篇都不一樣？

各篇報導採用的統計期間和計算口徑不同。Search Engine Journal 整理出約 13 個月內從 2,237:1 到 70,900:1 的數字，全部歸於 Cloudflare，差異來自口徑，不是造假。