robots.txt 沒擋，AI 爬蟲卻爬不到？2026 三層落差實測
robots.txt 說可以，AI 就真的爬得到嗎？三層落差與實測方法
你在 robots.txt 裡把 GPTBot、ClaudeBot、PerplexityBot 全部 Allow 了。然後呢？AI 爬蟲爬不到你的網站這件事，還是有可能正在發生，而你從那個檔案裡一個字都看不出來。
原因很單純。robots.txt 是你貼在門口的一張告示，CDN 與 WAF 才是真正站在門口決定放不放行的那個人。這兩樣東西根本不在同一個系統裡——一個是網站根目錄下的純文字檔，一個是 CDN 後台的一組規則。它們可以完全對不上，而且沒有任何機制會主動提醒你。
這篇文章把一條請求從網際網路走到你的網頁、中間要過的三關拆開來看：政策層（robots.txt）、邊緣層（CDN／WAF）、origin 層（你自己的伺服器）。接著給你一套可以直接複製貼上的實測方法——用官方完整 User-Agent 打真正的內容頁，加上同一時段的一般瀏覽器 UA 對照組——以及 403、429、503 與「200 但內容是空殼」四種結果各自該回頭查哪一層的判讀表。文中所有數字都是 2026-08-05 對 cloudinsight.cc 自家網站實際跑出來的，指令一併附上，你可以照著重跑。
圖說：一條請求要過三關——① 政策層 robots.txt ② 邊緣層 CDN／WAF ③ origin 伺服器；真正被擋下的，多半是在第二關
robots.txt 是政策層宣告，不是執行層：一條請求要過三關
一條 AI 爬蟲的請求要讀到你的內容，得依序通過三個彼此獨立的關卡，而 robots.txt 只管得到第一關。這是「robots.txt 明明 Allow 了、內容卻進不了 AI」最常見的結構性原因。
三關各自是什麼、誰在控制、能不能真的擋掉請求，直接看表：
| 層 | 具體是什麼 | 誰在控制 | 能不能擋掉請求 | robots.txt 上看得到嗎 |
|---|---|---|---|---|
| 政策層 | 網站根目錄的 robots.txt 純文字檔 | 你自己（寫檔案的人） | 不能。它只是宣告意願，遵不遵守由爬蟲決定 | 就是它本身 |
| 邊緣層 | CDN／WAF 的 bot 防護、速率規則、地理與 ASN 規則、JS 挑戰 | CDN 後台（可能是另一個同事、甚至外包廠商） | 能。請求還沒碰到你的程式碼就被回掉 | 完全看不到 |
| origin 層 | 你的伺服器、應用程式、框架的轉址與渲染邏輯 | 開發團隊 | 能，但通常是無意的（轉址、渲染、權限） | 看不到 |
看懂這張表，那句關鍵認知就成立了：robots.txt 檔案再乾淨，也完全反映不出邊緣層在做什麼。
這不是我們的詮釋，是標準本身講的。robots.txt 的正式規格是 IETF 的 RFC 9309「Robots Exclusion Protocol」（Standards Track，2022 年 9 月）。它在第 1 節寫明，這些規則是「爬蟲被請求遵守」（crawlers are requested to honor）的，緊接著一句「These rules are not a form of access authorization.」——這些規則不是一種存取授權。第 3 節 Security Considerations 又補一刀：「The Robots Exclusion Protocol is not a substitute for valid content security measures.」要真的管住存取，得在應用層放真正的安全機制。
所以你在 robots.txt 寫 Allow，標準層面的意思是「我不反對你來」，不是「我保證你進得來」。前者你說了算，後者不是。
它們不只是兩個不同的設定畫面，而是兩個不同的系統。改 robots.txt 的人可能是行銷或 SEO 負責人，動 CDN 規則的可能是維運，甚至是三年前幫你架站的外包。兩邊沒有任何同步機制，也沒有任何一方會跳出來說「你這條 Allow 其實被我擋掉了」。
政策層長什麼樣子：一個乾淨到底的實例
先看一個「政策層完全沒問題」的樣本。2026-08-05 我們把自家 cloudinsight.cc 的 robots.txt 抓下來，裡面對主流 AI 爬蟲一路開綠燈——GPTBot、ClaudeBot、PerplexityBot、OAI-SearchBot、Claude-SearchBot、Google-Extended，全部是 Allow: /。
curl -s https://cloudinsight.cc/robots.txt
輸出裡每一個 AI 爬蟲區塊都長這樣：
User-Agent: GPTBot
Allow: /
User-Agent: ClaudeBot
Allow: /
User-Agent: Google-Extended
Allow: /
這份檔案能證明什麼？只能證明一件事：站方沒有在政策層表達拒絕的意思。 它證明不了 AI 真的讀得到任何一頁。要證明後者，得往下一層走。
順帶一提，任何只讀 robots.txt 就給你綠燈的檢查——不管是工具跑的還是人工看的——結論都要打折。那個綠燈的意思是「第一關通過」，不是「三關通過」。CDN 在整條請求路徑上到底站在哪個位置，可以先看我們的 CDN 是什麼？原理、優勢與選擇指南 補起來，後面的判讀會輕鬆很多。
圖說：由外而內＝① 政策層 robots.txt（虛線，擋不住東西）② 邊緣層 CDN／WAF（實心厚環，真正決定放不放行）③ origin 伺服器（核心）
中間那層在做什麼：bot 防護、速率規則與 fake bot 判定如何變成 403 與 429
邊緣層擋掉爬蟲，通常不是誰刻意去設「封鎖 AI」，而是幾組泛用防護規則順手掃到的結果。這也是它難察覺的原因——沒有人做過那個決定，那誰會記得回頭檢查？
常見的四類機制，以及它們對爬蟲的典型結果：
| 機制 | 它實際在判什麼 | 對 AI 爬蟲的典型結果 |
|---|---|---|
| bot 挑戰模式 | 請求看起來像不像自動化程式（UA、TLS 指紋、行為特徵） | 403，或回一頁 JS 挑戰頁 |
| 速率限制規則 | 單一來源在時間窗口內打了幾次 | 429 |
| 地理／ASN 規則 | 來源國家或自治系統編號是否在允許清單內 | 403 |
| JS 挑戰 | 對方跑不跑得動 JavaScript | 狀態碼 200，但拿回的是挑戰頁而非內容 |
第一列最值得停下來看。Cloudflare 的 fake bot 管理規則文件寫得很直接：若 User-Agent 比對到已知 bot、但來源無法驗證，規則就把該請求標記為 fake bot（Cloudflare）。
這句話反過來讀才有意思。規則判的是「來源能不能驗證」，不是「這隻爬蟲是不是真的」。一隻貨真價實的 AI 爬蟲，只要驗證鏈在某個環節沒接上——出口 IP 剛換、廠商的清單還沒同步、反向 DNS 設定漏掉——就會落進和偽裝流量同一個籃子。而你在 robots.txt 上，看不到任何徵兆。
「已驗證」是有門檻的，而門檻不在你手上
Cloudflare 的 Verified bots 文件（頁面標示 Last updated 2026-07-01）列出兩條要求：一是誠實自我識別——透過 Web Bot Auth 密碼學簽章、公布 IP 清單搭配穩定的 user agent、或反向 DNS；二是非濫用行為——遵守 robots.txt 與爬取指示、維持合理請求頻率、且未被觀察到規避站方意願或攻擊網站（Cloudflare）。
注意這兩條的主詞都是爬蟲營運商，不是你。也就是說，某隻爬蟲有沒有「已驗證」身分，你這個站主既無法決定、也不會收到通知。那站主還能做什麼？只有一件事：實際測，看它到底過不過得來。
規則掛在哪一類，決定你誤傷的範圍
顆粒度也是個變數。Cloudflare 在 AI bot 分類的公告中，把 bot 分成 Search Engine Crawler、Aggregator、AI Crawler、Page Preview、Advertising、Academic Research、Accessibility、Feed Fetcher、Security、Webhooks 共 10 類（Cloudflare）。
這代表什麼？你的規則掛在「AI Crawler」，跟掛在更上層的泛 bot 類別，誤傷範圍差很多。前者只影響 AI 爬取，後者可能連 Search Engine Crawler 一起掃到——那就不只是 AI 讀不到，是連傳統搜尋收錄都受影響。實務上我們看過最多的狀況，是規則當初為了擋掃描器而開，開的位置比需要的高了一層，然後就沒有人再回頭看過。
要確認自家 bot 防護的等級與自訂規則實際掛在哪裡，設定位置可以對照 Cloudflare CDN 完整教學：從註冊到進階設定；如果你的站在 Google Cloud 上、防護走的是另一套 WAF，對應的規則層與記錄查法見 GCP 資安與 Cloud Armor 防護完整指南。這兩層的日誌，是後面判讀狀態碼時要回頭翻的地方。
順著同一條路徑往前看，若你的防護是為了擋攻擊流量而開的，CDN DDoS 防護的運作原理與設定 會說明那些規則平常在做什麼——理解它的本職，才知道它為什麼會順手掃到爬蟲。
對自家站跑一次三層稽核：六種 UA 打同一個內容頁，狀態碼與位元組全部一致
講方法之前，先把方法跑一次給你看——一輪乾淨的稽核，輸出到底長什麼樣？2026-08-05，我們拿 cloudinsight.cc 自己的站當標的，用五組 AI 爬蟲的 User-Agent 加一組一般 Chrome 瀏覽器 UA（對照組），在同一個時間窗口打同一個中文內容頁。
指令長這樣，可以直接複製：
UA_GPT='Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot'
UA_BROWSER='Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36'
URL='https://cloudinsight.cc/zh/blog/cdn-settings'
curl -sS -A "$UA_GPT" -o /dev/null -w '%{http_code} %{size_download}\n' "$URL"
curl -sS -A "$UA_BROWSER" -o /dev/null -w '%{http_code} %{size_download}\n' "$URL"
-A 指定送出的 User-Agent，-o /dev/null 把內容丟掉不印，-w '%{http_code} %{size_download}' 只留下狀態碼與回應位元組數。兩行之間不要間隔太久，這樣才算「同時段」。
六組 UA 的結果如下（2026-08-05 實測，UTC 02:05）：
| 送出的 User-Agent | 狀態碼 | 回應大小 |
|---|---|---|
| GPTBot（官方完整字串） | 200 | 133,173 bytes |
| OAI-SearchBot（官方完整字串） | 200 | 133,173 bytes |
| ChatGPT-User（官方完整字串） | 200 | 133,173 bytes |
| ClaudeBot | 200 | 133,173 bytes |
| PerplexityBot | 200 | 133,173 bytes |
| 一般 Chrome 瀏覽器（對照組） | 200 | 133,173 bytes |
六列的狀態碼一致，回應大小連一個 byte 都沒差。結論很乾脆：這個網址上，邊緣層沒有依 User-Agent 做差別處置。
順帶一提，這個站確實有邊緣層——同一次請求的回應標頭裡有 server: cloudflare 與 cf-cache-status: DYNAMIC，origin 則在另一個平台上。所以這不是「因為沒有 CDN 所以沒事」，而是「有 CDN，而且規則沒有誤傷」。這兩件事在稽核報告裡的份量完全不同。
落差長什麼樣子？一個示意的失敗案例
六種 UA 全部 200、位元組完全一致，那是通過的樣子。不通過會長什麼樣？下表是示意，不是實測資料，只是把「有落差」時你會在終端機看到的畫面寫出來，方便你對照自己的輸出：
| 送出的 User-Agent | 狀態碼 | 回應大小 | 這代表什麼 |
|---|---|---|---|
| 爬蟲官方完整 UA | 403 | 幾百 bytes | 邊緣層依 UA 拒絕 |
| 一般瀏覽器 UA（對照組） | 200 | 一百多 KB | 站本身是活的、內容也在 |
只要對照組是 200、爬蟲組不是，差別就落在 UA 這個變數上，而 UA 是邊緣層在判的東西。這時候不必再猜是不是站掛了——對照組已經幫你把那個可能性排除掉了。這正是對照組唯一的、也是全部的價值。
圖說：上＝爬蟲 UA 這條被邊緣層擋下，下＝瀏覽器 UA 對照組順利拿到內容；兩條打的是同一個網址、同一個時段
不確定自家的 CDN 與 WAF 到底疊了哪些規則？
多數站方不知道自己有這道落差，是因為沒有人同時看得到 robots.txt 跟 CDN 後台的規則。CloudInsight 技術團隊可協助梳理雲端與 CDN 的設定分布，確認邊緣層到底疊了哪些規則。
實測方法：官方完整 UA 打內容頁，加上同時段的一般瀏覽器 UA 對照組
方法本身只有四個要點，但每一點都有人踩過。我們把踩過的坑一起寫進去。
要點一：UA 要用官方完整字串，不是半截 token
規則常常比對的是完整字串，不是關鍵字。你只寫 GPTBot 三個字去測，測出來的結果不能代表真爬蟲來訪時會發生什麼——它可能過、真爬蟲被擋，也可能反過來。
「token 不等於完整字串」這個分別，RFC 9309 第 2.2.1 節本身就寫了：爬蟲在 robots.txt 裡被比對的名字叫 product token，而標準只要求這個 token 是爬蟲實際送出的識別字串的子字串（原文：「The product token SHOULD be a substring of the identification string that the crawler sends to the service.」）。換句話說，GPTBot 這種 token 天生就只是完整 UA 的一小段。拿它當測試字串，你測的根本不是同一個東西。
OpenAI 的官方文件把三隻 bot 的完整 UA 逐字列出來了（OpenAI）：
| 爬蟲 | 官方完整 User-Agent | IP 清單 |
|---|---|---|
| GPTBot（訓練） | Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot | https://openai.com/gptbot.json |
| OAI-SearchBot（搜尋） | Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36; compatible; OAI-SearchBot/1.4; +https://openai.com/searchbot | https://openai.com/searchbot.json |
| ChatGPT-User（使用者觸發） | Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot | https://openai.com/chatgpt-user.json |
不過各家公布的顆粒度並不一致，這點很少人講。Anthropic 的官方說明頁只列出三隻 bot 的名字——ClaudeBot（訓練）、Claude-User（使用者觸發）、Claude-SearchBot（搜尋）——沒有給完整 UA 字串（Anthropic）；Cloudflare 的 AI 爬蟲對照文件同樣只列出 token（Cloudflare）。
碰到這種只給 token 的情況怎麼辦？從你自己的伺服器存取記錄撈。搜尋 log 裡含該 token 的請求，把那一行的 UA 整串複製下來當測試字串——那才是真正打到你家門口的樣子，比任何文件都準。
順著這條線還有一件事值得記住：Anthropic 在同一份說明裡明講，用封鎖 IP 的方式可能無法正確或持續達成 opt-out，因為那會妨礙它讀取你的 robots.txt（Anthropic）。想靠 IP 清單管控爬蟲的人，這句話值得抄下來。
而且 IP 清單本身是會動的。2026-08-05 我們把四份官方清單抓下來數了一遍：GPTBot 21 個網段、OAI-SearchBot 35 個、Anthropic 20 個，而 ChatGPT-User 是 289 個——且那份清單的 creationTime 就是當天。訓練爬蟲的出口穩得像石頭，使用者觸發流量的出口一直在換。手工維護 IP 白名單這條路，成本結構跟你想的不一樣。
curl -s https://openai.com/gptbot.json | python3 -c "import sys,json;print(len(json.load(sys.stdin)['prefixes']))"
要點二：要打真正的內容頁，不是首頁、不是 robots.txt
這是我們自己踩過最實在的一個坑。很多規則只掛在特定路徑上，而首頁往往是最不具代表性的那一頁。
同樣是 2026-08-05 那一輪，我們把抽樣範圍拉開，結果差異大到不解釋不行：
| 測試目標 | 狀態碼 | 回應大小 | 你實際拿到的是什麼 |
|---|---|---|---|
https://cloudinsight.cc/（首頁） | 307 | 3 bytes | 語系轉址，不是內容 |
/blog/cdn-settings（無語系前綴） | 307 | 21 bytes | 轉去 /zh/blog/cdn-settings |
/zh/blog/cdn-settings（中文內容頁） | 200 | 133,173 bytes | 完整文章 HTML |
/zh/blog/cloudflare-cdn（另一篇中文內容頁） | 200 | 134,708 bytes | 完整文章 HTML |
/en/blog/cdn-settings（英文內容頁） | 200 | 141,575 bytes | 完整文章 HTML |
看第一列。如果整份稽核只打了首頁，你會拿到 307 加 3 bytes——不是錯誤、也不是內容，什麼都證明不了。而且六種 UA 打首頁的結果完全一樣，你甚至會誤以為「測過了，沒問題」。
要看到內容，curl 得加 -L 跟著轉址走：
curl -sSL -A "$UA_GPT" -o /dev/null \
-w 'final=%{url_effective} code=%{http_code} size=%{size_download}\n' \
'https://cloudinsight.cc/blog/cdn-settings'
要點三：一定要有同時段的一般瀏覽器 UA 對照組
這是整套方法的核心，少了對照組，其他三個要點全部白做。
沒有對照組的時候，一個 403 有兩種解釋：邊緣層在擋爬蟲，或者這個站這一刻就是壞的。你分不出來。加上一組同時段的一般瀏覽器 UA，答案立刻收斂——對照組 200、爬蟲組 403，那就是 UA 造成的；兩組都 403，那是站的問題，跟爬蟲無關。
「同時段」三個字也要當真。相隔十分鐘跑的兩組結果不能拿來對照，因為中間可能剛好有一次部署、一次快取失效、一次流量尖峰。我們的做法是寫成同一支迴圈跑完，最多差幾秒。
要點四：抽樣要涵蓋各種頁型，尤其是多語系
只測一頁等於沒測。抽樣至少要涵蓋首頁、列表頁、內容頁、分頁，以及每一個語系版本。你的英文版上一次被實際打過，是什麼時候？
拿 cloudinsight.cc 自己當例子：2026-08-05 這個站有中文 365 篇、英文 369 篇，合計 734 篇文章。中文與英文是兩組不同的路徑前綴，回應大小也不同（133,173 對 141,575 bytes）。只測中文首頁，測不出英文內容頁的任何問題——而對很多站來說，英文版才是 AI 引用時真正會被抓的那一份。
最後補一句：只記狀態碼是不夠的，回應大小一定要一起記。 一個 200 配上 3 KB 的回應，多半是 JS 挑戰頁或空殼 HTML，不是你的文章。這條的重要性，本文〈判讀結果〉一節會講得更清楚。
判讀結果：403、429、503 與 200 空殼各自指向哪一層
測完之後，狀態碼就是你的地圖。每一種結果都指向不同的一層，也對應不同的下一步。
| 你看到的結果 | 意思 | 最可能發生在哪一層 | 下一步該去看哪個設定 |
|---|---|---|---|
| 403 | 存取被拒 | 邊緣層（WAF／bot 規則） | bot 防護等級、自訂 WAF 規則、fake bot 判定的例外設定 |
| 429 | 速率超限 | 邊緣層（限流） | 速率規則的閾值與計算窗口；確認爬蟲的請求頻率是否落在窗口內 |
| 503 | 來源不可用或挑戰頁 | 邊緣層與 origin 都可能 | 先看 CDN 有沒有回源錯誤紀錄，再看 origin 的健康狀態 |
| 200，但拿回 JS 挑戰頁或空殼 HTML | 狀態碼漂亮，內容沒送到 | 邊緣層的 JS 挑戰，或 origin 的前端渲染方式 | JS 挑戰／受管挑戰的開關；確認頁面是不是靠 JavaScript 才渲染出內文 |
| 3xx | 轉址 | origin 層（多半是語系或正規化邏輯） | 確認轉址目標可達，並把最終網址也納入抽樣 |
第四列是最難察覺的一種，值得單獨講。
儀表板全綠，就代表爬蟲真的讀到內容了嗎？自動化監控如果只看狀態碼，這一列會全部顯示綠燈——200 就是 200，儀表板不會有任何異狀。但爬蟲拿到的是一頁挑戰腳本或一具空殼，內文一個字都沒有。等你發現不對勁，通常已經是幾個月後在 AI 回答裡怎麼也找不到自己的內容。
怎麼分辨？把回應大小拉出來比。同一個模板的文章頁，大小應該落在同一個量級；某一次跑出來只有幾 KB，那就是它。更保險的做法是抓一段內文的固定字串下去比對：
curl -sSL -A "$UA_GPT" 'https://cloudinsight.cc/zh/blog/cdn-settings' \
| grep -c '<h1'
回傳 0 就代表這頁的標題根本沒渲染出來，不管狀態碼多好看。
測出來之後，要動哪一格？
測出 403 或 429 之後要改哪一格，取決於你的站掛在哪一朵雲、用哪個方案。CloudInsight 代理 AWS、GCP、Azure、阿里雲與騰訊雲，設定分散在多家平台時可以統一梳理，並提供台灣時區的中文技術支援。
把稽核變成常態：什麼時候該重跑、要留哪些證據
一次性的稽核只能證明「那一刻沒事」。那多久該再跑一次？邊緣層的規則會變，爬蟲的 UA 與出口 IP 也會變，所以這件事得排進固定節奏。
該重跑的時機其實很好記，全部是「有人動了某一層」的時候：
- 換 CDN 供應商，或在同一家換了方案等級
- 調整任何一條 WAF 或 bot 規則——包含以為「只影響某個路徑」的那種
- 供應商推出新版防護、或把某個功能改成預設開啟
- 網站新增語系、改路由結構，或一次上架大量新頁面
- 距離上次稽核滿一季
至於要留什麼證據，這六項一項都不能少：
| 要留的欄位 | 為什麼非留不可 |
|---|---|
| 時間（含時區） | 規則變更、快取失效都有時間點，沒有時間就無法對齊 |
| UA 全字串 | 只記「GPTBot」，事後無法重現同一次請求 |
| 完整 URL | 規則常掛在特定路徑，換一頁結果就不同 |
| 狀態碼 | 判讀的主要依據 |
| 回應大小 | 抓「200 但內容是空殼」唯一便宜的辦法 |
| 對照組結果 | 沒有它就無法歸因，這筆紀錄事後等於作廢 |
最後一列是我們最想強調的。少了對照組的紀錄，三個月後回頭看只會知道「那天爬蟲拿到 403」，卻不知道那天站本身是好是壞——歸因鏈斷在這裡，等於沒留。
要提醒的是，稽核通過只代表「爬得到」，不代表「會被引用」——可爬取是前提，不是成果。與 CloudInsight 同一團隊經營的 AI SEO Hacker 專門在做把可爬取修好之後，內容端還要做的事；伺服器端這一層清乾淨了，再往下一層走才有意義，順序反過來會白花力氣。
調完 CDN 規則之後有哪些項目需要重新驗證，可以照 CDN 設定優化教學：讓網站速度提升的 8 個做法 逐項對一遍，把可及性稽核接在那份清單後面跑，形成一個固定流程。這條軌道再往前延伸，還有兩件事會接著找上你：爬蟲帶來的頻寬與流量成本要怎麼從帳單上算出來（見 AI 爬蟲的頻寬與流量成本），以及怎麼確認來訪的「爬蟲」真的是它自稱的那一隻（見 驗證 AI 爬蟲身分的方法）。可及性、成本、身分驗證，是同一套伺服器端功課的三個面向。
圖說：稽核走成一個循環——換 CDN／改規則／上新版防護／新增頁面都要重跑，每一輪的六項證據統一歸檔
常見問題
Q: robots.txt 沒有擋 AI 爬蟲，為什麼還是抓不到我的內容？
A: robots.txt 是政策層宣告，沒有執行力；真正能在請求碰到你程式碼之前回 403 或 429 的是 CDN／WAF 那一層，而這一層的規則完全不會反映在 robots.txt 檔案上。兩者是不同系統、由不同人維護。要確認，只能用爬蟲的官方完整 UA 實際打一次內容頁，並加上同時段的一般瀏覽器 UA 對照組比狀態碼。
Q: Cloudflare 的 bot 防護預設會擋掉 AI 爬蟲嗎？
A: 要看規則掛在哪一類。Cloudflare 已把 bot 分成 Search Engine Crawler、AI Crawler、Page Preview 等 10 類，規則掛得越上層、誤傷範圍越大。它的 fake bot 管理規則寫明：User-Agent 比對到已知 bot 但來源無法驗證，就會被標記為 fake bot——真爬蟲驗證鏈沒過也會中。與其推測，不如直接測。
Q: 用 curl 帶 UA 測，跟真爬蟲來訪的結果會一樣嗎？
A: 不會完全一樣，但足以抓出 UA 這一層的差別處置，這也是最常見的落差來源。差異在於真爬蟲的來源 IP 在官方清單內、可通過反向驗證，curl 則否。所以 curl 測出 403 幾乎確定有問題；測出 200 則代表「至少 UA 這關沒被擋」，IP 與驗證鏈那層仍要另外確認。
Q: 收到 403 跟 429，處理方式一樣嗎？
A: 不一樣。403 是存取被拒，通常來自 WAF 或 bot 規則，要去查 bot 防護等級與自訂規則、必要時加例外。429 是速率超限，來自邊緣層的限流，要查的是速率規則的閾值與計算窗口，而不是封鎖清單。兩者都發生在邊緣層，但要動的設定完全不同，改錯地方不會有效果。
Q: 狀態碼是 200，為什麼還說內容沒送到？
A: 因為 200 只代表伺服器有回應，不代表回的是你的文章。JS 挑戰頁與空殼 HTML 都會回 200，但內文一個字都沒有。分辨方法是同時記錄回應大小：2026-08-05 實測中，正常的中文內容頁是 133,173 bytes，而首頁的轉址回應只有 3 bytes。只看狀態碼的監控，這一類問題會全程顯示綠燈。
結論：robots.txt 乾淨不代表爬得到，實測才算數
回到開頭那個問題：robots.txt 說可以，AI 就真的爬得到嗎？答案是不一定，而且那份檔案永遠不會告訴你答案。它管的是政策層，決定放不放行的是邊緣層，兩者不互通。
要拿到真答案，三步就夠：
第一步，用官方完整 UA 打真正的內容頁——不是首頁、不是 robots.txt。廠商沒公布完整字串的，從自己的存取記錄撈。
第二步，同時段補一組一般瀏覽器 UA 當對照組，比狀態碼，也比回應大小。兩組都不通就是站的問題，只有爬蟲組不通才是邊緣層在擋。
第三步，依狀態碼回頭查對應那一層的設定——403 與 429 去翻 bot 防護和速率規則，503 先看回源紀錄，200 但內容空殼去看 JS 挑戰與渲染方式。
這件事的成本低到不太合理：幾行 curl、幾分鐘。相比之下，內容被邊緣層默默擋掉幾個月而完全不自知，代價要大得多。與其相信一份檔案，不如相信一次實測。
當然，伺服器端的功課不只可及性一項——爬蟲進得來之後，你的伺服器扛不扛得住那些自動化流量、要不要為它們調整承載規劃，是另一條要走的路（見 AI agent 流量與伺服器承載準備）。但順序不會變：先確認爬得到，其他才有意義。
🎯 立即行動
robots.txt 是你寫給爬蟲看的，CDN 規則才是實際執行的——兩邊對不上的時候，吃虧的是你。
👉 立即諮詢，取得最適合您的方案 👉 加入 LINE 官方帳號，即時獲得技術支援
參考資料
- IETF RFC 9309《Robots Exclusion Protocol》（Standards Track，2022 年 9 月；robots.txt 的正式規格，2026-08-05 讀取）
- OpenAI 官方 bots 文件：GPTBot、OAI-SearchBot、ChatGPT-User 的完整 User-Agent 與 IP 清單（2026-08-05 讀取）
- Anthropic：Anthropic 是否爬取網頁資料、站方如何封鎖爬蟲（2026-08-05 讀取）
- Cloudflare：Fake bot 管理規則疑難排解
- Cloudflare：Verified bots 概念與驗證門檻（頁面標示 Last updated 2026-07-01）
- Cloudflare Blog：新增 AI bot 分類與 10 類 bot 類別
- Cloudflare AI Crawl Control：AI 爬蟲 user-agent token 對照
相關文章
怎麼確認來的真的是 GPTBot？2026 爬蟲身分驗證三關卡
要驗證 GPTBot 真假，比對 User-Agent 完全不夠——UA 是請求端自己填的。本文用 2026-08-05 的實測資料，示範官方 IP 清單比對、反向 DNS 雙向驗證與 Cloudflare Verified Bots 兩條門檻怎麼組成一條可稽核的判定流程，並附上可自行重現的 403／200 實測指令。
騰訊雲騰訊雲 EdgeOne 評測 2026：值得用嗎？價格、效能與 Cloudflare 完整比較
EdgeOne 是騰訊雲的邊緣加速產品，整合 CDN、DDoS 防護、WAF。本文用最新官方定價（含免費方案）重新分析：進階防護等級 EdgeOne Standard 要 $590/月，比 Cloudflare Business $200 貴，EdgeOne 的價值在亞太與中國覆蓋而非價格。
CDNAI 爬蟲吃掉多少頻寬？2026 從自家 CDN log 算出成本再決定限流
AI 爬蟲頻寬成本沒有業界平均值可抄，2026 年唯一可信的數字是你自己帳單上那一個。本文說明爬蟲流量為何集中打在回源、log 該留哪五個欄位、四步驟怎麼把 response bytes 換算成回源 GB，再對照 CDN 帳單找出真正被計費的那一項，並說明為何先設速率限制比直接封鎖更務實。