網站對AI（人工智能）爬蟲友好嗎？10項檢查清單

在robots.txt裏寫上Allow，只能説明訪問規則允許相應爬蟲進入，不能證明網站已經被抓取、收錄或引用。

AI爬蟲是搜尋平台或人工智能平台用來訪問網頁、讀取內容的程序。robots.txt則是放在網站根目錄下、用於聲明爬蟲訪問規則的文本文件。要判斷一個網站是否對AI爬蟲友好，至少要回答五個問題：

• 目標URL（網頁地址）能否公開訪問？
• 搜尋抓取、模型訓練和用戶發起的訪問，是否分別配置了規則？
• CDN（內容分發網絡）和WAF（網站應用防火牆）是否誤攔了合法請求？
• 伺服器返回的原始HTML（網頁源代碼的主要格式）裏是否包含正文？
• 伺服器或CDN日誌能否證明真實請求已經成功？

即使這五項全部通過，也只能説明網站具備被訪問和讀取的條件，不能保證任何平台一定抓取、收錄、引用或推薦。

先分清四種結果

檢查網站之前，必須先區分四種不同的結果：

1. 規則允許訪問：robots.txt沒有禁止相應爬蟲訪問目標頁面；
2. 模擬請求成功：使用測試工具或命令行，可以正常取得頁面內容；
3. 真實請求成功：伺服器或CDN日誌中出現經過驗證的平台請求，併成功返回內容；
4. 頁面被實際引用：平台已經在搜尋結果或AI回答中使用該頁面。

這四種結果逐級遞進，但前一項成立，不代表後一項已經發生。尤其不能把“robots.txt允許訪問”直接寫成“已經被AI收錄”。這裏的“索引”，是指平台把頁面納入可以檢索的資料庫。

還要注意，robots.txt不是保護私密內容的安全工具。真正不應公開的資料，必須通過賬號權限、密碼或其他訪問控制進行保護。

10項檢查總表

序號	檢查項	合格狀態	常見問題
1	公開訪問	目標網頁無需登錄，最終返回成功狀態	登錄限制、地區限制、驗證碼
2	robots.txt	根目錄文件可以訪問，規則明確且沒有衝突	文件不存在、規則寫錯、全站禁止訪問
3	用戶代理	按搜尋、訓練和用戶發起訪問分別配置	把同一平台的所有爬蟲統一放行或屏蔽
4	CDN與WAF	合法請求不會被挑戰或誤封	只檢查robots.txt，沒有檢查安全策略
5	HTML正文	原始響應包含標題、正文和主要連結	內容完全依賴JavaScript加載
6	索引信號	noindex、canonical等設置沒有衝突	允許抓取，卻同時禁止索引
7	站內發現	重要頁面有穩定入口，並進入站點地圖	頁面只能通過直接地址訪問
8	資源訪問	正文依賴的資源可以正常讀取	數據接口、腳本、圖片或文件返回403
9	日誌驗證	可以核對請求身份、來源地址、狀態碼和響應量	只憑模擬工具作出結論
10	訪問穩定性	錯誤率和訪問頻率限制處於可控狀態	頻繁出現伺服器錯誤或請求過多

一、目標頁面是否真正公開

先在未登錄、沒有站點Cookie的環境中訪問目標網頁。Cookie是瀏覽器保存登錄狀態和訪問資訊的小型數據。

合格狀態至少包括：

• HTTPS連接正常。HTTPS是經過加密的網頁傳輸方式；
• 經過必要跳轉後，頁面最終返回200。200是HTTP網頁傳輸協議中的成功狀態碼；
• 閲讀正文不需要登錄賬號；
• 頁面不會跳轉到驗證碼、地區提示、年齡確認或客戶端下載頁。

不要只測試首頁。產品頁、文章頁和文檔頁等不同頁面類型，都應分別抽查。首頁可以打開，不能證明站內其他頁面也能正常訪問。

同時要記錄完整的重定向過程。重定向是伺服器把一個網頁地址自動轉到另一個地址。HTTP跳轉到HTTPS、舊域名跳轉到新域名可以存在，但不能循環跳轉，也不能因為訪問者身份不同而返回沒有正文的頁面。

計劃公開的頁面如果返回以下狀態，應先解決訪問問題，再判斷網站是否對AI爬蟲友好：

