這比較像家裡的四種訪客：送信的、來抄水電表的、你自己叫的外送、以及在門口拍照的路人。把大門鎖死確實能擋掉全部，代價是信也收不到了。先分清楚誰是誰，才知道要關哪一道門。
這篇整理 Google、OpenAI、Anthropic、Perplexity、Apple 與 Common Crawl 的官方說明，給你一張政策矩陣、一份設定範例和七步檢查。
要從 robots 規則一路核對到實際內容取得，看 AI crawler 可存取性檢查表；sitemap 在發現上的角色看 sitemap 與 AI crawler 發現。
不同用途的 crawler 政策需分開保存與驗收。
先用目的分類，而不是用品牌分類
「AI crawler」不是官方統一分類。Google 把 Googlebot Search 和 Google-Extended 分開；OpenAI 把 OAI-SearchBot、GPTBot 與 ChatGPT-User 分開；Anthropic、Perplexity 和 Apple 各自提供不同 user-agent。這些名稱是產品文件裡的控制單位。按用途分組，才不會在想擋訓練的時候順手關掉搜尋呈現。
| 政策目的 | 常見控制層 | 先問的問題 | 主要風險 |
|---|---|---|---|
| 搜尋發現或搜尋回答 | 搜尋 crawler、Googlebot 或 vendor search bot | 目標產品要不要讀取公開頁面？ | 允許抓取仍不代表會被引用 |
| 模型訓練 | 供應商 training token | 哪些路徑允許作為訓練資料？ | 封鎖訓練 token 不一定封鎖搜尋 |
| 使用者即時擷取 | user-triggered fetcher | 使用者要求開網址時要如何處理？ | 有些平台說明 robots 可能不適用 |
| 降低負載 | robots、crawl rate、WAF 或 CDN | 哪些 crawler 造成請求壓力？ | 過度封鎖會影響公開內容可發現性 |
| 資料保密 | 登入、授權、伺服器拒絕 | 內容是否根本不應公開？ | robots.txt 不是存取控制 |
Google 的 robots.txt 官方介紹 把 robots.txt 定位成 crawler 存取與流量管理方法，並提醒它不是把頁面從搜尋結果隱藏的機制。跨平台時，這條邊界要放在第一欄，不要等到設定完成才補註解。
跨平台 AI crawler 政策矩陣
下表整理各家官方文件對用途和控制方式的描述。它不是放行清單，也不是效果比較；官方只說明某個 token 的用途，表裡就只寫到那個範圍。
| 平台／控制單位 | 主要用途 | robots.txt 能表達的政策 | 官方邊界 |
|---|---|---|---|
| Googlebot | Google Search 抓取、渲染與索引流程 | 依 Googlebot 或一般群組管理可抓取路徑 | 影響 Google Search 抓取層，不等於控制所有 Google AI 產品 |
| Google-Extended | 管理 Google 抓取內容是否可用於 Gemini 未來訓練，以及部分 Gemini grounding | 使用 User-agent: Google-Extended 的獨立群組 | 沒有獨立 HTTP user-agent，不影響 Google Search 收錄或排名，也不是 AI Overviews 顯示開關 |
| OAI-SearchBot | ChatGPT Search 搜尋結果 | 可獨立允許或拒絕 | OpenAI 說拒絕後不會出現在 ChatGPT Search answers，但仍可能作為導覽連結出現 |
| GPTBot | 可能用於 OpenAI foundation model 訓練的內容抓取 | 可與 OAI-SearchBot 分開設定 | 封鎖它不等於封鎖 ChatGPT Search |
| ClaudeBot | Anthropic 模型開發與訓練資料收集 | 依 Anthropic user-agent 群組控制 | Anthropic 將訓練、搜尋與使用者請求拆成不同 bot |
| Claude-SearchBot | 改善 Claude 搜尋結果品質 | 可獨立控制 | Anthropic 文件描述它是搜尋索引用途，不與 ClaudeBot 合併 |
| Claude-User | 使用者要求 Claude 讀取網頁 | 可依 Anthropic 文件設定 | 這是 user-directed request，不能用自動 crawler 的結果代替驗收 |
| PerplexityBot | 在 Perplexity 搜尋結果中呈現與連結網站 | 可獨立允許或拒絕 | Perplexity 說它不拿來抓取 foundation model 訓練內容 |
| Perplexity-User | 使用者提問時即時取用網頁 | Perplexity 說這類請求一般忽略 robots.txt | WAF 需依官方 IP ranges 和實際安全政策另行判斷 |
| Applebot | Apple Search、Spotlight、Siri、Safari 等搜尋相關用途 | 支援一般 robots 與 meta 控制 | Applebot 可能被用來提供 Apple 產品的 AI 內容上下文 |
| Applebot-Extended | 控制 Apple foundation model 訓練資料使用 | 可在 robots.txt 對指定路徑設定 | 它不抓網頁，且不影響頁面出現在 Apple 搜尋結果 |
| CCBot | Common Crawl 公開爬取資料集 | 可用 User-agent: CCBot 拒絕抓取 | Common Crawl 建議同時驗證 user-agent，因為可能有偽造 CCBot 的請求 |
其中 Google-Extended 的定位最容易被誤讀。Google 官方說它是 robots.txt 的控制 token，不會以獨立 user-agent 發出 HTTP 請求，而且不影響 Google Search 的收錄或排名。Google 對 AI features 的說明則要求頁面先符合 Search 的索引資格，沒有另一個可取代 Googlebot 的 AI Overviews crawler。
OpenAI、Anthropic、Perplexity、Apple 和 Common Crawl 的官方說明也各自使用不同語句描述 user-directed fetch、搜尋和訓練。這就是矩陣要保留來源欄的原因。只記一串 bot 名稱，半年後很容易忘記每個名稱實際控制什麼。
把矩陣轉成 robots.txt 政策
先寫目標路徑，再決定群組
假設一個網站有公開文章、內部預覽、管理後台和不想納入模型訓練的資料。可以先在政策表寫出以下分工：
| 路徑 | OAI-SearchBot | GPTBot | Google-Extended | PerplexityBot | 使用者觸發存取 |
|---|---|---|---|---|---|
/ 與公開文章 | Allow | 依站點政策，例中 Allow | 依站點政策，例中 Allow | Allow | 依服務與安全政策 |
/preview/ | Disallow | Disallow | Disallow | Disallow | 拒絕或要求登入 |
/private-research/ | Disallow | Disallow | Disallow | Disallow | 使用登入或授權 |
/admin/ | Disallow | Disallow | Disallow | Disallow | 由伺服器權限保護 |
接著才把決定寫成規則。下面的例子把表格中的三個受限路徑，在每個需要匹配的 specific group 中逐一列出：
User-agent: Google-Extended
Allow: /
Disallow: /private-research/
Disallow: /preview/
Disallow: /admin/
User-agent: OAI-SearchBot
Allow: /
Disallow: /private-research/
Disallow: /preview/
Disallow: /admin/
User-agent: GPTBot
Allow: /
Disallow: /private-research/
Disallow: /preview/
Disallow: /admin/
User-agent: PerplexityBot
Allow: /
Disallow: /private-research/
Disallow: /preview/
Disallow: /admin/
User-agent: *
Disallow: /private-research/
Disallow: /admin/
Disallow: /preview/
Sitemap: https://www.example.com/sitemap.xmlRFC 9309 §2.2.1 要先找符合 crawler product token 的群組；有 specific match 時，只讀該群組，不會再從 User-agent: * 繼承 /admin/、/preview/ 或 /private-research/。例如 OAI-SearchBot 請求 /private-research/ 會讀到自己的 Disallow，而沒有列在上方的 ExampleBot 才會使用 wildcard 三條限制；另外，同一群組內仍按 RFC 9309 §2.2.2 的最長路徑匹配判斷 Allow／Disallow。
這段設定管不到 Perplexity-User 或 ChatGPT-User 這類使用者觸發的請求，也代替不了 WAF 的來源驗證。實作前要確認各平台文件、CDN 規則和應用程式回應是否一致。
先不要把 robots.txt 當成隱私工具
公開 URL 即使被 robots.txt 拒絕，仍可能因其他頁面的連結而被發現。Google 官方建議需要真正防止搜尋顯示時，使用 noindex、登入或移除頁面等方法；需要保護資料時則應使用權限控制。不同平台對 robots 的遵守程度也不相同，所以「寫了 Disallow」只代表提交了一項 crawler 政策，跟資料已經保密是兩回事。
從檔案到 WAF 的七步檢查
1. 建立 user-agent 清單
先記平台、user-agent、用途和官方來源 URL。搜尋 crawler、訓練 token 和使用者 fetch 不要混在同一個欄位。若是 Google-Extended，備註它是 robots token，不是獨立 HTTP user-agent。
2. 以路徑標記政策
每一條規則都寫目的，例如「阻止 /preview/ 被搜尋 crawler 讀取」或「停止 Google-Extended 對 /private-research/ 的使用」。沒有目的的 Disallow: / 之後很難做影響分析。
3. 讀回 /robots.txt
確認 origin 回傳 200、內容是純文字、沒有 CDN 錯誤頁，也沒有因不同 host 或 protocol 出現另一份規則。檢查時同時保留時間、host、狀態碼和原文雜湊，避免日誌和檔案版本對不上。
4. 檢查重要頁面的 HTTP 與 HTML
挑一個公開頁、一個 preview 頁和一個應受保護的頁面。測試狀態碼、重新導向、noindex、canonical、主要正文是否在回應中，以及是否要求登入。robots.txt 放行不能掩蓋 403、429 或應用程式本身的錯誤。
5. 核對 CDN 與 WAF
Perplexity 官方建議 WAF 同時使用 user-agent 與官方 IP ranges 做判斷；Common Crawl 也提醒偽造 CCBot 的可能性。其他平台也應依自己的官方 IP 清單驗證。只比對 user-agent 會把偽造請求和正式 crawler 混在一起。
6. 讀伺服器紀錄
把請求時間、IP、user-agent、URL、狀態碼、回應大小與快取狀態放在同一列。若只知道某個 bot 有來過，卻不知道它取得 200、403 還是快取中的舊頁，這筆紀錄不足以支持「頁面可被使用」的結論。
7. 把 crawler 證據和回答證據分開
最後用固定題目觀察目標產品的回答、來源 URL 和日期。Google AI features 的呈現、OpenAI Search、Perplexity、Claude 或 Apple 產品都有自己的檢索和回答流程。crawler log 可以回答「請求發生了什麼」，回答觀測才回答「這次介面顯示了什麼」。
哪些結果不能由 robots.txt 推出
robots.txt 能幫你表達 crawler 存取政策，但它不會替你完成索引、內容理解、來源選擇或引用驗收。常見的跳躍有以下幾種：
| 已取得的證據 | 可以說 | 不宜直接說 |
|---|---|---|
OAI-SearchBot 取得 200 | 這次請求取得公開頁面 | ChatGPT 一定會引用 |
GPTBot 被拒絕 | 對 GPTBot 提交拒絕政策 | 所有 OpenAI 存取都被封鎖 |
Google-Extended 被拒絕 | 對 Google-Extended 設定資料使用限制 | Google Search 或 AI Overviews 被封鎖 |
| URL 在 sitemap | URL 被列入發現清單 | 已被每個 AI 引擎讀取 |
| WAF 放行某 IP | 該安全規則放行請求 | 內容一定被平台採用 |
Google 的生成式 AI 指南也說，符合條件並不保證 Google 會抓取、索引或提供頁面。其他 AI 產品各有各的文件和回應資料，用一個全域分數代替實際證據會出事。
接下來可以看什麼
只需要處理 OpenAI 那兩個 token 的，先看 OAI-SearchBot 與 GPTBot 的差別。要把 crawler 存取結果和品牌提及、引用、推薦放進同一個觀測流程，看 AI Visibility 的量測方法和 Citation Tracking。
我們的 Otlex 是 EthorX 開發的 AI 搜尋優化平台，觀測品牌在 ChatGPT、Google AI Overview、Google AI Mode、Gemini、Grok、Perplexity、Claude 七個引擎回答中的提及、引用與推薦。已經整理好多平台題庫、想把 crawler 政策、來源 URL 和回答變化放在同一條流程上的團隊，可以從那裡看起，再依網站內容和權限範圍聯絡我們討論。
常見問題
robots.txt 能同時控制所有 AI crawler 嗎？
每個平台的 user-agent、用途和規則處理方式可能都不同。逐家讀官方文件，把搜尋、訓練和使用者請求分成不同欄位，再決定要不要共用 * 群組——一個 * 群組寫起來最快，也最容易在半年後變成一個沒人敢動的黑盒子。
Google-Extended 是另一個 Google 搜尋爬蟲嗎？
Google 官方把它描述成 robots.txt 的控制 token，不是獨立的 HTTP user-agent——它不會自己來敲門，你也不會在 log 裡看到它。它管理的是 Google 抓取的內容能否用於 Gemini 某些訓練與 grounding 情境，和 Google Search 的收錄或排名無關。
封鎖 PerplexityBot 就能阻止 Perplexity 讀取所有頁面嗎？
Perplexity 把 PerplexityBot 和 Perplexity-User 分開。後者是使用者提問時觸發的請求，官方文件寫明這類 fetch 一般忽略 robots.txt——那是使用者自己叫的外送，門口的公告攔不住。有安全需求的話，要處理 WAF、IP ranges、登入與伺服器權限。
Applebot-Extended 會讓頁面消失在 Apple 搜尋嗎？
Apple 官方說 Applebot-Extended 只控制內容能否用於 Apple foundation model 訓練，這個 token 本身不抓網頁。拒絕它的頁面仍然可能出現在 Apple 搜尋結果——它管的是資料用途，不是頁面可見性。Applebot、meta 指令和頁面存取各自檢查。
robots.txt 改好後，多久要重查？
各平台文件給的調整時間不同，Perplexity 與 OpenAI 都提到可能需要約 24 小時。那是系統讀取政策的時間提示——過了 24 小時，接下來要看的是日誌和產品回答，不是直接宣告已生效。每次變更保留 robots、日誌和產品回答三層證據。
參考來源
以下依各平台官方文件整理，user-agent、IP ranges 與 robots.txt 例外以官方頁面當下為準。
- Google Search Central：Introduction to robots.txt
- Google Crawling Infrastructure：Google-Extended
- Google Search Central：AI features and your website
- OpenAI Developers：Overview of OpenAI Crawlers
- Anthropic Help Center：Web crawlers
- Perplexity Developers：Perplexity Crawlers
- Apple Support：About Applebot
- Common Crawl：CCBot
- RFC Editor：RFC 9309 Robots Exclusion Protocol
- Google Search Central：Latest documentation updates