AI 爬蟲怎麼讀一個中文網站？7 天 49,996 次請求的實測拆解

「AI 到底有沒有在讀我的網站」，我一直以為只能靠感覺回答。直到我打開 Cloudflare 的原始請求紀錄，把七天內每一筆 AI 機器人的請求逐條比對它打了哪個網址——結果跟我想的完全不一樣。

資料來自我自己維護的一個台灣繁體中文內容站（WordPress，約 850 篇已發布文章），窗口是 2026 年 8 月 18 日到 24 日共 7 個完整 UTC 日。數字、口徑、量法與所有我不確定的地方我會全部攤開——你可以不同意我的解讀，但至少能複核我的算術。

先講最重要的一句：AI 爬蟲在這七天裡有 83.8% 的抓取，花在已經下架或只會轉址的舊網址上。不是花在我辛苦寫的新文章上。

一、先把口徑講清楚，不然後面的數字都不能比

「AI 爬蟲流量」的說法只要沒講口徑就無法複核。我的口徑：

• 窗口：2026-08-18 至 2026-08-24，7 個完整 UTC 日（不是 7 天滾動，也不是台北時間切日）。
• 母體：Cloudflare 判定為已驗證機器人、且分類屬於 AI 相關類別的請求。
• 只算內容頁：已排除靜態資源與基礎設施路徑（例如佈景主題檔、後台端點、圖片檔）。
• 已排除我方自己的腳本：排程實爬前台時用專屬的使用者代理字串，量測時排除，否則等於自己污染自己的指標。

用這個口徑數出來，七天合計 49,996 次。按分類拆開是 AI Crawler 46,386、AI Search 3,517、AI Assistant 93，三者相加正好等於 49,996。

一個我必須先自打臉的地方

但下一節那張分桶表，加總只有 42,265 次，比 49,996 少了 7,731 次。這不是算錯，是同一批資料的兩種數法：49,996 是「總共幾次」，42,265 是「逐條網址列出來之後再加總」——而逐頁統計每天最多只回 5,000 列，我這七天七次全部撞到上限，超出的部分就沒有進到路徑清單裡。

我原本以為這是兩種母體的差異，回頭逐日核對才確認不是：兩者同母體、同濾網，差別只在後者被列數上限切掉了尾巴。所以本文講「AI 讀了幾次」一律用 49,996，講「抓取分布在哪些網址」才用 42,265，而且只當比例看。

這個坑值得留意：同一份報表裡兩個數字長得都像「總數」，其中一個卻是被截斷的。網路上不少 AI 爬蟲統計圖表互相打架，我懷疑有一部分就是這樣來的。

還有一個更細的坑：「AI Crawler／AI Search／AI Assistant」這組分類名稱，在 Cloudflare 自己的文件裡已經被歸為「舊分類」。文件明確註記，在 2026 年 7 月 1 日啟用的新分類法之下，AI Search 與傳統搜尋之間「不再有有意義的區別」，兩者都被視為 Search 行為；AI Search 這個值只是為了讓既有規則向後相容而保留。所以如果你看到有人拿「AI Search 佔比」講一個很精確的趨勢，先確認他用的是哪一版分類法。

二、最大的發現：83.8% 的抓取打在已經沒有用的網址上

我把路徑清單裡那 42,265 次、歸得出類的 13,921 條路徑分成五桶，逐條比對它現在的狀態：

桶	請求次數	佔比	不重複路徑	平均每條被讀
② 已下架或已轉走的舊網址	18,856	44.6%	5,045	3.7 次
③ 數字型舊 ID 網址（會 301）	16,580	39.2%	7,730	2.1 次
① 在 sitemap 內的現役內容	4,754	11.2%	271	17.5 次
④ 分類／標籤／作者／分頁／feed 封存頁	1,784	4.2%	832	2.1 次
⑤ sitemap 與 robots.txt	291	0.7%	43	6.8 次

五桶加總正好是 42,265 次與 13,921 條路徑，沒有第六桶。② 與 ③ 合計 35,436 次，佔 83.84%。（路徑數為 2026-08-25 的量測值；請求數與佔比不受影響。）

被列數上限切掉的那 7,731 次呢？它們依定義落在長尾——每天被打次數最少的那些網址，幾乎都是冷門舊網址，不會是我 sitemap 裡那 280 條現役內容。所以截斷的影響方向是確定的：83.8% 如果有偏差，是低估不是高估。這也是我唯一敢對截斷下的判斷——它只用到「長尾比較冷門」這一個前提。

但「83.8% 被浪費了」這個說法太快了

