首頁 / 技術文章 / AI 爬蟲收到 403：先分清 robots.txt 與內容頁的拒絕
技術文章
AI 爬蟲收到 403：先分清 robots.txt 與內容頁的拒絕
對 /robots.txt 回應 403，不能當成已經封鎖內容頁；它首先影響的是爬蟲能否讀取存取規則。至於遵守 RFC 9309 的爬蟲會如何處理，必須核對錯誤處理條文，不能把讀不到規則直接解讀成禁止抓取。
robots.txt 與內容頁收到 403，代表不同的控制位置
判斷封鎖是否有效，第一個問題應該是：被拒絕的請求要讀取什麼？如果目標是 /robots.txt，網站擋住的是存取規則；如果目標是文章頁，網站才是在該次內容請求上執行拒絕。兩者即使呈現相同狀態碼，也不適合用同一個封鎖結果概括。
RFC 9309 是 Robots Exclusion Protocol 的正式規格，涵蓋協定定義、錯誤處理與快取指引。robots.txt 的作用仍以爬蟲遵守規則為前提。從控制方式判斷，Disallow 是交給爬蟲解讀的限制；內容端的拒絕則應由網站的存取控制執行。設定前者，不能取代驗證後者。
因此，若網站希望同時表達禁止抓取的意願，並阻止指定請求取得內容，合理的配置目標是讓爬蟲讀得到適用規則，再由內容頁的存取政策執行拒絕。不能只看到日誌裡出現拒絕回應，就推定文章已受到同樣保護；檢查時必須把請求路徑一起納入。
robots.txt 讀不到之後，不能自行推定爬蟲會停止
需要防範的情境是：WAF 依 user agent 套用封鎖，連 /robots.txt 也一起拒絕。如果爬蟲對這類錯誤採取視為沒有可用限制的處理，網站原本寫在檔案裡的 Disallow 就無法透過這次請求傳達。這是規則被擋住後可能出現的反效果，不能把它誤認為多加了一道內容保護。
同樣需要保留的，是規範允許的行為與個別產品實際行為之間的差距。即使確認了 RFC 條文，也不能直接推論每家 AI 業者的重試頻率、既有索引處理或後續抓取方式。沒有業者文件或可驗證紀錄時，這些實作細節應維持未確認。
403、404、5xx 與逾時：應分別核對哪些行為
以下對照的是 /robots.txt 請求的檢查重點。表格不替尚未核對的規範條文補上答案，而是區分網站需要確認的分支，避免把所有讀取失敗一律當成禁止抓取。規範依據應回到 RFC 9309 原文。
| 請求結果 | 需要核對的爬蟲行為 | 網站端檢查重點 |
|---|---|---|
| 403 | 是否允許視為沒有可用限制；不可直接認定爬蟲會停止 | 是否有 WAF 或 CDN 規則把 robots.txt 一起拒絕 |
| 404 | 是否與其他 4xx 採相同處理，以及適用條件 | 預定提供的 robots.txt 是否存在於正確位置 |
| 5xx | 是否須暫停抓取、採取限制，或使用既有規則 | 錯誤出現於哪個服務環節，以及恢復後的回應 |
| 逾時 | 網路錯誤如何分類，以及後續重試與快取處理 | 請求在哪個環節未完成，是否只影響特定請求 |
重新導向與快取也應分開查核。若 robots.txt 會轉往另一個位置，建議記錄完整路徑及最終回應，再核對規格對重新導向的要求。若網站剛修改規則，則應確認爬蟲是否仍可能採用先前取得的版本。跳轉次數、快取期限與錯誤持續期間的處理，都不宜從規格摘要推定。
檢查方法：用同一個 user agent 分別請求規則與內容
實務檢查可以先回答一個範圍較小、也更容易驗證的問題：網站對指定請求究竟回了什麼？建議選定要管理的爬蟲，使用經確認的 user agent，對規則檔與代表性內容頁分別發出請求。測試紀錄應保留路徑、回應狀態與回應內容，避免只留下單一狀態碼。
- 先寫下預期政策：該爬蟲應能讀取哪些規則、哪些內容應拒絕、哪些內容應允許。
- 以指定 user agent 請求 /robots.txt，確認取得的是預期規則內容；如果收到拒絕、其他頁面或重新導向，記錄完整結果。
- 以相同 user agent 請求代表性內容頁，分別檢查應允許與應拒絕的路徑，不用規則檔的結果代替內容頁結果。
- 對照 CDN、WAF 與伺服器端的設定和日誌，找出實際產生回應的環節，再調整 robots.txt 的存取例外。
- 修改後重做相同請求，並分開追蹤真正爬蟲的後續流量；不要把模擬請求成功當成爬蟲已採用新政策。
這種測試適合驗證指定條件下的網站回應，不宜擴大解讀為爬蟲身分已獲確認。若封鎖策略需要依賴身分判斷，可延伸參考爬蟲身分與流量類別的查核方式。編輯上的建議是把身分驗證、規則傳達與內容存取分開驗收，避免一個檢查結果替其他環節背書。
封鎖是否有效，還要看目標是存取、引用或流量
robots.txt 本身也有遵守程度的限制。Search Engine Journal 經 Digiday 轉述 Tollbit 報告指出，AI 爬蟲抓取中有 30% 未遵守 robots.txt 的明確權限設定。這是報告對抓取行為的統計，不能改寫成有相同比例的爬蟲業者一律不守規則，也不代表每個網站都會遇到同樣情況。
對內容經營者而言，這支持把規則宣告與存取控制分別管理的判斷：前者是否能被讀取、後者是否真的拒絕內容，需要各自驗證。即使兩項檢查都符合預期，也不應直接承諾內容不再出現在 AI 回答裡。
PPC Land 轉述的 BuzzStream 研究顯示，多數受研究、封鎖特定 AI 爬蟲的大型新聞網站仍被 AI 系統引用。這項結果不能證明某次請求成功繞過封鎖，也不能確認引用來自哪個管道。它能提醒經營者的是：拒絕抓取與停止引用，應該使用不同指標衡量。
流量影響也不適合只靠拒絕回應判斷。SEJ 引述 Digiday 報導，Reuters 表示改採預設封鎖後沒有流量損失，並降低服務爬蟲的成本。這是單一出版商的說法，不能成為所有網站的效果保證。對 AEO／GEO 決策，更合適的做法是先區分爬蟲用途，再分別觀察取得內容、引用與導流；相關配置可參考搜尋與訓練用途分開管理的做法。
配置判斷：讓規則可讀，再驗證內容端的拒絕
如果網站的目標是傳達禁止抓取的規則，同時執行內容存取限制，較穩妥的配置方向是讓 robots.txt 保持可讀，並在內容端驗證拒絕是否符合政策。若發現 WAF 連規則檔也擋住，應先檢查它是否破壞了原本的規則傳達目的。
真正需要驗收的成果，是指定爬蟲能讀到預定規則、指定內容按政策允許或拒絕，以及搜尋曝光沒有偏離經營目標。至於 robots.txt 的錯誤回應如何觸發 RFC 的處理分支，應在核對條文後再下結論；讓規則無法讀取，不應被當作封鎖已完成的證據。
常見問題
robots.txt 回應 403，代表整個網站都禁止 AI 爬蟲存取嗎？
不能這樣判斷。它首先表示規則檔的請求遭到拒絕，內容頁是否也被拒絕必須另外檢查。至於爬蟲依 RFC 9309 如何處理這種錯誤，不能僅憑規格摘要確認。
已經用 WAF 封鎖爬蟲，還需要讓它讀取 robots.txt 嗎？
若仍希望透過 robots.txt 傳達存取規則，建議讓規則檔可讀，再於內容端執行拒絕。應分別驗證規則傳達與內容封鎖，避免 WAF 把原本希望提供的規則一起擋住。
換成爬蟲的 user agent 測試，就能確認真正爬蟲的行為嗎？
這適合檢查網站對指定請求的回應，不足以確認真正爬蟲的身分、快取狀態或後續行為。建議把模擬請求結果與經身分查核的實際流量分開判讀。
內容頁拒絕抓取後，AI 就不會再引用網站嗎？
不能保證。PPC Land 轉述的 BuzzStream 研究顯示，多數受研究、封鎖特定 AI 爬蟲的大型新聞網站仍被引用；但研究結果不能確認引用管道，也不能直接推論到所有網站。