首頁 / 技術文章 / AI 爬蟲身分驗證：Googlebot 通過 DNS 或 IP 比對後，還要判斷流量類別
技術文章
AI 爬蟲身分驗證：Googlebot 通過 DNS 或 IP 比對後，還要判斷流量類別
請求通過 DNS 或 IP 驗證後，網站仍須判斷流量類別，以及該類流量是否遵守 robots.txt，才能決定放行、限速或封鎖。驗證結果應保留分類依據，讓存取政策有足夠資訊可用。
來源屬實，不代表已經具備放行條件
日誌中的 User-Agent 是請求宣稱的身分，不能單獨當成認證依據。Google 官方驗證文件提供 DNS 與 IP 網段比對方式，目的就是協助網站辨識冒充 Google 的請求。對網站而言，這項驗證回答的是來源是否符合官方公布的依據，還沒有回答這次存取應獲得什麼權限。
關鍵差異在 Google 自己的分類。依官方文件，Common crawlers 在自動抓取時一律遵守 robots.txt；Special-case crawlers 不一定遵守；User-triggered fetchers 則忽略 robots.txt。因此，即使來源驗證同樣成功，網站仍不能對所有 Google 流量套用相同的放行理由。
本站的判斷是，驗證程式應輸出來源驗證結果、流量類別與比對依據，再由存取政策決定處置。只回傳真或假，會丟掉最能影響權限的資訊：到底是搜尋爬蟲、特殊用途爬蟲，還是使用者觸發的抓取。
Google 各類爬蟲與 Bingbot 的驗證依據對照
下表將流量類別放進反向 DNS 欄，並列 IP 清單與 robots.txt 行為。Google 的分類與檔名依據官方驗證文件；Bing 的 DNS 步驟來自2012 年官方文章。表中的星號表示主機名稱樣式，不是可以直接套用的驗證程式。
| 流量類別與反向 DNS 樣式 | 對應 JSON 網段檔 | robots.txt 遵守程度 |
|---|---|---|
| Google Common crawlers，例如 Googlebot：crawl-*.googlebot.com、geo-crawl-*.geo.googlebot.com | common-crawlers.json | 自動抓取時一律遵守 |
| Google Special-case crawlers，例如 AdsBot：rate-limited-proxy-*.google.com | special-crawlers.json | 不一定遵守 |
| Google User-triggered fetchers，由 Google 控制：google.com 下的主機名稱 | user-triggered-fetchers-google.json | 忽略 |
| Google User-triggered fetchers，另一組 IP：gae.googleusercontent.com 下的主機名稱 | user-triggered-fetchers.json | 忽略 |
| Bingbot：search.msn.com 下的主機名稱；仍須正向解析確認原 IP | 本文未確認現行清單 | 本文引用的驗證資料不足以確認 |
| OpenAI：GPTBot、OAI-SearchBot、ChatGPT-User 的反向 DNS 設定未確認 | 各爬蟲的確切檔名、格式與更新頻率未確認 | 本文不據此推定 |
Google 的使用者觸發流量尤其需要分清楚。官方文件將它分成不同 IP 組別，其中 user-triggered-fetchers.json 對應的主機名稱位於 gae.googleusercontent.com，並以 Google Cloud 上的網站代使用者發出請求為例。據此判斷，來源落在 Google 相關基礎設施，不能直接推導成 Google 本身正在執行搜尋索引爬取，也不宜自動繼承 Googlebot 的權限。
驗證邏輯應依序處理來源、分類與存取政策
- 驗證來源：採 DNS 方式時，先反向解析來源 IP，再確認主機名稱符合業者公布的網域或樣式，最後正向解析，確認結果包含原 IP；採 IP 方式時，比對業者公布的網段清單。
- 保留分類證據：記錄命中的清單檔名或完整主機名稱樣式，再據此判定流量類別。若證據不足，應保留未知狀態。
- 套用存取政策：依類別判斷 robots.txt 是否適用，再結合網站對內容、用途與流量負載的要求，決定放行、限速或封鎖。
上述 DNS 與 IP 方法有Google 官方文件作為依據；保留分類證據則是實作建議。例如，來源 IP 命中 special-crawlers.json 時，驗證結果應保留 Special-case crawlers 類別，而非只留下 Google 來源屬實。後續規則才有辦法知道，不能假設這類流量一律受 robots.txt 約束。
分類時也應避免過早使用寬泛條件。只接受 googlebot.com，依官方分類會漏掉其他真實的 Google 流量；只記錄 google.com，又不足以區分特殊用途與部分使用者觸發流量。較合理的實作是先比對具體樣式或分類清單，保留證據，無法細分時不要猜測。
例如，網站若允許自動搜尋爬取，可以對已確認的 Common crawlers 開放指定內容；對使用者觸發抓取，則另行決定是否允許存取同一路徑。這是政策設計示例，並非官方要求。對內容出版商而言，身分驗證可作為差別授權的前提，但來源可信本身不應被解讀為已有內容使用授權。
robots.txt 管抓取規則，存取權限仍須另外決定
RFC 9309規範 Robots Exclusion Protocol，內容涵蓋規則語法、錯誤處理與快取。從這個範圍來看，robots.txt 應被放在抓取規則層，不能拿來取代請求來源的認證。網站若要理解兩者如何配合，可延伸參考以 robots.txt 區分 AI 搜尋與訓練的限制。
Google 的 User-triggered fetchers 忽略 robots.txt，是該業者文件對特定類別的說明，不宜延伸為所有 AI 助理的共同規則。網站若判定某類請求不得取得內容，建議在實際處理請求的存取控制層執行封鎖；若接受用途但希望控制負載，則另設限速條件。這些取捨應寫進網站的代理存取政策，避免由驗證成功自動推導出全面放行。
對產品與行銷團隊而言，也應避免把通過驗證視為取得搜尋曝光的承諾。這套判斷的用途是決定請求如何被處理；至於內容能否被取得、後續是否被引用，仍是不同問題，可對照AI 搜尋取得網頁的不同關卡分別檢查。
常見陷阱：單向 DNS、過寬網域與失去分類資訊
反向解析得到看似正確的名稱，仍不算走完 DNS 驗證。Bing 官方步驟要求再以該名稱正向解析，確認回到原 IP。實作上也建議精確處理網域邊界，例如示意名稱 googlebot.com.example.com 不應因為含有 googlebot.com 就通過。
另一個陷阱是把驗證失敗直接標成惡意冒充。建議將未通過、查詢失敗與尚無可用驗證依據分開記錄，再由網站設定相應處置。這樣即使最後採取相同的限速策略，維運人員仍能分辨原因，避免把資料不足當成已確認的攻擊。
Cloudflare Verified Bots 文件提供另一個實務邊界：它可透過公開 IP 清單或指定網域的反向 DNS 進行 IP 驗證；公開清單須符合 IP 組合固定且有限、供業者本身使用等條件，並提供 User-Agent 比對樣式。據此推測，共享雲端 IP 的業者可能較難滿足這條驗證路徑，但不能因此把所有共享雲端請求判定為不可信。
本文的依據與限制
Bing 的來源是歷史驗證說明，本文未確認其現行網域與 IP 清單是否另有變更，部署前仍應核對現行官方資料。對OpenAI 爬蟲文件，本文可用內容不足以確認各爬蟲的 IP 清單檔名、格式、更新頻率及反向 DNS 設定，因此保留未知欄位，也不把 Google 的分類或 robots.txt 行為套用過去。
DNS 與 IP 比對的選擇，建議以業者實際公開的驗證依據為準。若使用清單，應設計更新與失敗處理；若使用 DNS，可評估快取結果，降低逐次查詢可能帶來的負擔。無論採哪一種，都應保留比對依據，讓規則調整時能追溯分類原因。
網站下一步最值得檢查的，是驗證結果能否直接支援權限決策。若系統只留下已驗證，卻沒有流量類別與命中依據，就仍不足以支援細緻的放行規則。來源可信、用途可接受、存取條件符合，應各自成立；分類未知的請求，則應留在網站明確設定的未知流量政策內。
常見問題
反向 DNS 查到 googlebot.com，就可以放行嗎？
還不夠。Google 的 DNS 驗證方式還要求正向解析該主機名稱，確認結果包含原 IP。驗證成功後，仍應依流量類別與網站政策決定權限。
真實的 Google 流量都會遵守 robots.txt 嗎？
不會。依Google 官方分類，Common crawlers 在自動抓取時一律遵守，Special-case crawlers 不一定遵守，User-triggered fetchers 則忽略 robots.txt。
只接受 googlebot.com 的驗證規則有什麼問題？
若目標是辨識所有 Google 爬蟲與 fetcher，這個範圍太窄。官方文件也列出 google.com 與 gae.googleusercontent.com 下的主機名稱；應依具體樣式或對應網段檔分類，避免把其他真實流量誤判為冒充。
GPTBot 可以照 Googlebot 的方式做雙向 DNS 驗證嗎？
本文無法確認。可用的OpenAI 文件內容不足以確認反向 DNS 設定，也不足以列出各爬蟲的確切 IP 清單檔名與格式，不宜自行推定驗證網域。