爬蟲的 User-Agent 可以隨意偽造。本文說明網站如何核實一個自稱 Googlebot 的爬蟲是否真實：反向 DNS、IP 範圍、簽章與營運方註冊表。
User-Agent 標頭就是一段純文字，任何指令碼都可以把它設成 Googlebot/2.1 (+http://www.google.com/bot.html)，沒有任何機制能阻止這麼做。爬蟲偽裝者經常這麼做，為的就是繞過那些只看這一個欄位的簡單機器人過濾器。與此同時，真正的 Googlebot、Bingbot 以及其他數十個正規爬蟲，也確實是用同一個欄位來自報身分的。一個想對「Googlebot」另眼相待的網站，得先回答一個問題：這個請求究竟是不是真的來自 Google，還是只是有人打對了那幾個字？
核心要點
- User-Agent 中聲明的身分本身不能證明任何事——它是純文字，複製一個真實爬蟲的字串對任何想冒充它的人來說都只是一行程式碼的事。
- 正反雙向確認的反向 DNS（forward-confirmed reverse DNS） 是最經典的檢測方式：先查出來源 IP 由誰控制，再用營運方自己發布的 DNS 記錄反過來確認這個答案。
- 營運方公開發布的 IP 範圍清單 是一種更快、成本更低的替代方案（對維護這類清單的營運方而言），代價是更新之間存在陳舊的空窗期。
- 密碼學簽章（RFC 9421 / Web Bot Auth） 用證明取代推斷：一個通過驗證的簽章，展示的是「哪把金鑰簽署了這個請求」，而不只是「這個請求來自哪個網路」。
- 營運方註冊表是最新出現的選項——Cloudflare 的 BotBase 讓營運方自行註冊一個身分供網站直接查詢，而註冊表本身會替網站把 DNS、IP 範圍與簽章這幾道檢測重新跑一遍。
- 這四種方法核實的對象各不相同，失效的方式也各不相同，所以弄清楚一個網站究竟依賴哪一種檢測，和弄清楚它是否存在檢測本身同樣重要。
聲明是免費的，證明卻不是
以下每一種檢測手段存在的原因都指向同一個缺口：User-Agent 只是用戶端對自己身分的一句聲明，而用戶端可以聲明任何內容。一般瀏覽器同樣如此——我們關於偵測 User-Agent 偽裝的文章講的正是這個問題在瀏覽器一側的表現——但一個自稱身分的爬蟲風險更高，因為信任「Googlebot」的網站往往會給它一些絕不會給匿名訪客的待遇：不限速存取、繞過付費牆，或直接跳過驗證頁面。核實這個聲明，而不只是讀取它，正是本文要講的全部內容。
方法一：正反雙向確認的反向 DNS
這是最古老、至今仍被廣泛使用的檢測方式，分兩步進行——省略第二步，正是讓第一步變得毫無意義的常見錯誤。
第一步——反向查詢。 取出請求的來源 IP 位址，查詢它的 PTR 記錄，PTR 記錄會把一個 IP 映射回一個主機名稱。如果這確實是 Google 的爬蟲，這個主機名稱應該以 googlebot.com、google.com 或 googleusercontent.com 結尾——這三個網域正是 Google 官方核實文件告訴站長可以認可的。
第二步——正向確認。 光靠第一步得到的主機名稱還什麼都證明不了，因為 PTR 記錄是由掌管該 IP 位址所屬反向 DNS 區域的人來控制的——而不是由你希望是誰在營運這個位址來決定。RFC 1912 正是記錄了這類 DNS 設定錯誤與濫用風險，而 RFC 8499 裡的 DNS 術語定義也在結構上說明了同一點：所謂反向 DNS，不過是由 IN-ADDR.ARPA 和 IP6.ARPA 這兩個區域提供的「從位址到名稱」這個方向，內容由持有該位址範圍委派權的一方自行填寫，而不是由可信第三方簽發的憑證。所以檢測還沒結束。網站要把第一步得到的主機名稱拿去做正向解析——一次普通的 A/AAAA 查詢——並檢查結果是否落回最初的那個來源 IP。只有當兩個方向的結果彼此吻合，這個身分才站得住腳：一個不掌控 googlebot.com 的 DNS 的攻擊者，無法讓任意一個 IP 的 PTR 記錄，恰好解析出一個又能正向解析回同一個 IP 的主機名稱。
這也是為什麼這套兩步流程被稱為「正反雙向確認」的反向 DNS，也是為什麼單獨一次反向查詢算不上一種核實方法——它查到的只是一個由別人掌控的值。
方法二：營運方公開發布的 IP 範圍
有些爬蟲營運方乾脆跳過 DNS，直接發布自己抓取所使用的 IP 範圍清單。網站下載這份清單，檢查請求的來源 IP 是否落在其中，命中即視為通過核實。這只是一次集合歸屬判斷——比兩次 DNS 往返查詢便宜得多——這在主流爬蟲產生的請求量級下相當重要。
Google 發布的正是這樣的清單：一組由 CIDR 位址區塊組成的 JSON 檔案，依爬蟲類別拆開——common-crawlers.json 對應搜尋爬蟲，special-crawlers.json 對應 AdsBot 這類產品，使用者觸發的抓取器另有獨立檔案。Google 官方文件把「比對這些檔案」列為手動 DNS 往返之外的自動方案——同一個問題，更便宜的答法。
代價在於新鮮度。一份發布出來的位址範圍清單只是一張快照；如果營運方新增了位址範圍，而網站快取的副本還沒跟上，一個真實的爬蟲短期內就可能過不了這道檢測。而且這種方法只存在於那些有紀律去發布並維護清單的營運方身上——很多規模較小或較新的爬蟲根本不這麼做。
方法三：密碼學簽章
DNS 和 IP 範圍核實的都是某個網路——即持有該位址範圍的一方，或宣稱擁有該位址範圍的一方。簽章核實的是另一件事：持有某把特定私鑰的一方。營運方使用 HTTP 訊息簽章（RFC 9421） 為每個外發請求簽章，Web Bot Auth 架構草案（一份仍在改版、連名稱都還在變的 IETF 網際網路草案，而非已定稿的標準）正是基於這項標準，營運方同時會公開對應的公鑰。網站用這把公鑰驗證簽章，完全不需要過問請求來自哪個 IP 位址。
我們的機器人檢測技術指南在「密碼學機器人身分：Web Bot Auth」一節完整說明了這套機制——如果你想了解底層的密碼學原理，值得一讀；這裡更要緊的一點比較窄：簽章檢測回答的是「哪把金鑰簽了這個請求」，這和「這個請求來自哪個網路」是兩個不同的問題，兩者的答案有時會不一致，這點值得留意。
方法四：營運方註冊表
2026 年為同一個問題新增了第四種答案。與其讓每個網站各自從網路位址或金鑰中推斷身分，營運方現在可以在一個註冊表裡註冊一次，由註冊表替所有網站去做這件推斷的事。Cloudflare 面向營運方的 BotBase（2026 年 8 月 28 日上線）讓機器人營運方提交並維護自己的註冊條目——聲明自己是誰、做什麼、可以如何被核實——並追蹤這份提交在待審核、通過、駁回等狀態之間的流轉，通過之後才拿到「已驗證」標記。
關鍵在於審核過程中發生了什麼。Cloudflare 不會照單全收這份聲明：它會檢查營運方聲稱的核實方式是否真的成立，逐項驗證對方的 IP 範圍清單、反向 DNS 設定以及 Web Bot Auth 簽章。換句話說，註冊表並不是要取代前三種方法——它只是把這三道檢測集中跑一次，讓每個網站可以直接取用一個結論，而不必各自把同樣的三道檢測再造一遍。
與之對應的網站一側則是 Bot Preference Sync，方向正好相反：站長在控制台裡一次性設定自己對搜尋類、智能體類、訓練類爬蟲的政策，Cloudflare 會自動把對應規則寫進這個站台的 robots.txt。那是一套政策機制，而不是核實機制——但兩者只有搭配起來才有意義，因為一條寫給「Googlebot」的偏好設定，其價值完全取決於這個網站有沒有能力判斷來讀它的東西真的是 Googlebot。
為什麼這個順序不是隨意排的
這四種檢測並不是同一件事被逐級做得更好。前三種核實的是三個截然不同的對象，第四種則是替你把前三種跑一遍，而它們各有各的失效方式：
- 正反雙向確認的反向 DNS 與公開的 IP 範圍核實的是網路。 它們會因 DNS 設定錯誤或位址範圍清單過期而失效——兩者都是把真實爬蟲擋在門外的漏判；機率低得多的另一種情況，是攻擊者不知怎地同時掌控了他所取得的某個位址的正向和反向區域（罕見，但對一個資源充足的攻擊者來說並非不可能）。
- 簽章核實的是金鑰持有者。 只有在私鑰外洩時才會失效——這是密碼學與維運安全層面的問題，和 DNS 或網路拓撲毫無關係。
- 註冊條目核實的是註冊表替你查過的那些東西。 它的強度完全等於背後那幾道檢測的強度，同時額外帶來兩種失效方式：註冊機構自身審核不嚴，以及一個合法營運方還沒來得及註冊。
一個網站如果只依賴其中一種檢測，實際上就是在不自知的情況下只信任了這一種失效方式。把它們組合起來——用註冊表查詢打頭，對註冊表裡沒有的營運方再回退到自己的 DNS 檢測——意味著攻擊者要攻破的不只是最薄弱的那一環，同時也不會因為一份過期清單就把真實爬蟲擋在門外。
這對你自己的瀏覽器意味著什麼
以上四種方法，沒有一種是一般瀏覽器能夠提供的。它們的存在是為了那些一開始就自報身分的自動化爬蟲；一個一般上網的人從來不會主動送出一個需要被核實的身分聲明。這正是為什麼網站要為一般訪客準備一整套完全不同的工具——瀏覽器與網路指紋識別——從沒有人主動聲明過的訊號中拼出一幅工作階段畫像。如果你想從另一個角度看看這是什麼樣子，BrowserInsight 的機器人檢測工具會展示檢測系統在一個沒有任何身分聲明可核實的工作階段上，能觀察到的那些相同的用戶端訊號。
本文的範圍是刻意收窄的。這篇指南只講一件事——核實一個已經自稱是某個特定身分的爬蟲。它不講如何僅憑用戶端訊號，把不受歡迎、未聲明身分的自動化和真實訪客區分開來（參見我們的機器人檢測技術指南）；它不講一個 AI 智能體如何用真人自己的憑證駕馭這個人真實的瀏覽器（參見 AI 智能體流量偵測）；它也不講一個真人如何在不被追蹤的前提下證明自己是人（參見網路匿名憑證）。這些都是不同的問題，答案也各不相同；本文只專注於把「這個請求自稱是 Googlebot」，從一句被信任的字串，變成一個經過核實的事實。
常見問題
只要 User-Agent 寫著 Googlebot，我就能直接信任它嗎？
不能。User-Agent 是用戶端自行設定的純文字，沒有任何機制能阻止某個指令碼原樣複製一個真實爬蟲的字串。應該把 User-Agent 聲明當作一個待核實的斷言，而不是既成事實——用上文的某種方法去核實，而不是直接相信這串文字本身。
反向 DNS 和「正反雙向確認」的反向 DNS 有什麼差別？
單純的反向（PTR）查詢只能告訴你這個 IP 的管理者選擇公開了哪個主機名稱——如果你本來就不信任這個管理者，這什麼都證明不了。正反雙向確認的反向 DNS 多加了一步：把這個主機名稱再做一次正向解析，檢查它是否落回最初的那個 IP。省略這一步正向確認，是這項檢測中最常見的一個錯誤。
密碼學簽章是不是絕對優於基於 DNS 的核實？
它們核實的是不同的東西，所以「更好」取決於你需要什麼。簽章證明的是哪把私鑰簽署了一個請求，與網路位置無關，因此在抵禦 IP 偽造方面更強。但它只對已經採用簽章機制的營運方生效，而正反雙向確認的反向 DNS 只要 DNS 設定正確就能用，無論對方是否採用了簽章機制。
我還需要檢查請求的 TLS 或 TCP 指紋嗎？
這是一個獨立的、起補充作用的訊號，而不是替代品——我們的TCP/IP 指紋識別指南說明了網路層特徵如何暴露「聲明的用戶端」與「實際協定堆疊」之間的不匹配，這在身分核實之外很有用，但它本身並不能確認這究竟是誰的爬蟲。
Googlebot 核實能防住所有偽造的爬蟲嗎？
它只針對一種特定的威脅：偽裝成某個已知的、可核實身分的營運方的請求。對於那些從一開始就沒有自稱是 Googlebot 的未聲明抓取流量，它無能為力——那類流量需要的是我們機器人檢測技術指南裡涵蓋的更廣泛機器人檢測訊號，而不是身分核實。