• 401：需要身份驗證；
• 403：伺服器拒絕訪問；
• 404：頁面不存在；
• 410：頁面已經刪除；
• 429：請求過於頻繁；
• 5xx：伺服器端發生錯誤。

二、robots.txt能否訪問，規則是否清楚

robots.txt應放在網站根目錄，也就是域名下的固定位置，例如：

https://example.com/robots.txt

檢查時重點確認三件事：

1. 文件可以直接訪問，沒有被登錄驗證或防火牆攔截；
2. 通用規則中沒有誤寫Disallow: /。Disallow表示禁止訪問，後面的/表示全站；
3. 單獨為某類爬蟲設置的規則，與通用規則沒有衝突。

規則中的User-Agent是用戶代理標識，也就是請求方用來聲明自己身份的文字字段。Allow表示允許訪問相應路徑，但它只負責表達訪問規則，不能代替權限控制。

Google官方説明，robots.txt主要用於管理抓取流量，不是可靠的去索引方法。一個被禁止抓取的網頁，如果被其他頁面連結，仍可能以沒有摘要的形式出現在搜尋結果中。

因此，真正私密的內容必須通過權限或密碼保護，不能只依賴Disallow。

三、是否按爬蟲用途分別配置

“AI爬蟲”不是一個統一開關。同一家平台可能分別設置搜尋抓取、模型訓練和用戶發起訪問等用戶代理。用途不同，網站的管理決定也可以不同。

企業可以允許搜尋相關爬蟲訪問公開頁面，同時根據自身政策限制模型訓練用途。具體配置應以平台當前發佈的官方説明為準，不要長期照搬舊名單。

下表中的英文名稱，都是各平台公開的用戶代理標識：

平台與用戶代理	公開用途	自查重點
OpenAI OAI-SearchBot	用於ChatGPT搜尋結果	搜尋頁面是否允許訪問，WAF是否放行官方IP地址
OpenAI GPTBot	可能用於模型訓練的內容抓取	是否符合公司的訓練數據政策
OpenAI ChatGPT-User	用戶發起的頁面訪問	不要把它理解為自動索引爬蟲
Anthropic ClaudeBot	模型開發內容收集	與搜尋用途分開決定
Anthropic Claude-User	用戶請求觸發取回	目標頁面能否正常響應用戶訪問
Anthropic Claude-SearchBot	搜尋質量與索引	搜尋相關頁面是否被誤攔
PerplexityBot	用於Perplexity搜尋結果	robots.txt和WAF是否允許訪問
Perplexity-User	用戶發起的頁面訪問	官方説明其通常不受robots.txt規則限制，應重點檢查WAF和頁面權限

OpenAI分別設置了OAI-SearchBot、GPTBot和ChatGPT-User，搜尋與訓練設置相互獨立。Anthropic公開列出了ClaudeBot、Claude-User和Claude-SearchBot。Perplexity則區分PerplexityBot與Perplexity-User。

配置完成後，建議保留一份帶日期的決策表，至少記錄：

• 允許哪些用戶代理；
• 允許或限制哪些路徑；
• 每項決定依據哪份官方文檔。

平台的用戶代理和管理規則可能變化，robots.txt也應保留版本記錄，便於後續複查。

四、CDN、WAF和其他安全策略是否誤攔

robots.txt表達的是網站對爬蟲訪問的管理規則。請求最終能否取得頁面，還取決於CDN、WAF、主機防火牆、反爬策略和應用網關。

常見誤攔包括：

• 把所有非瀏覽器請求都判定為機器人；
• 強制執行JavaScript挑戰。JavaScript是網頁常用的腳本語言，這類挑戰通常要求瀏覽器先運行一段程序；
• 按國家或地區封鎖IP地址。IP地址是設備或伺服器在網絡中的地址；
• 把數據中心的IP地址全部列入黑名單；
• 請求稍微集中就返回429。

這就是為什麼robots.txt明明允許訪問，伺服器日誌裏仍可能出現403。

檢查時不能只按User-Agent字符串放行，因為這個字符串可以偽造。Perplexity官方建議WAF同時校驗User-Agent和官方IP範圍；OpenAI也提供搜尋爬蟲與訓練爬蟲的公開IP入口。