看最右邊那欄。現役內容平均每條路徑被讀 17.5 次，數字型舊 ID 網址平均只有 2.1 次。AI 爬蟲不是反覆盯著舊網址狂讀，而是「舊網址的品項實在太多」——光③這一桶就有七千多條不重複路徑，我整份 sitemap 卻只有 280 條。

這個對照把問題從「AI 爬蟲很笨，一直讀垃圾」改寫成「我的網站對外暴露了幾千條不該存在的入口」——前者你無能為力，後者是你自己的網站架構問題。網站的 URL 結構與導覽層級怎麼規劃，在這件事上的影響比任何 AI 專用設定都大。

好消息藏在①那一桶

sitemap 裡 280 條網址，其中 271 條在這七天內至少被 AI 抓過一次，覆蓋率 96.8%。「AI 找不到我的新內容」在我這個站上不成立——它們找得到，只是同時還在讀另外一萬三千條沒用的東西。全站單一路徑的最高次數是一篇談 SEO 的文章，709 次；首頁 655 次。（這份排行榜本身沒有標桶別，所以我不會宣稱這兩條各自落在哪一桶。）

三、對照組：真正的 Googlebot 只有 1,116 次，而且你不過濾就會多算一倍

我原本只想拿 Googlebot 當背景參考，結果它自己變成本文第二個發現。同一個七天窗口：帶有 Googlebot 使用者代理字串的請求有 2,333 次，但通過 Cloudflare 機器人驗證的只有 1,116 次。差額 1,217 次之中，有 1,211 次集中在 8 月 20 日這一天。那不是均勻分布的背景噪音，是某一批來源在單日大量偽裝成 Googlebot——是不是同一個行為者，我的資料看不出來。

使用者代理字串是請求方自己填的，任何人都能填成 Googlebot。Google 官方文件把驗證方法寫得很清楚：對來源 IP 做反查 DNS，確認網域是 googlebot.com、google.com 或 googleusercontent.com，再正查回去確認得到同一個 IP；或直接拿 Google 公布的 IP 清單比對。Cloudflare 的已驗證機器人機制就是幫你做完這件事。

實務意義很直接：任何「AI 爬蟲比 Googlebot 多幾倍」的說法，先問對方有沒有做機器人驗證。以我這份資料，49,996 對 1,116 約是 45 倍——但我無法保證兩者路徑口徑完全一致，這個倍數只該當數量級看。

另外，大量偽裝成 Googlebot 的請求通常不只是統計問題。WordPress 的登入防護與更新策略值得順手檢查一次，偽裝爬蟲跟掃描弱點的往往是同一批流量。

四、使用者觸發的 95 次，跟那四萬次不是同一種東西

同一個七天窗口裡，使用者觸發的抓取共 95 次，全部來自 ChatGPT-User，逐日分別是 16、21、15、15、8、8、12——七天之中每一天都有。Perplexity-User 是 0，Claude-User 也是 0。

這裡有一段過程值得講。我第一次整理時撞到一個矛盾：AI Assistant 這個分類七天只有 93 次，ChatGPT-User 卻有 95 次——但 Cloudflare 文件把 AI Assistant 定義成「由使用者動作驅動的自動化 AI 機器人」，ChatGPT-User 理應被涵蓋在內。寬的那一桶不可能比窄的那一項小。

逐日拆開就找到了：七天裡六天完全相同，只有 8 月 19 日 ChatGPT-User 是 21、AI Assistant 是 19。AI Assistant 這個桶幾乎就是 ChatGPT-User 本身，而有 2 次帶著 ChatGPT-User 字樣的請求沒有被歸進任何 AI 分類。

這 2 次比那 93 次更值得看。字串是請求方自己填的，分類是平台端另外判的，兩者可以不一致——這跟下一節那 1,211 次假冒 Googlebot 是同一件事，只是規模小得多。看到一個機器人名稱，不等於那真的是那隻機器人。

95 小到看起來可以忽略，但三家官方文件都把它跟一般爬蟲明確區分：

• OpenAI 把自家機器人分成幾種用途：GPTBot 用於訓練，OAI-SearchBot 用於在 ChatGPT 搜尋結果中呈現網站，而 ChatGPT-User 是「使用者在 ChatGPT 或 Custom GPT 提問時，可能造訪網頁」的代理。文件明寫它「不用於自動爬取網路」，而且「因為這些動作是由使用者發起的，robots.txt 規則可能不適用」。
• Perplexity 的說法更直白：PerplexityBot 負責搜尋索引，Perplexity-User 支援使用者動作，而且文件直接寫「由於是使用者要求的擷取，這個擷取器通常會忽略 robots.txt 規則」。
• Anthropic 則列出三隻機器人：ClaudeBot 收集可能用於模型訓練的網頁內容、Claude-User 支援使用者發起的請求、Claude-SearchBot 用於改善搜尋結果品質。文件並說明關掉 Claude-User 會讓系統無法在使用者提問時取得你的內容。

