如何驗證 AI 爬蟲是否如其所言

您的伺服器日誌顯示來自 GPTBot 的請求。您應該信任它嗎？

誠實的答案是：不能僅憑該字串就信任它。使用者代理標頭是用戶端對自身的宣告，任何用戶端都可以宣告任何內容。 curl -A "GPTBot" 大約只需要四秒就能輸入完成。如果您的 robots.txt 政策、分析或付費牆邏輯根據使用者代理字串進行分支，那麼它就是在根據未經驗證的輸入進行分支。

好消息是，大多數主要的 AI 爬蟲都提供了驗證方式。壞消息是，有相當一部分爬蟲完全沒有提供任何驗證方式，而有一整類爬蟲則是設計上無法驗證。本文將說明每種驗證方法如何運作、哪些爬蟲支援哪些方法，以及在哪些情況下誠實的答案仍然是「您無法判斷」。

使用者代理字串是一項宣告，而非身份證明

有三件事值得區分：

• 識別 — 爬蟲告訴您它是誰（使用者代理字串）。
• 驗證 — 您獨立地根據營運商控制的內容確認該宣告。
• 授權 — 您決定該已驗證身份可以執行哪些操作。

robots.txt 運作於第三層，但無法存取第二層。它是一種建議性協定：RFC 9309 標準化其語法與遵循預期，而非提供執行的機制。忽略您的 Disallow 的爬蟲並未違反技術控制；它只是拒絕了一項請求。而冒充行為良好的爬蟲則會繼承您授予原始爬蟲的任何權限。

這在 2026 年比 2020 年更重要，因為這些權限現在是真實存在的。網站允許 AI 爬蟲在模型答案中被呈現、根據每次爬取付費，或讓它們免於機器人挑戰。這些都成為有人偽裝成該身份的理由。

三種驗證方法（依強度排序）

反向 DNS 搭配正向確認

這是經典方法，對於支援它的營運商來說仍然是最穩健的。您取得請求的 IP，將其解析為主機名稱（PTR 記錄），檢查該主機名稱是否以營運商控制的網域結尾，然後再將該主機名稱正向解析回 IP，並確認是否與原始 IP 相符。

正向確認步驟不可省略。PTR 記錄是由控制該 IP 區塊反向區域的人設定，因此如果不再次進行正向解析，您就是在信任攻擊者控制的記錄。

記錄反向 DNS 後綴的營運商包括 Google（.googlebot.com / .google.com）、Microsoft（.search.msn.com）、Amazon（.crawl.amazonbot.amazon）、Apple（.applebot.apple.com）以及 Common Crawl（.crawl.commoncrawl.org）。

已公開的 IP 範圍

營運商會發布其爬蟲使用的 CIDR 區塊的 JSON 檔案；您可以檢查 IP 是否在其中。OpenAI 在 openai.com/gptbot.json 提供此功能，這也是實務上最常見的方法 — 在我們登錄的 41 個爬蟲中，有 20 個記載了 IP 範圍驗證，使其成為支援度最廣的單一檢查方式。

有兩個操作上的注意事項。清單會變動，因此應定期抓取並快取，而非硬編碼；此外，IP 範圍的可信度取決於營運商自身的基礎設施管理 — 共享的雲端範圍不如專用範圍可靠。

Web Bot Auth 簽章

這是未來的發展方向，也是唯一能以密碼學方式證明身份，而非依賴網路拓撲的方法。機器人會使用 HTTP Message Signatures 以私鑰簽署其 HTTP 請求，並在可發現的 JWKS 目錄中發布公鑰，您的伺服器即可驗證該簽章。此方法正在 IETF 推進中，Cloudflare、Akamai 與 AWS 已在驗證端提供支援。

以下是來自營運商端的誠實現況，這部分多數文章都會略過：檢查我們登錄中所有 41 個爬蟲的主要文件，我們無法確認有任何一個爬蟲目前發布了可供驗證的簽章代理網域與 JWKS URL。基礎設施已存在，但營運商端的部署尚未以網站擁有者可以採用的方式記載。請將 Web Bot Auth 視為未來建置的目標，而非本季即可用來設限的工具。

41 個爬蟲實際支援哪些驗證方式

統計登錄中各驗證方法的支援數量（一個爬蟲可支援多種方式）：

一個爬蟲可記載多種方法，因此前三列會有重疊：41 個爬蟲中有 25 個至少支援一種網路層級檢查，其餘 16 個則完全不支援。對於這 16 個爬蟲來說，使用者代理字串是營運商發布的唯一識別碼，且沒有任何東西可以驗證。您可以允許或封鎖它們，但無法驗證它們。（其中一個，Google-Extended，甚至沒有使用者代理字串 — 詳見下文。）

依用途分類，這 41 個爬蟲可分為：13 個使用者觸發的抓取器（因人類詢問而抓取頁面的代理）、10 個搜尋索引爬蟲、9 個訓練爬蟲、4 個代理式瀏覽器、3 個資料提供者，以及 2 個純粹的退出權杖 — Google-Extended 和 Applebot-Extended 根本不是爬蟲，而是用來控制已抓取頁面使用方式的 robots.txt 權杖。

在撰寫任何 Disallow 之前，值得先理解這個區別。封鎖訓練爬蟲不會損失任何推薦流量。但封鎖使用者觸發的抓取器，則代表有人詢問其助理關於您的頁面，而助理無法讀取它。

完全無法驗證的類別

代理式瀏覽器是一個真正不同的問題。它們是由 AI 代理以使用者名義驅動的真實瀏覽器引擎。它們不帶有穩定的機器人權杖，因為從網路的角度來看，它們就是瀏覽器：真實的 Chrome 使用者代理、真實的 TLS 指紋、真實的 JavaScript 執行。