IP清單應從平台官方地址獲取，並定期更新。

五、原始HTML是否包含主要內容

瀏覽器裏能看到正文，不代表伺服器直接返回的HTML裏也有正文。

檢查頁面時，除了查看瀏覽器最終顯示的內容，還要通過“查看源代碼”或命令行請求，核對伺服器返回的原始HTML。頁面標題、正文、關鍵參數、作者、日期和主要內部連結，至少應有核心部分直接出現在響應中。

如果HTML只有基礎頁面結構和大量腳本地址，正文全部依靠JavaScript運行後加載，部分抓取器就可能無法取得可用內容。

這並不意味着網站必須停用JavaScript。真正需要確認的是，準備公開的事實有沒有穩定的伺服器輸出。網站可以採用以下方式，讓抓取器在原始響應中讀到主要內容：

• 服務端渲染：由伺服器先生成包含正文的完整網頁；
• 靜態生成：提前生成可以直接訪問的網頁文件；
• 預渲染：在訪問前準備好可讀取的頁面內容。

檢查時不要只看頁面能否正常顯示，還要直接搜尋原始響應中是否存在關鍵文字和連結。

六、索引信號是否互相沖突

允許抓取，不等於允許索引。

以下設置都可能造成衝突：

• HTML中存在meta robots noindex。這是寫在網頁源代碼中的“不要索引”指令；
• HTTP響應頭包含X-Robots-Tag: noindex。響應頭是伺服器隨網頁一起返回的説明資訊，這項設置同樣表示不要索引；
• canonical指向錯誤地址。canonical是規範地址標記，用來説明哪個網頁地址應被視為主要版本；
• 正式頁面被標記為測試頁或其他頁面的副本。

如果canonical指向錯誤頁面，平台可能不會把當前網頁作為主要版本處理。

重點頁面需要分別檢查HTML、HTTP響應頭和規範地址，不能只看robots.txt。

如果目標是讓爬蟲讀取頁面上的noindex，就不能同時在robots.txt中阻止訪問。Google明確提醒：頁面被robots.txt攔截後，爬蟲無法讀取頁面裏的noindex。其他平台如何處理，應以各自官方文檔為準。

七、重要頁面能否被站內發現

重要頁面不能只存在於後台數據庫、站內搜尋結果或臨時分享連結中。如果站內沒有普通連結指向它，爬蟲就可能無法穩定發現這個頁面。

應從首頁、欄目頁、產品頁或文檔目錄建立可以直接訪問的連結，並在XML站點地圖中列出希望被發現的規範網頁地址。XML站點地圖是一份按固定格式整理的網站頁面清單，供爬蟲發現網頁。連結文字應説明目標頁面的內容，不要全部寫成“點擊這裏”。

檢查沒有站內入口的孤立頁面時，要反查頁面入口，並逐項核對站點地圖中的地址：

• 是否返回200；
• 是否指向正式域名；
• 是否混入測試頁面；
• 是否包含已經刪除的頁面。

站點地圖可以幫助爬蟲發現頁面，但不能保證頁面一定被收錄。

八、正文依賴的資源能否正常訪問

有些頁面的HTML返回200，但正文需要通過數據接口加載，而接口對機器人返回403；有些關鍵説明只存在於圖片、摺疊組件或下載文件中；還有些樣式文件和腳本被安全策略攔截，導致頁面結構無法正常解析。

因此，除了頁面本身，還要檢查以下資源的狀態碼：

• 正文數據接口，也就是供網頁程序獲取內容的地址；
• 主要圖片；
• PDF等下載文件。PDF是一種常見的電子文檔格式；
• 結構化數據接口，也就是按固定字段向程序提供資訊的接口；
• 頁面依賴的腳本資源。

關鍵事實不要只放在圖片裏。名稱、參數、適用範圍和限制條件，應同時出現在可以讀取的文字中。下載文件最好配有HTML摘要頁和穩定的下載地址。

九、日誌能否證明真實訪問成功

伺服器或CDN日誌，是確認真實訪問情況的重要依據。日誌是系統自動保存的請求記錄。

日誌至少應記錄：

• 請求時間；
• 訪問路徑；
• User-Agent；
• 來源IP地址；
• HTTP狀態碼；
• 響應字節，也就是伺服器實際返回的數據量；
• 處理耗時。