三份文件擺在一起，結論就出來了：一次使用者觸發的抓取，背後大致對應「有一個人問了問題，模型決定去打開你這一頁」。它跟批次爬取不是同一種訊號。

所以我把 ChatGPT-User 的每日次數當先行指標在追。優點是每天都有數字、不必等索引；缺點是它不是流量、也不保證有人真的看到你——模型讀完可能只摘一句話、不附連結。我不會拿它換算任何「等同於幾次瀏覽」的數字，沒有公開資料支持那種換算。

五、noindex 擋得住 Google，擋不住 AI 爬蟲

這是②③兩桶的直接後果：那些網址很多是設了 noindex 或已轉走的舊內容，Google 早就不收，AI 爬蟲照樣一天到晚在讀。

Google 官方文件其實已經寫明機制。noindex 是「寫在頁面上、等爬蟲自己來讀」的指令：Googlebot 必須先爬到那一頁、抽出標籤或標頭，Google 才會把該頁移出搜尋結果。文件甚至提醒，若該頁被 robots.txt 擋住或爬蟲進不去，爬蟲根本看不到 noindex，該頁反而可能因為別的頁面連過來而繼續出現在搜尋結果裡。

所以：noindex 是「請不要把我放進搜尋索引」，不是「請不要讀我」。它的收件人是願意遵守它的搜尋引擎。AI 業者的退出機制是另一套東西——在 robots.txt 裡針對各自的機器人名稱下規則，而且如上一節所述，使用者觸發的那一類本來就可能不吃 robots.txt。

標一個誠實的界線：我沒有做「同一頁加上 noindex 前後對照」的受控實驗，上面是機制推論加觀測，不是實驗結果。要因果證據的話，這一段還不夠。

六、你自己怎麼查（不需要付費工具）

這份資料沒用到任何 SEO 付費工具，全部來自 Cloudflare 的 GraphQL Analytics API。想自己跑一份，思路是這樣：

1. 用請求層級的分組查詢，維度取「已驗證機器人分類」「使用者代理字串」「請求路徑」，指標取請求數。Cloudflare 官方文件有結構自省說明，可以直接把 schema 撈下來看有哪些欄位。
2. 一定要加上主機名稱條件。底下若有廢棄的子網域，不加這條會把它們的噪音全混進來——我第一次跑就是這樣，得到一個完全不能看的 5xx 比例。
3. Googlebot 一定要用「已驗證機器人」欄位過濾，不要用使用者代理字串比對——理由就是第三節那 1,211 次。
4. 把自己排掉。你自己的監測腳本、外掛的健康檢查、CDN 的回源探測，都會進到同一份紀錄裡。
5. 注意列數上限。路徑維度的查詢有回傳列數上限，我這七天每天都撞到 5,000 列，長尾一定是低估的。

兩個限制先講：Cloudflare 免費方案只保留 8 天資料，想看長期趨勢就得每天自己存一份；而且這條路只有在流量真的走 Cloudflare 時才成立，只把它當 DNS 用的話紀錄裡什麼都沒有。想確認自己的站有沒有真的走 CDN，可以先看CDN 的原理與台灣連線實測。

沒有 Cloudflare 也有替代方案：主機端的存取紀錄有一模一樣的資訊，只是要自己解析與做反查 DNS 驗證。共享主機通常拿不到完整的存取紀錄，VPS 與託管型主機則多半可以，這在挑主機時值得列進去比。至於搜尋端的表現，那是另一套資料，要看 Google Search Console，兩者不能互相取代：前者告訴你「誰來讀了」，後者告訴你「有沒有人因此看到你」。

七、那 83.8% 該不該處理？我的答案有條件

最直覺的反應是「把舊網址清一清，讓爬蟲把力氣花在新內容上」。我要很明確地說：這個推論我不替你保證。它預設了一件沒被證實的事——AI 爬蟲的抓取預算是零和的，省下來的會自動轉到別處。但 AI 業者沒有公開任何關於抓取預算如何分配的資料，我也沒看過任何可驗證的實驗證明「刪掉舊網址會讓新內容被讀更多次」。請不要把這篇文章當成那個結論的依據。

我實際會做、以及不會做的事是這樣分的：

值得做（因為它本來就該做）	先不要做（因為理由建立在未證實的因果上）
把多跳的轉址鏈壓平成一跳	為了「省抓取預算」把舊網址一次大量改成 410
把已刪除頁面回傳的軟性 200 改成正確的狀態碼	用 robots.txt 全面封鎖 AI 機器人，只為了讓數字變好看
收斂無限延伸的分頁與參數網址	為了餵 AI 而新增一批專門給機器讀的頁面
檢查舊 ID 網址是從哪裡被連出去的	把 noindex 當成阻擋 AI 的手段（第五節已說明它不是）