登錄追蹤了四個，而清單本身的變動也具有參考價值：ChatGPT Atlas（OpenAI）與 Comet（Perplexity）是目前的，而 OpenAI 的 Operator 與 Google 的 Project Mariner 已被記錄為已棄用 — 在十八個月內就被取代。無論您在此建置什麼，都應設計成可被取代的。

這裡沒有可供比對的使用者代理字串、沒有已公開的 IP 範圍、沒有反向 DNS 後綴。剩下的只有行為訊號，而在無頭但真實的瀏覽器上，行為訊號是薄弱的。

這是目前工具集的誠實極限，也是 Web Bot Auth 重要的原因：它是唯一能讓代理式瀏覽器主動提供可驗證身份，而非要求您推斷身份的提案。

實作檢查

使用 Node 實作反向 DNS 搭配正向確認（無需相依套件）：

import { promises as dns } from "node:dns";

// 營運商為其爬蟲發布的後綴。請勿自行推斷 —
// 請使用營運商記載的網域，否則您可能驗證到冒名者。
const SUFFIXES = {
  googlebot: [".googlebot.com", ".google.com"],
  bingbot:   [".search.msn.com"],
  applebot:  [".applebot.apple.com"],
  amazonbot: [".crawl.amazonbot.amazon"],
  ccbot:     [".crawl.commoncrawl.org"],
};

export async function verifyByReverseDns(ip, operator) {
  const suffixes = SUFFIXES[operator];
  if (!suffixes) return { verified: false, reason: "no published suffix" };

  let hostnames;
  try {
    hostnames = await dns.reverse(ip);            // PTR lookup
  } catch {
    return { verified: false, reason: "no PTR record" };
  }

  const host = hostnames.find((h) => suffixes.some((s) => h.endsWith(s)));
  if (!host) return { verified: false, reason: "PTR outside published domain" };

  // 正向確認：PTR 記錄由反向區域的擁有者控制，
  // 因此需將主機名稱解析回來，並要求 IP 相符。
  const forward = await dns.resolve(host).catch(() => []);
  return forward.includes(ip)
    ? { verified: true, host }
    : { verified: false, reason: "forward lookup did not match" };
}

進入全螢幕模式 退出全螢幕模式

在正式環境中，有兩件事需要正確處理。請在請求路徑之外執行此操作 — 在請求路徑中進行 DNS 往返會造成延遲與阻斷服務的風險，因此請以非同步方式驗證，並快取每個 IP 的驗證結果。此外，請在您的政策上採取關閉失敗，而非在請求上：未經驗證的請求不一定具有敵意，它只是尚未證實，因此請降低其權限，而非對可能是真實使用者的請求回傳 403。

為什麼「不明確」比自信的猜測更好的答案

大多數已發布的 AI 爬蟲清單都會為每個機器人提供 robots.txt 遵循的明確是/否判斷。編譯這些資料後發現，這種明確性反而是最站不住腳的部分。

對於相當數量的爬蟲，其營運商根本從未針對該確切名稱的代理發布過明確聲明。此時可用的選項是從同類機器人推斷、複製其他清單的說法，或是記錄「不明確」並引用營運商的實際說明。只有第三種選項能在有人查證時站得住腳。

因此，本文背後的登錄採用三態值 — 是、否、不明確 — 每個個別聲明都附有主要來源 URL 與 last_verified 日期，並在無法取得來源的欄位明確標記為空值，而非填入看似合理的猜測。這樣做比較不整潔，但只有這樣才能在營運商悄悄修改文件時保持正確。

如果您需要每個爬蟲的資料 — 使用者代理權杖、robots.txt 權杖、驗證方法、已公開的 IP 範圍 URL、退出機制，以及每個欄位背後的來源 URL — 可以在 agentswelcome.dev/crawlers 找到，另有 JSON 端點位於 /api/crawlers，如果您希望以 diff 而非閱讀的方式取得資料。

常見問題

在 robots.txt 中封鎖 AI 爬蟲真的能阻止它們嗎？
從技術上來說不行。robots.txt 是建議性的：RFC 9309 定義了其語法與期望，而非執行機制。OpenAI、Anthropic 與 Perplexity 各自發布文件，說明其爬蟲會遵循 robots.txt，而證據顯示主要營運商確實如此。如果您需要執行，則需要 WAF 規則或邊緣的已驗證機器人政策 — 而非一個文字檔。

Google-Extended 是我應該封鎖的爬蟲嗎？
Google-Extended 不是爬蟲，也沒有使用者代理字串。它是一個 robots.txt 權杖，用來控制 Google 已抓取的內容是否可用於 Gemini 訓練。拒絕它不會減少爬取流量，也不會影響搜尋索引。Applebot-Extended 對 Apple 的運作方式相同。

我應該封鎖訓練爬蟲，但允許搜尋爬蟲嗎？
這是常見的政策，其理由也站得住腳：訓練爬蟲消耗您的內容卻沒有任何推薦回流，而搜尋索引或使用者觸發的抓取器則能讓您出現在人類正在閱讀的答案中。請依機器人類型而非公司決定政策 — 有些營運商會在不同權杖下同時執行兩種類型。

這些資料多久會變動一次？
變動頻率足以造成影響。營運商會在沒有公告的情況下新增權杖、重新命名代理並更新 IP 範圍。任何沒有每個聲明來源 URL 與驗證日期的爬蟲清單，都只是某人某個下午的快照，包括本文在內 — 這也是為什麼上述數字會標註檢查日期：2026-07-30。

資料來自 AGENTS WELCOME 爬蟲登錄 — 41 個爬蟲，每個欄位都附有其主要來源與驗證日期。檢查日期：2026-07-30。