分析時，應先通過官方IP範圍或平台提供的驗證方式確認請求身份，再檢查對方訪問了哪些頁面、取得了什麼狀態碼、是否反覆失敗，以及伺服器實際返回了多少內容。

第三方工具只能證明模擬請求可以訪問，不能證明真實平台已經抓取。最終報告必須明確證據處於哪個階段：規則允許、模擬成功、真實請求成功，還是已經被平台引用。

十、訪問頻率和錯誤率是否穩定

對爬蟲友好，不等於完全不設限制。網站可以設置合理的訪問頻率限制，但不應讓正常抓取長期收到429、503或挑戰頁面。503表示伺服器暫時無法提供服務。

如果錯誤連續出現，應檢查：

• 伺服器容量是否足夠；
• 緩存策略是否合理。緩存是提前保存可以重複使用的內容，以減少伺服器重複處理；
• 安全規則的優先級是否正確；
• 頁面依賴的上游接口是否穩定。

修改robots.txt或WAF後，也不能只測試一次。OpenAI説明，搜尋相關的robots.txt調整可能需要約24小時生效。其他平台如果沒有公開生效週期，不要自行設定固定時限。

最終判定：紅牌、黃牌還是綠牌

狀態	判定	處理方式
紅牌	目標頁面不公開、全站誤攔、HTML沒有正文，或重點頁面持續返回403、5xx	暫停作出“對AI爬蟲友好”的結論
黃牌	robots.txt已經配置，但WAF、索引信號、站內發現或日誌證據不完整	補齊檢查後重新測試
綠牌	頁面、規則、安全層、HTML、索引信號、站內連結、依賴資源和日誌均可複核	進入持續監測

判斷網站是否對AI爬蟲友好，不能只看robots.txt。公開訪問、爬蟲規則、安全策略、頁面內容、索引信號、站內連結、依賴資源和日誌證據必須相互對應，才能確認網站具備穩定的爬蟲訪問條件。

即使獲得綠牌，也不能寫成“保證收錄”或“保證引用”。技術檢查只能回答網站能否被訪問、內容能否被讀取。頁面最終是否被發現、索引、引用或推薦，還取決於內容相關性、證據質量、平台機制和用戶提出的問題。

常見問題

1. robots.txt寫了Allow，就算對AI爬蟲友好嗎？

不算。Allow只解決訪問規則中的一部分。還要檢查頁面是否公開、WAF是否放行、原始HTML中有沒有正文、noindex與canonical是否衝突、依賴資源能否讀取，以及真實請求是否在日誌中成功返回。

2. 所有AI用戶代理都應該放行嗎？

不是。企業應先區分搜尋、模型訓練和用戶發起的訪問，再根據內容公開範圍、合規要求和公司政策分別決定。公開官網和私有客戶區不應採用同一套規則。

3. ChatGPT-User和OAI-SearchBot有什麼區別？

OAI-SearchBot用於ChatGPT搜尋結果；ChatGPT-User用於某些由用戶發起的頁面訪問，不是自動網絡抓取器。OpenAI官方説明，兩者的設置相互獨立，用戶發起的訪問對robots.txt的適用方式也可能不同。

4. 為什麼robots.txt允許了，日誌仍然返回403？

常見原因是CDN、WAF、地區限制、驗證碼、登錄限制或應用權限在後續環節攔截了請求。應核對真實IP地址、User-Agent、命中的安全規則和最終響應內容，不能只檢查robots.txt。

5. 頁面主要依靠JavaScript加載，一定不行嗎？

不能一概而論。不同平台處理JavaScript的能力可能變化，但原始HTML中沒有核心正文，會增加抓取和解析的不確定性。重點事實由伺服器直接輸出，並通過命令行請求驗證返回內容，更便於檢查。

6. 技術檢查全部通過，多久會被AI引用？

沒有統一時限，也沒有保證。技術檢查通過，只表示網站具備被訪問和讀取的條件。是否被發現、索引、引用或推薦，還取決於內容相關性、證據質量、平台機制和用戶提出的問題。

公開資料入口

• OpenAI Crawlers
• Anthropic爬蟲説明
• Perplexity Crawlers
• Google robots.txt指南
• Google生成式AI搜尋指南