左欄不管 AI 存不存在都該做，做完網站本來就更乾淨；右欄需要的是因果證據，而目前沒有人有。「本來就該做」與「會帶來成效」是兩個不同的理由，混在一起講就是我最不想寫的那種文章。

八、把所有誠實標價集中在這裡

1. 路徑清單被截斷 7,731 次。逐頁統計每天在 5,000 列上限被切，七天全撞到，所以 49,996 次裡只有 42,265 次進得了分桶。真實不重複路徑數只會比 13,921 更多，桶②桶③只會被低估（方向見第二節）。
2. 只有 8 天資料。Cloudflare 免費方案的保留期限，所以我無法回答「這個分布是長期常態還是這週特例」。
3. 機器人分類本身可能有誤。資料裡有一批偽裝成 Android 瀏覽器的使用者代理字串卻被判為 AI 類別。我懷疑是某個已知爬蟲，但無法確證，所以不點名。這代表 49,996 本身也有誤差；第四節那 2 次沒被歸進 AI 分類的 ChatGPT-User 則是同一問題的反方向實例。
4. 只有一個站、一種內容類型。樣本 n=1，別的網站、產業、語言分布可能完全不同。
5. 本文結論都是觀測，不是受控實驗——沒有 A／B 對照，也沒有前後測。
6. 第三節的倍數比較口徑不完全一致，只該當數量級看。

結論：三件我現在會做的事

如果你只想帶走可以馬上動手的部分：

第一，先把自己的紀錄撈出來看一次。我原本以為會看到「新文章沒被讀」，實際看到的是「新文章被讀了，但淹在一萬三千條舊網址裡」——這兩件事的處置方式完全不同。

第二，把「使用者觸發」的那幾個代理字串單獨拉出來追。ChatGPT-User、Perplexity-User、Claude-User 這一類，每天記一個數字就好——那是少數不必等索引、不必等排名就看得到的訊號。它會不會轉化成實質流量，我還在觀察。

第三，把 noindex 從你的 AI 對策清單裡拿掉。真正對應的機制是 robots.txt 裡的機器人名稱規則，而且對使用者觸發的那一類可能無效——三家官方文件都寫得很清楚，只是很少人去讀。

至於 AI 這個題目上真正影響日常工作的，其實還是工具本身怎麼選、政策風險怎麼看，而不是爬蟲怎麼讀你。

本文引用的一手來源

以下每一條都是我在 2026 年 8 月 25 日當天實際打開、逐字比對過的官方頁面，網址是跟隨轉址後的最終位置：

• OpenAI — Overview of OpenAI Crawlers：證明 GPTBot、OAI-SearchBot、ChatGPT-User 的用途區分，以及「ChatGPT-User 不用於自動爬取網路」「因為動作由使用者發起，robots.txt 規則可能不適用」兩段原文。
• Perplexity — Perplexity Crawlers：證明 PerplexityBot 與 Perplexity-User 的分工，以及「由於是使用者要求的擷取，這個擷取器通常會忽略 robots.txt 規則」的原文。
• Anthropic 說明中心 — Does Anthropic crawl data from the web, and how can site owners block the crawler?：證明 ClaudeBot、Claude-User、Claude-SearchBot 三者的用途與關閉後的影響。
• Cloudflare — Verified bots：證明已驗證機器人的分類方式，以及「AI Crawler／AI Search／AI Assistant」屬於舊分類、AI Search 在 2026 年 7 月 1 日的新分類法下已併入 Search 的註記。
• Cloudflare — GraphQL Analytics API：本文資料的取得方式，以及第六節查詢思路的依據。
• Google — Verify Requests from Google Crawlers and Fetchers：證明反查 DNS 加正查驗證的官方步驟，以及 Google 另有公布 IP 清單可供比對。
• Google Search Central — Block Search indexing with noindex：證明 noindex 要生效必須「頁面沒有被 robots.txt 擋住且爬蟲能夠存取」，否則爬蟲看不到該規則。

免責聲明：本文所引用之官方文件與平台政策，均為 2026 年 8 月 25 日查核之版本，各家爬蟲政策與分類法可能隨時修訂，實際適用請以各平台當下公告為準。文中所有數字皆來自單一網站在 7 天內的實際請求紀錄，樣本為 n=1，不代表其他網站或期間；已知的量測限制集中列於第八節。本文不構成任何關於「調整網站後將獲得特定成效」的保證。