內容發佈者歡迎來自搜尋引擎的網路爬蟲和機器人,因為它們有助於增加網站流量。網路爬蟲會看到網站上發佈的內容,並將該內容呈現給搜尋該內容的使用者。網站擁有者可以透過自己的網站內容獲利,因為這些使用者仍然需要點擊進入頁面才能存取短標題以外的任何內容。
人工智慧 (AI) 機器人也會爬行網站的內容,但採用完全不同的傳遞模型。這些大型語言模型 (LLM) 會盡力讀取 Web 內容,從而訓練一個系統,使其能夠為使用者重新包裝內容,而無需使用者存取原始出版物。
AI 應用程式可能仍會嘗試引用內容,但我們發現,相對於 AI 機器人抓取特定網站的頻率而言,真正點擊的使用者非常少。我們曾在小規模的討論中探討過這一挑戰,而今天,我們非常高興地宣佈,我們已將這些發現結果發佈在 Cloudflare Radar 上的「AI 深入解析」頁面中,作為一項新指標呈現。
Cloudflare Radar 的訪客現在可以查看特定 AI 模型向網站傳送流量的頻率與其爬行該網站之頻率之間的關係。我們將與廣大受眾分享此分析結果,以便網站擁有者能夠獲得更完善的資訊,幫助他們決定允許或封鎖哪些 AI 機器人,並幫助使用者瞭解 AI 使用情況對網際網路流量的整體影響。
這種衡量如何運作?
由於對於這些網路爬蟲來說,HTML 頁面是最有價值的內容,因此顯示的比率計算方法如下︰將與指定搜尋或 AI 平台關聯且回應為 Content-type: text/html
的相關使用者代理程式的請求總數,除以其 Referer
標頭包含與指定搜尋或 AI 平台關聯的主機名稱的 HTML 內容的請求總數。
下面的兩個圖表展示了兩種常見的爬行場景,並表明公司可能會根據網路爬蟲的用途使用不同的使用者代理程式。上圖表示一個簡單的交易,其中範例 AI 平台正在要求內容以訓練 LLM,並將自身表示為 AIBot
。下圖表示範例 AI 平台正在要求內容以服務使用者請求——尋找航班資訊。在本例中,它將自身表示為 AIBot-User
。為了便於分析,這兩個使用者代理程式的請求流量將匯總到同一個平台名稱下。
當使用者點擊網站或應用程式上的連結時,用戶端通常會將 Referer:
標頭作為請求的一部分傳送到目標網站。在下圖中,範例 AI 平台回應使用者互動,傳回的內容中包含指向外部網站的連結。當使用者點擊連結時,會向內容提供者發出請求,該請求在 Referer:
標頭中包含 ai.example.com
,告知他們該請求流量來自何處。為了便於分析,我們將主機名稱與其各自的平台關聯起來。
觀察結果
檢閱比率
新指標以簡單表格的形式呈現,它將來自與給定平台關聯之網路爬蟲(使用者代理程式)的 HTML 頁面請求總數,與來自與給定平台關聯的主機名稱所引薦之用戶端的 HTML 頁面請求總數進行比較。計算得出的比率一律會標準化為單一轉介請求。
下表顯示,在 2025 年 6 月 19 日至 26 日,該比率高至 Anthropic 的 70,900:1,低至 Mistral 的 0.1:1。這意味著,Anthropic 的 AI 平台 Claude 每推薦一次 HTML 頁面,就會發出 71,000 次 HTML 頁面請求,而 Mistral 發出的引薦流量是爬行請求的 10 倍。(然而,Claude 原生應用程式引薦的流量不包含 Referer:
標頭,我們認為其他原生應用程式產生的流量也是如此。因此,由於引薦流量僅包含來自這些提供者的網頁端工具的流量,這些計算可能誇大了相應的比率,但具體誇大多少尚不清楚。)
當然,部分由於爬行模式的變化,這些比率會隨著時間的推移而變化。上表也顯示了與上一期間相比該比率的變化,其變化幅度從 DuckDuckGo 和 Yandex 的成長超過 6%,到 Google 的下降 19.4% 不等。Google 比率的週環比下降,與自 6 月 24 日開始觀察到的 GoogleBot
抓取流量下降有關,而 Yandex 比例的週環比成長,與自 6 月 21 日開始觀察到的 YandexBot
爬行活動的增加有關,如下圖所示。
Radar 的 Data Explorer 包含一個時間序列檢視,用於顯示這些比率隨時間的變化,例如下方的百度範例。時間序列資料也可透過 API 端點取得。
引薦流量的模式
您可以在關聯的 Data Explorer 檢視中查看底層活動的變化和趨勢,也可以透過 API 端點(時間序列、摘要)取得原始資料。請注意,引薦流量和爬行流量的份額均與圖表中包含的引薦來源和網路爬蟲組相關,而非 Cloudflare 整體流量。
例如,在下方以引薦來源為中心的檢視中,涵蓋了 2025 年 6 月的前四週,我們可以看到引薦流量主要來自搜尋平台 Google,資料呈現相當一致的晝夜變化模式。(google.*
項目涵蓋來自主 google.com 網站以及本地網站(例如 google.es 或 google.com.tw)的引薦流量。)由於使用推測規則推動預先擷取,來自 Google ASN (AS15169) 的引薦流量被明確排除在此處的分析之外,因為它不代表活躍使用者的內容使用情況。
其他搜尋平台的引薦請求份額也呈現出清晰的晝夜模式,不過其請求占比僅為 Google 所見的一小部分。
整個六月期間,即便將各個 AI 平台的引薦流量合計起來,其佔比仍明顯低於搜尋平台引薦的流量佔比。
爬行流量的變化
如上所述,比率值隨時間的變化可能是由爬行活動的變化所驅動。這些轉變體現在Data Explorer 中可用的爬行流量份額中,以及透過 API 端點可用的原始資料(時間序列、摘要)中。下方以網路爬蟲為中心的檢視涵蓋了 2025 年 6 月近四週的資料,我們可以看到,與 Google 爬行活動相關的請求(包括 Googlebot
和 GoogleOther
標識符)的佔比在當月呈下降趨勢,並出現了幾個高峰/低谷期。在同一時間段內,Google AS15169 的 HTTP 請求流量也呈現類似的模式,與佔比下降的趨勢大致吻合。
此外,OpenAI 的 GPTBot
在整個月的多個時段幾乎沒有爬行活動。
這對內容提供者意味著什麼
這些比例直接影響內容在網際網路上發佈的可行性。雖然這些比例會隨時間波動,但整體趨勢仍然是:相較於引薦流量,爬行次數持續增加。舊式搜尋引擎網路爬蟲在每個訪客產生的情況下,可能只會掃描您的內容幾次,甚至更少。網站允許網路爬蟲存取,曾讓其收益模式更具可行性,而非相反。
我們觀察到的新資料表明,情況已不再如此。儘管向內容來源傳送的流量相同或更少,但這些模型在持續更頻繁地使用更多內容。
我們在去年發佈了新工具,幫助網站擁有者重新取回控制權。只需點擊一下,發佈者就可以封鎖那些利用其內容進行訓練的 AI 網路爬蟲。今天,我們發佈了新的方法,確保價值交換對等式雙方都公平,但在此期間,我們仍然建議內容創作者稽核並執行他們偏好的 AI 網路爬蟲政策。
還有一件事……
除了提供有關爬行、引薦流量及相關趨勢的新見解外,我們還藉此機會推出了擴展的「已驗證機器人」內容。Cloudflare Radar 上的「機器人」頁面包含已驗證機器人的分頁清單,顯示機器人名稱、擁有者、類別和排名(基於請求量)。此清單現已擴展為新的「機器人」部分中的獨立目錄。目錄如下所示,為每個已驗證機器人顯示一張卡片,其中顯示機器人名稱、描述、機器人擁有者和類別以及驗證狀態。使用者可以按機器人名稱、擁有者或描述搜尋目錄,也可以按類別進行篩選(例如,僅選擇「監控和分析」機器人)。
點擊卡片內的機器人名稱會彈出一個特定於機器人的頁面,其中包含有關機器人的中繼資料、機器人使用者代理程式在 HTTP 請求標頭中如何表示以及應如何在 robots.txt 指令中指定該機器人的資訊,同時顯示所選時間段內相關 HTTP 請求量趨勢的流量圖(預設與上一時間段進行比較)。相關資料也可透過 API 取得。未來,當我們為這些機器人專屬頁面新增更多資訊時,我們會在變更記錄項目中記錄更新。