AI 爬蟲吃掉多少頻寬？2026 從自家 CDN log 算出成本再決定限流
AI 爬蟲吃掉多少頻寬？從自己的 CDN 與 origin log 算出真實成本
帳單上的流量數字往上跳了一階，網站沒改版、廣告也沒加碼，第一個被懷疑的通常是 AI 爬蟲。問題是：你怎麼證明？很多團隊卡在同一個地方——知道 AI 爬蟲流量變多了，卻說不出它到底吃掉多少頻寬，更說不出對應到帳單上的哪一行。
這篇文章不給你業界平均值，也不給參考區間。理由很直接：AI 爬蟲頻寬的成本，高度取決於你的站有多少長尾頁、快取怎麼設、圖片多大，隨便換一個變數，答案就差一個量級。與其抄一個看起來很專業、卻跟你的站毫無關係的數字，不如把量測方法交到你手上。
接下來拆六件事：成本為什麼落在回源而不是 CPU、誰在爬（附四份官方 IP 清單的 2026-08-05 實測現況）、log 該留哪五個欄位、四個步驟怎麼換算出回源 GB、怎麼對照帳單找出真正被計費的那一項，以及為什麼我們建議先設速率限制、而不是一口氣全部擋掉。
圖說：帳單變貴的位置，是那幾道穿過邊緣快取、直接回到原站的請求——回源，才是計價的地方
AI 爬蟲的成本不在 CPU，在回源頻寬與快取未命中
先講結論：AI 爬蟲讓帳單變貴，主因通常不是伺服器算不動，而是它把大量請求打到了 CDN 邊緣快取不住的地方，逼出一次又一次的回源。一般訪客和爬蟲要的東西根本不一樣——前者集中在少數熱門頁，後者要的是「全部」。
一般訪客的存取分布是尖的。首頁、幾篇熱門文章、幾個產品頁，吃掉絕大部分流量；這些頁在邊緣節點是熱的，命中率高，原站幾乎不用出手。CDN 的省錢效果就是這麼來的，機制細節可以參考我們寫過的 CDN 邊緣節點與快取的運作原理。
爬蟲的分布是平的。它不挑熱門頁，它按 sitemap 或連結圖一路往下走，包含那些三年沒人點過的長尾頁。而長尾頁在邊緣通常沒有熱度、也就沒有被快取住，於是每一次抓取幾乎都變成一次回源請求。同樣是一萬次請求，訪客可能只讓原站出手幾百次，爬蟲則可能次次都要原站掏東西出來。
用頁面數把量級的骨架先搭起來
想估自己的量級，骨架只有三個乘數：
- 長尾頁面數——你的站有多少頁「有可能被抓，但平常沒人看」
- 每輪抓取次數——同一批 URL 在一個計費週期內被抓幾輪
- 每頁回源大小——HTML 加上首次載入時一起被拉走的圖片與靜態檔
三個數字相乘，就是一輪完整抓取造成的回源量。第一個數字你現在就查得到，後面兩個只能從 log 裡撈。
以 CloudInsight 自己的站當例子：2026-08-05 實測，中文 365 篇、英文 369 篇，合計 734 篇。這個規模在內容站裡不算大，但它示範了一件事——當一隻爬蟲把 734 個 URL 完整走一遍，而其中大多數在邊緣是冷的，原站就要被叫醒 734 次。你的站如果有五千頁、五萬頁，把數字帶進去自己看。
我們刻意不在這裡填第二、第三個乘數。因為「每輪抓幾次」和「每頁多大」這兩件事，同一個產業的兩個站都可能差三倍以上，任何幫你填好的數字都是假的。
為什麼不是 CPU 的問題
爬蟲的請求多半是 GET 靜態內容，不觸發登入、不打購物車、不跑複雜查詢。除非你的原站每次出手都要跑一輪動態渲染或資料庫查詢，否則 CPU 通常還撐得住，先喊痛的是頻寬與請求數。那為什麼大家第一時間都去看 CPU？因為它在監控面板上最顯眼。看完覺得「還好啊」，然後就漏掉了真正變貴的那一項。
圖說：左＝一般訪客集中在少數熱門頁（邊緣命中率高） 右＝爬蟲的存取幾乎平均鋪滿全站（長尾頁大量回源）
先把「誰在爬」列出來：四份官方 IP 清單的現況與更新節奏
要算帳，得先知道帳算在誰頭上。而「AI 爬蟲」從來不是一個東西——Cloudflare 在新增 AI bot 分類時一口氣拉出十類，包含 Search Engine Crawler、AI Crawler、Page Preview 等等，光是這個分法就說明：訓練用的、搜尋用的、使用者按下按鈕才觸發的，行為模式完全不同，成本結構自然也不同。
好消息是，OpenAI 與 Anthropic 都公開了自家爬蟲的出口 IP 清單，這是分群的第一份原料。以下是 2026-08-05 實測的現況——請注意，這些值會變動，你在讀這篇的時候應該自己再打一次。
| 爬蟲 | 用途 | 官方 IP 清單 | 網段數 | 清單 creationTime |
|---|---|---|---|---|
| GPTBot | 訓練 | https://openai.com/gptbot.json | 21 | 2025-10-30 |
| OAI-SearchBot | 搜尋 | https://openai.com/searchbot.json | 35 | 2026-01-02 |
| ChatGPT-User | 使用者觸發 | https://openai.com/chatgpt-user.json | 289〜290 | 2026-08-05 01:03 |
| ClaudeBot／Claude-User／Claude-SearchBot（共用一份） | 訓練／使用者觸發／搜尋 | https://claude.com/crawling/bots.json | 20（IPv4 20、IPv6 0，其中 19 個是 /32 單一 IP） | 2026-05-01 |
（以上為 2026-08-05 一手實測，數值會隨官方更新而變動）
自己重跑一次很快，一行就夠：
# 2026-08-05 實測：讀出清單的建立時間與網段數
curl -s https://openai.com/gptbot.json | \
python3 -c "import json,sys; d=json.load(sys.stdin); print(d['creationTime'], len(d['prefixes']))"
# 輸出：2025-10-30T11:00:00.000000 21
從更新節奏讀出兩種完全不同的維護成本
把四份清單的 creationTime 排在一起看，會浮出一個模式（以下是我們的分析，不是官方說法）：訓練型爬蟲的出口 IP 極穩定，使用者觸發型的則高頻變動。
GPTBot 那份清單的建立時間停在 2025-10-30，到 2026-08-05 為止九個月沒有動過。ChatGPT-User 剛好相反——它的 creationTime 就是實測當天的 2026-08-05 01:03，而且我們前後間隔幾分鐘呼叫兩次，網段數從 290 掉到 289。同一天、同一支腳本、隔幾分鐘，答案就不一樣。
規模差距也很明顯：ChatGPT-User 的 289 個網段，是 GPTBot 21 個的十四倍左右。兩家的清單風格也不同，Anthropic 那份 20 筆裡有 19 筆是 /32 的單一 IP，OpenAI 則以 /24、/25 這類網段為主。這件事直接影響你手工維護 WAF 規則的成本結構——是維護 21 條穩定規則，還是追著 289 個會漂移的網段跑。
實測踩到的坑：官方 IP 清單自己被 bot 防護擋住
這個坑值得單獨拉出來講，因為它會讓你的自動化腳本靜默失敗。同一個 https://claude.com/crawling/bots.json，只換 User-Agent，回應碼就不一樣：
| User-Agent | HTTP 回應 |
|---|---|
Python-urllib/3.13 | 403 |
curl/8.7.1 | 200 |
一般瀏覽器 UA（Mozilla/5.0 ... Chrome/128.0 Safari/537.36） | 200 |
（2026-08-05 一手實測）
三行指令就能重現：
# 2026-08-05 實測：同一個 URL，只換 User-Agent
curl -s -o /dev/null -w "%{http_code}\n" -A "Python-urllib/3.13" https://claude.com/crawling/bots.json
# → 403
curl -s -o /dev/null -w "%{http_code}\n" https://claude.com/crawling/bots.json
# → 200（curl/8.7.1 的預設 UA）
curl -s -o /dev/null -w "%{http_code}\n" \
-A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0 Safari/537.36" \
https://claude.com/crawling/bots.json
# → 200
我們第一次寫這支同步腳本時，就是用 Python 標準庫直接開 URL，結果拿到 403 卻沒有炸——腳本安靜地寫了一份空清單出去。如果你打算排程自動同步這幾份清單來餵 WAF 白名單，記得兩件事：顯式設一個像樣的 User-Agent，以及在腳本裡對「網段數為 0」這種結果直接拋錯，不要讓它默默覆蓋掉昨天的好資料。
這一步只是打標籤，不是驗證身分
必須把話講清楚：比對 User-Agent 與官方 IP 清單，得到的是分群，不是身分驗證。UA 字串誰都能偽造，而 IP 清單只能證明「這個來源在官方公布的範圍內」，不能證明對方沒有用別的手法混進來。要做到真正意義上的驗證，涉及反向 DNS、密碼學簽章等另一套機制，我們另外寫了驗證 AI 爬蟲身分的官方作法專門處理。
業界對這件事的門檻長什麼樣？Cloudflare 的 Verified bots 文件（頁面標示 Last updated 2026-07-01）列了兩條：一是誠實自我識別，做法包含 Web Bot Auth 的密碼學簽章、公布 IP 清單搭配穩定的 User-Agent，或反向 DNS；二是非濫用行為，也就是遵守 robots.txt、維持合理的請求頻率、不規避站方意願。Google 驗證 Googlebot 用的反向 DNS（FCrDNS），就是第一條的老牌做法之一。
反過來說，Cloudflare 的 fake bot 管理規則會在「UA 比對到已知 bot、但來源無法驗證」時把它標記為 fake bot。這正好說明了一件事——UA 是宣稱，不是證據。
算流量成本的階段，打標籤的精度已經夠用了。但如果你接下來要拿這份清單去設封鎖規則，精度不夠會直接變成誤傷。
從 CDN 與 origin log 算出 AI 爬蟲吃掉多少流量：五個欄位、四個步驟
爬蟲流量怎麼查？答案不在監控面板的漂亮圖表，在原始 log 裡。而多數團隊的第一個障礙不是不會算，是當初根本沒把該留的欄位留下來。
五個必留欄位
| 欄位 | 為什麼非留不可 | 少了它會怎樣 |
|---|---|---|
timestamp | 切出計費週期、看抓取節奏與尖峰時段 | 算得出總量，看不出是誰在什麼時候把你打爆 |
user-agent | 分群的第一層依據 | 完全無法把流量歸給特定爬蟲 |
client IP | 拿官方清單交叉確認 UA 標籤 | 只能相信 UA 字串，偽裝流量全部算進去 |
response bytes | 這才是頻寬帳單的計價基礎 | 只能數請求數，而請求數跟錢的關係很弱 |
cache status | 區分邊緣命中與回源 | 分不出哪些請求真的驚動了原站，回源佔比算不出來 |
最常被漏掉的是最後兩個。沒留 response bytes，你會不自覺地拿請求數當成本的代理指標——但它代理得了嗎？一張 2 MB 的主圖和一頁 30 KB 的 HTML，請求數都是 1，帳單上的差距是六十幾倍。cache status 沒留，你連「這次抓取到底有沒有回源」都答不出來，而回源正是這篇文章要算的東西。
四個步驟換算出回源 GB
| 步驟 | 動作 | 產出 | 最容易出錯的地方 |
|---|---|---|---|
| 1 | 依 user-agent 打標籤分群 | 每筆請求掛上一個 bot 名稱或「一般流量」 | 用寬鬆的關鍵字比對，把不相干的 UA 也掃進來 |
| 2 | 用官方 IP 清單交叉確認 | 標記出「UA 宣稱是某 bot、但 IP 不在清單內」的可疑筆數 | 拿一份幾個月前抓的清單來比，誤判一整批 |
| 3 | 依 cache status 拆成邊緣命中與回源 | 每個 bot 的回源請求數與邊緣命中率 | 各家 CDN 的狀態值命名不同，映射表沒做對 |
| 4 | 對回源那一批加總 response bytes | 每個 bot 在該週期的回源 GB | 把邊緣命中的 bytes 也加進去，總量灌水 |
跑完這四步，你手上會有一張表：每一隻 bot、各自的回源 GB、各自的邊緣命中率。這張表就是後面所有決策的依據——沒有它，任何限流或封鎖都只是憑感覺。
三個常見的算錯法
第一，只看請求數不看 bytes。 這是最普遍的一種，因為請求數在多數面板上是現成的，bytes 要自己撈。結果就是把一堆抓 HTML 的請求算得很嚴重，卻漏掉真正吃頻寬的圖片與靜態資源。
第二，只看邊緣不看回源。 CDN 面板上那個總流量數字，有多少真的驚動了原站？其中相當一部分可能是邊緣直接吐出去的，原站根本沒動。這兩件事在帳單上的價格不一樣，混在一起看，你會把力氣花錯地方。
第三，log 保留期太短。 只留七天，你就做不出「這個月比上個月多」的趨勢，也對不上以月為單位的帳單週期。如果你的站同時要面對 AI agent 帶來的即時請求，保留期還要再拉長一點才看得出模式，這部分我們在AI agent 流量進來前的伺服器準備裡有另外展開。
想先看清楚流量與帳務長什麼樣子？
多數團隊卡在第一步：log 保留期太短、或根本沒留 cache status，算不出回源佔比。CloudInsight 技術團隊可協助盤點雲端與 CDN 的流量與帳務結構，把「錢花在哪一項」先看清楚。
把流量換算成錢：找出你帳單上真正被計費的那一項
算出回源 GB 之後，下一個問題是：這些 GB 落在帳單的哪一格？不同 CDN 與雲端供應商的計費維度不一樣，但爬蟲流量通常會打在下面這幾項裡。
| 常見計費維度 | AI 爬蟲流量會落在哪 | 影響金額大小的關鍵 |
|---|---|---|
| 回源／出站流量（GB） | 主戰場。長尾頁的每次抓取都可能是一次回源 | 長尾頁數量、頁面體積、邊緣快取命中率 |
| 請求數（次） | 爬蟲的請求數天生就高，但單價通常遠低於流量 | 抓取輪次、每頁附帶的靜態資源數 |
| WAF／Bot Management 規則觸發次數 | 你開始擋之後才會出現的成本 | 規則設得多細、比對頻率多高 |
| log 導出與儲存 | 要做這篇的分析就會用到 | 保留期長度、導出頻率、儲存級別 |
有件事很反直覺：**你為了搞清楚爬蟲成本而開的 log 導出，本身也是一筆成本。**這不是叫你別開，而是提醒你把它一起算進去，並且在拿到答案之後決定保留期要多長，而不是無限期全開。想把各家的計費項目對齊著看，可以參考CDN 費用怎麼算的完整拆解。
為什麼這篇不給你一個「業界平均」
到這裡，你可能還是想要一個數字：別人家 AI 爬蟲吃掉多少？大概佔總流量幾成？
我們不給，而且這是刻意的。這種數字要成立，前提是拿來比較的站在長尾頁數量、快取策略、頁面體積上跟你接近——這三件事只要有一件差很多，答案就會差一個量級。給你一個看起來很專業的區間，只會讓你把它當基準去做決策，然後在錯的方向上花力氣。
唯一可信的數字，是你自己帳單上的那一個。 本文那四個換算步驟不是理論演練，是為了讓你拿到屬於自己的那個數字。拿到之後，你才有立場談要不要動、動哪一個槓桿。
為什麼建議先限流而不是全擋：三個會反咬的副作用
該不該擋 AI 爬蟲？在你有自己的數字之前，這題無解；有了數字之後，我們的建議仍然是：先設速率限制，把全擋當作最後手段。 三個理由。
第一，封鎖 IP 可能連你的意願都傳達不出去。 Anthropic 官方說明講得很直白：封鎖 IP 的方式可能無法正確或持續達成 opt-out，因為那會妨礙它讀取你的 robots.txt。這句話值得多想一秒——你以為的「擋掉」，在對方系統裡可能只是「讀不到你的意願聲明」。真正表達拒絕的管道被你自己堵死了。
標準把這個後果寫得更具體。RFC 9309 第 2.3.1.3 節規定：爬蟲去取 robots.txt 時若拿到 4xx 狀態碼（403 正是其中一種），那麼「the crawler MAY access any resources on the server」——它可以把整個站當成沒有任何限制。用 IP 規則把 robots.txt 一起擋掉，標準給對方的指示不是「都別碰」，而是「隨便抓」。方向剛好相反。
第二，封鎖名單的維護成本高於限流規則。 回頭看 2026-08-05 的實測：ChatGPT-User 的清單當天更新，而且我們兩次呼叫間隔幾分鐘，網段數就從 290 變成 289。一份會這樣漂移的清單，你要多久同步一次才算跟得上？相較之下，速率規則是行為導向的——不管對方換到哪個 IP，超過門檻就節流，不需要你追著名單跑。
第三，能見度的取捨不該由頻寬帳單單方面決定。 那是內容端的問題，成本試算表算不出答案。與 CloudInsight 同一團隊經營的 AI SEO Hacker 有專文在談擋掉 AI 爬蟲之後對搜尋能見度的影響，本文只處理成本這一半。
| 面向 | 設速率限制 | 直接封鎖 |
|---|---|---|
| 對成本的效果 | 把尖峰壓平，總量仍受控 | 理論上歸零，實際看規則是否精準 |
| 維護成本 | 規則寫一次，跟著行為走 | 要追著會漂移的 IP 清單同步 |
| 誤傷風險 | 超過門檻才節流，可觀測、可回調 | 名單過期或寫太寬就整批擋掉 |
| 對 opt-out 的影響 | robots.txt 仍讀得到，意願傳達得出去 | 可能妨礙對方讀取 robots.txt |
| 可回退性 | 調參數即可，幾分鐘見效 | 要解封並等對方重新建立信任 |
如果你想知道自己現在被 AI 爬蟲讀到什麼程度、擋掉之後會失去什麼，可以先跑一輪AI 爬蟲可及性稽核的檢查項目，把現況拍下來再動手，不然改完就沒有對照組了。
圖說：左＝速率限制（流量收窄但通道還在，意願傳達得出去） 右＝直接封鎖（通道焊死，連 robots.txt 都讀不到）
限流怎麼設：三層節流槓桿與各自的副作用
爬蟲 rate limit 不是只有一種做法。手上其實有三層槓桿，效果、風險與動手難度都不一樣。
| 槓桿 | 作用機制 | 副作用 | 建議順序 |
|---|---|---|---|
| 針對 bot 流量放寬快取 TTL | 讓原本回源的請求改由邊緣吐出 | 內容更新的可見延遲變長 | 先做，風險最低 |
| CDN／WAF 速率規則 | 超過門檻就節流或挑戰 | 門檻設太緊會誤傷正常爬取與真人訪客 | 再做，可控可回調 |
Crawl-delay | 在 robots.txt 告知期望的抓取間隔 | 屬建議性、非強制，對方可不理會 | 當補充，不能當主要手段 |
第一層：放寬快取 TTL，唯一「不減少抓取也能降成本」的槓桿
這一層特別值得先做，因為它的邏輯跟另外兩層完全不同：它不試圖讓爬蟲少抓，而是讓每一次抓取都不必驚動原站。回源變成邊緣命中，成本自然往下掉，而爬蟲拿到的內容一樣完整。
代價是新鮮度。這個代價你付不付得起？TTL 拉長，內容更新之後在邊緣被看到的時間就會延後。對規格頁、說明文件、歷史文章這類長尾內容，這個代價通常可以接受；對每天改的價格頁或即時資訊，就要小心。實際要調哪些參數、怎麼量命中率有沒有真的提升，可以照著快取策略與命中率調校的實戰作法走一遍。
順帶一提，這一層之所以有效，前提是你在四步驟換算裡確認過「回源佔比高」。如果你的爬蟲流量本來就大多在邊緣命中，調 TTL 就白忙一場——這也是為什麼我們堅持先量再動。
第二層：CDN／WAF 速率規則，可強制也可觀測
速率規則的好處是它會留下紀錄：擋了幾次、擋的是誰、什麼時段。這讓你可以把規則當成實驗來跑，而不是設完就閉眼。
要注意的是白名單。你不會想把搜尋引擎的正常抓取一起節流掉，所以那四份官方 IP 清單在這裡會再用一次——只是這次不是拿來分群，是拿來排除。也因為這樣，清單同步的可靠度直接決定誤傷率，而 Anthropic 清單那個 403 的坑，在這一層會變成真實的損失。設定位置與操作步驟可以對照Cloudflare CDN 的設定位置與操作步驟。
門檻怎麼定？我們的建議是從你量出來的實際尖峰往上抓一點當起點，先觀察一個計費週期，再收緊。一開始就設得很嚴，你會分不清楚流量下降是規則有效還是誤傷。
第三層：Crawl-delay，有用但別指望
Anthropic 官方說明表示支援 Crawl-delay。但這個指令的本質是「告知期望」，不是「強制執行」——沒有任何機制保證對方遵守，也沒有回報機制讓你知道它有沒有生效。
更根本的一點是：Crawl-delay 根本不在 robots.txt 的正式標準裡。IETF 的 RFC 9309「Robots Exclusion Protocol」（Standards Track，2022 年 9 月）只定義 user-agent、allow、disallow 三種記錄，整份文件找不到 Crawl-delay 這個字；第 2.2.4 節對這類標準外的記錄只寫了一句「Crawlers MAY interpret other records that are not part of the robots.txt protocol」——MAY，可以解讀，也可以完全不理。所以某家「支援 Crawl-delay」是它自己加的善意，不是標準義務。誰支援、怎麼解讀那個秒數，你都沒有立場要求。
所以它的定位很清楚：當補充，不當主力。設了不會有壞處，但如果你的成本問題真的很嚴重，把希望壓在一行建議性的指令上，等於沒有處理。
動手順序
- 先調快取 TTL——零封鎖風險，先把能省的省下來
- 再設速率規則——用你量出來的數字定門檻，配白名單降低誤傷
- 補上
Crawl-delay——成本低，當作禮貌性的補充 - 回頭複量——用同一套四步驟再算一次回源 GB，跟動手前的數字比
第四步最常被跳過，但它才是整件事的閉環。省下來的那一段，真的是你的規則做到的嗎？沒有回頭複量，你永遠分不出那是規則的功勞，還是那隻爬蟲那個月剛好沒來。
快取與速率規則要調到哪一格，跟你買的方案有關
快取策略與速率規則要調到哪一格，跟你用哪家 CDN、買哪個方案綁在一起。CloudInsight 代理 AWS、GCP、Azure、阿里雲與騰訊雲，提供統一帳務、正規合約與台灣時區的中文技術支援。
常見問題
Q: 怎麼知道我的 CDN 流量暴增是不是 AI 爬蟲造成的？
A: 從 log 的 user-agent 分群開始，再用官方 IP 清單交叉確認。2026-08-05 實測，GPTBot 公布 21 個網段、ChatGPT-User 289〜290 個，比對後就能把流量歸給特定爬蟲。接著看 cache status，如果暴增的那一批大多是回源而非邊緣命中，來源幾乎可以確定不是一般訪客。
Q: 只比對 User-Agent 就能算出 AI 爬蟲流量嗎？
A: 不夠。User-Agent 字串誰都能偽造，只比對它會把偽裝流量一起算進來。務必再用官方 IP 清單交叉確認，例如 OpenAI 的 gptbot.json 與 Anthropic 的 bots.json。要注意這一步得到的是分群、不是身分驗證，真正的驗證要靠反向 DNS 或密碼學簽章等機制。
Q: Crawl-delay 設了真的有用嗎？
A: Anthropic 官方說明表示支援 Crawl-delay，但它屬於建議性指令、不具強制力，也沒有回報機制讓你確認對方有沒有遵守。定位上它是三層節流槓桿裡最弱的一層，適合當補充，不適合當主要手段。真正能強制執行又可觀測的，是 CDN 或 WAF 的速率規則。
Q: 把 AI 爬蟲全部擋掉，頻寬費用就一定會降嗎？
A: 不一定，而且可能帶來新問題。Anthropic 官方說明指出，封鎖 IP 的方式可能無法正確或持續達成 opt-out，因為那會妨礙它讀取你的 robots.txt。另外 IP 清單本身會漂移，2026-08-05 實測時 ChatGPT-User 的網段數在幾分鐘內就從 290 變成 289，名單過期就會誤傷。
Q: log 要保留多久才算夠？
A: 至少要蓋滿一個完整的計費週期，否則你算出來的流量對不上帳單上的期間。想看趨勢就要更長，因為爬蟲的抓取是一輪一輪來的，只留七天可能整輪都沒抓到。實務建議是先拉長保留期完成一次完整量測，再依 log 儲存成本回頭調整。
結論：先量再決定，不要憑感覺擋
回到最開始那個問題：AI 爬蟲到底吃掉你多少頻寬？這篇文章從頭到尾只回答了一件事——怎麼算出你自己的那個數字，而不是告訴你別人的數字是多少。
三步收尾。第一步，把 log 的五個欄位開齊（timestamp、user-agent、client IP、response bytes、cache status），並把保留期拉到至少蓋滿一個完整計費週期。第二步，跑四個步驟算出各 bot 的回源 GB，再對照帳單找出被計費的那一項。第三步，先調快取 TTL、再設速率規則、補上 Crawl-delay，然後回頭用同一套方法複量一次。
有了自己的數字之後，很多爭論會自動消失。有人說 AI 爬蟲很花錢、有人說沒差，兩邊都對——差別只在於他們的站不是你的站。你的答案只在你自己的 log 和帳單裡。
圖說：順序是先量再調——左邊的紀錄（log）先累積夠，中間的儀表才讀得出數字，右邊的旋鈕才有得轉
🎯 立即行動
把 AI 爬蟲流量從「感覺很多」變成帳單上可指認的一行，是最快能動手、也最容易被跳過的一步。
👉 立即諮詢，取得最適合您的方案 👉 加入 LINE 官方帳號，即時獲得技術支援
參考資料
- IETF RFC 9309《Robots Exclusion Protocol》（Standards Track，2022 年 9 月；robots.txt 的正式規格，2026-08-05 讀取）
- OpenAI GPTBot IP 清單（gptbot.json）（2026-08-05 實測）
- OpenAI OAI-SearchBot IP 清單（searchbot.json）（2026-08-05 實測）
- OpenAI ChatGPT-User IP 清單（chatgpt-user.json）（2026-08-05 實測）
- Anthropic 爬蟲 IP 清單（bots.json）（2026-08-05 實測）
- Anthropic 官方說明：爬蟲行為與站方的封鎖方式（2026-08-05 實測 200）
- Cloudflare Verified bots 驗證門檻文件（頁面標示 Last updated 2026-07-01）
- Cloudflare Fake bot 管理規則
- Cloudflare 新增 AI bot 分類說明
相關文章
怎麼確認來的真的是 GPTBot？2026 爬蟲身分驗證三關卡
要驗證 GPTBot 真假，比對 User-Agent 完全不夠——UA 是請求端自己填的。本文用 2026-08-05 的實測資料，示範官方 IP 清單比對、反向 DNS 雙向驗證與 Cloudflare Verified Bots 兩條門檻怎麼組成一條可稽核的判定流程，並附上可自行重現的 403／200 實測指令。
CDN2025 CDN 廠商完整比較：Cloudflare vs AWS CloudFront vs Akamai
Cloudflare、AWS CloudFront、Akamai 三大 CDN 廠商完整比較。從功能、價格、節點分布到適用場景，幫你找出 2025 年最適合的 CDN 解決方案。
CDNCDN 費用完整指南：2026 各大廠商定價比較與省錢技巧
CDN 費用怎麼算？完整解析 Cloudflare、AWS CloudFront、Akamai 的計費方式，附上實際費用試算與省錢技巧，幫你找到最划算的 CDN 方案。