首頁 / 技術文章 / robots.txt 群組不會繼承：為 GPTBot 開例外時，如何保留封鎖規則
技術文章
robots.txt 群組不會繼承：為 GPTBot 開例外時，如何保留封鎖規則
依 RFC 9309，為爬蟲另開相符的具名群組後，原本寫在 * 群組的 Disallow 就不再對它生效。要保留那些限制，必須把封鎖規則寫進具名群組；以下以 GPTBot 示範規格上的結果，各家爬蟲的實作仍須另行確認。
具名 User-agent 群組會取代 *，不會繼承
設定上的陷阱，往往出現在網站想為某個爬蟲開放內容時：* 群組已經封鎖後台與內部路徑，於是新增 User-agent: GPTBot，再放一行 Allow: /。如果預期原有的封鎖仍會保留，這份設定就會偏離原意。
原因是群組選擇發生在路徑規則判定之前。依 RFC 9309，有相符的具名群組時，爬蟲採用該群組的規則；只有找不到時，才退回 *。因此，* 不是每個爬蟲都先套用的共同底層，而是沒有相符具名群組時的備用選項。
RFC 9309 於 2022 年 9 月以 IETF Standards Track 文件發布，群組比對已有正式規格可循。Google 的官方說明也明確區分具名群組與萬用群組：兩者不會合併成一套繼承規則。這裡要分清楚規格如何要求、Google 如何解讀，以及其他廠商實際如何執行。
有效群組判定：先找 token，再決定是否退回 *
審查 robots.txt 時，建議先選定要檢查的爬蟲 product token，再依 RFC 9309 的群組比對規則找出它實際使用的規則集合。以下把這個集合稱為有效群組；它可能來自多個相符群組的合併，不能直接理解成檔案裡某一段文字。
- 先找與爬蟲 product token 相符的具名群組。如果同一 token 出現在多個群組，先合併這些群組的規則，不再納入 * 群組。
- 沒有相符的具名群組時，才使用 User-agent: * 群組。
- 具名群組與 * 群組都沒有時，不套用任何規則，依此協定允許抓取。
這個順序會改變設定的讀法。看到檔案開頭有 Disallow: /admin/，還不能判斷 GPTBot 是否受限；必須先確認那行屬於哪個群組，以及 GPTBot 最後會選到哪套規則。只查路徑是否出現在檔案裡，容易漏掉群組選擇造成的落差。
另一個容易忽略的地方是重複群組。Google 文件說明，同一 token 的多個群組會合併，不是讀到第一個就停止。若設定分散在人工維護區與自動產生區，審查時應把同 token 的內容一起攤開，才能知道完整政策。
錯誤範例：GPTBot 的 Allow 讓原有封鎖失去作用
假設網站希望一般爬蟲與 GPTBot 都避開 /admin/、/internal-api/，同時允許 GPTBot 抓取公開內容。以下是用來說明群組語意的反例，路徑均為示意；註解標出依 RFC 9309 判定時，各行對 GPTBot 的作用。
# GPTBot 有相符的具名群組，因此不採用這個群組
User-agent: *
# 這項封鎖不會帶入 GPTBot 的有效群組
Disallow: /admin/
# 這項封鎖也不會帶入 GPTBot 的有效群組
Disallow: /internal-api/
# GPTBot 採用的具名群組
User-agent: GPTBot
# 此群組只有允許規則，未列出上述封鎖
Allow: /
依前述規格，GPTBot 找到自己的群組後，就不會再讀取 * 群組裡的封鎖規則作為補充。它的有效規則只剩 Allow: /，因此示例中的 /admin/ 與 /internal-api/ 都沒有被禁止抓取。這是根據規格推導的設定結果，不代表已確認 GPTBot 的實際請求行為。
這裡無須比較 Allow 與 Disallow 誰的優先權較高，因為那些 Disallow 根本沒有進入 GPTBot 的有效群組。把問題誤判成路徑規則衝突，可能導致維護者反覆調整路徑，卻沒有修正真正缺少封鎖規則的群組。
修正版：在每個具名群組寫入完整封鎖規則
若要保留上述政策，修正重點是把必要的 Disallow 放進 GPTBot 群組。以下範本將共同封鎖規則分別寫入 * 與 GPTBot；判讀時，每個群組都能獨立表達需要避開的路徑，不必仰賴不存在的繼承關係。
# 沒有相符具名群組的爬蟲使用這套規則
User-agent: *
Disallow: /admin/
Disallow: /internal-api/
# GPTBot 的封鎖規則必須在自己的群組中列出
User-agent: GPTBot
Disallow: /admin/
Disallow: /internal-api/
若維護者只是想讓 GPTBot 遵守與一般爬蟲完全相同的政策，也可以考慮不設它的具名群組，讓它依規格退回 *。具名群組應服務於明確的政策差異；多開一段卻沒有不同需求，只會增加日後同步修改的負擔。
需要保留具名群組時，建議把共同封鎖路徑當成維護清單。新增內部路徑後，逐一確認每個具名群組是否也該加入；若由 CMS、外掛或產生器輸出 robots.txt，則應檢查最後輸出的檔案。設定介面上的共用政策是否真的展開到各群組，才是驗收重點。
常見誤解：繼承、只讀第一組、未列出就禁止
以下對照整理 RFC 9309 與 Google 文件所支持的群組行為。這些差異會直接影響審查方法，不能只靠規則的排列位置猜測結果。
| 錯誤說法 | 規格行為 | 審查重點 |
|---|---|---|
| 具名群組會繼承 *，再追加自己的規則 | 有相符具名群組時，不套用 * 群組 | 共同封鎖是否已寫入具名群組 |
| 同一 token 只看第一個群組 | 相符的多個群組會合併規則 | 搜尋整份檔案中的同 token 群組 |
| 未列出的爬蟲預設禁止 | 沒有相符具名群組時退回 *；兩者皆無則不套用規則，允許抓取 | 確認是否有 *，以及它實際限制哪些路徑 |
對維運而言，較可靠的檢查單位是爬蟲與路徑的組合。例如先判定 GPTBot 的有效群組，再檢查示例中的後台路徑；接著換成沒有具名群組的爬蟲，確認退回政策。這比只搜尋檔案內有沒有 Disallow，更能對照原先的存取意圖。
AI 爬蟲的適用限制：規格判定與實際行為要分開
設定 GPTBot 等 OpenAI 爬蟲前，應先對照 OpenAI 爬蟲文件確認要管理的對象。本篇的群組推導依據是 RFC 9309；現有依據不足以確認 OpenAI、Anthropic、Perplexity 等營運者的解析器，都完整採用相同的合併與退回行為，因此不能把規格結果直接當成各家實作保證。
實務上，建議先把預期政策寫清楚，再用伺服器日誌核對請求路徑與回應，將設定推導和觀察結果分開保存。若目標是區分 AI 搜尋與其他用途，可延伸閱讀按用途管理 AI 爬蟲的做法與限制；不論最後選用哪些 token，每個具名群組都應重新檢查共同封鎖是否完整。
保護後台與授權內容時，則不應把 robots.txt 當成存取控制。網站應以實際的驗證與授權機制決定能否取得內容；爬取政策與內容頁拒絕存取的差異，可參考如何區分 robots.txt 與內容頁的存取限制。將兩者分開管理，也能避免把一份語法正確的檔案誤認為完整的安全措施。
為 AI 爬蟲新增具名群組，應視為建立一份需要獨立審查的爬取政策。真正需要驗收的是：該 token 最後採用哪些規則，以及原本不希望開放的路徑是否仍在其中。若無法維持各群組的一致更新，減少不必要的具名群組，會比持續複製規則更容易管理。
常見問題
在 * 寫 Disallow: /，再替 GPTBot 寫 Allow: /，GPTBot 還會被擋住嗎？
依 RFC 9309，若 GPTBot 有相符的具名群組，就不套用 * 的封鎖；在沒有其他相符群組規則的前提下，該設定允許它抓取。這是規格判定，各家爬蟲的實作與網站實際存取控制仍須分開確認。
把 * 群組移到 GPTBot 群組後面，能恢復共同封鎖嗎？
不能靠這種排序恢復繼承。依 RFC 9309，相符具名群組存在時就不使用 *。應把必要的封鎖規則寫入 GPTBot 群組，或在政策相同時移除不必要的具名群組。
同一個 User-agent 分散在不同群組，後面的規則會被忽略嗎？
依 RFC 9309，同 token 的相符群組應合併；Google 文件也說明了合併行為。因此審查時須查看整份檔案，不能只讀第一個相符群組。
沒有列出某個爬蟲，是否代表禁止它抓取？
不是。依 RFC 9309，沒有相符具名群組時會退回 *；如果連 * 都沒有，就不套用任何規則，依此協定允許抓取。