OpenAI 在 2026 年 10 月 30 日宣布，未來會支援一個寫在 robots.txt、可讓多家 AI 供應商共同理解的訓練偏好訊號。對網站經營者而言，這代表原本逐家維護 GPTBot、Google-Extended、ClaudeBot 等規則的工作，可能有一部分能統一；但截至公告日，OpenAI 只表示會在未來幾個月實作，並未宣告訊號已全面生效。

因此，現在適合做的是盤點與設計，不是把新規則貼上正式站就刪掉既有控制。這個訊號表達的是「內容是否可用於生成式 AI 訓練」的偏好，不等於防火牆，不直接控制爬蟲是否能抓取，也不等於決定網站能否出現在 ChatGPT 搜尋或其他 AI 即時回答中。

新訊號到底表達什麼

OpenAI 公告指出，共同訊號會沿用 robots.txt，目的在讓網站用同一份偏好對多個參與供應商溝通。OpenAI 同時說，既有 crawler controls 仍會繼續適用；這表示過渡期間不能只保留共同訊號，也不能推論所有 AI 公司都會同步採用。

2026 年 10 月 30 日的 Internet-Draft提出 User-Agent: __usage_ai-training 這個 policy token。站方可用一般 Allow 與 Disallow 路徑規則表達偏好，例如全站不供訓練、但允許 /press-kit/。草案把 AI training 定義為使用資產去修改生成式模型的學習參數；分類、排序或評分等非生成任務不一定落在這個定義內。

這份文件目前是個人提出的 Internet-Draft，不是已通過的 RFC，也沒有 IETF 正式標準地位。它可能更新、被替換或失效。網站規格書應記錄草案版本與查核日期，不要在合約中寫成「已符合 IETF 認證」。

訓練偏好、抓取控制與 AI 搜尋要分開

第一層是內容用途偏好：共同 token 告訴參與者某個路徑可否拿來訓練。第二層是抓取控制：針對特定 crawler 的 User-agent 規則，才是在表達可否抓取。草案明確說，policy token 本身不是 crawling directive；網站若要限制流量，仍須設定爬蟲規則或在 CDN、WAF 執行技術封鎖。

第三層是搜尋與即時回答。訓練、建立搜尋索引、使用內容回答當下問題是不同用途。品牌若希望內容可被 AI 搜尋引用，但不希望用於訓練，就不該把所有 AI user agent 一律封鎖。反過來，允許搜尋也不保證被收錄、引用或帶來排名；這仍取決於可抓取性、內容品質、索引系統與平台政策。

Cloudflare 的 robots.txt 文件也提醒，robots.txt 遵守與否是自願的，檔案本身不會形成技術封鎖。Cloudflare 的 Bot Preference Sync 目前可發布 Content-signal: search=yes, ai-train=no, use=reference，並搭配供應商規則與 edge blocking；這套 Content Signals 表示法和新草案的 __usage_ai-training 並非同一語法，不能因為概念相近就假定所有供應商會交叉理解。

上線前先做四張清單

先建立「內容類型」清單，把公開文章、產品說明、下載文件、會員頁、後台、搜尋結果與暫存頁分開。每類標記是否允許一般搜尋、AI 即時引用與 AI 訓練，並確認內容授權真的允許站方做這個決定。外部作者、圖片授權、客戶提供素材與付費資料庫，不能只靠網站營運者的偏好取代原合約。

第二張是「目前規則」清單，蒐集每個網域及子網域實際回傳的 /robots.txt、CDN 代管設定、WAF 規則與應用程式產生邏輯。不要只看 Git repository 裡的檔案；Cloudflare 等平台可能在邊緣節點合併或加上內容，正式回應才是 crawler 讀到的版本。

第三張是「爬蟲與用途」對照，至少區分一般搜尋、AI 搜尋、使用者觸發抓取與訓練 crawler。第四張是「責任與變更」清單，記錄誰核准政策、誰修改 CDN、誰驗證，以及供應商公告或草案更新後多久重查。

實作與驗收步驟

先在測試網域建立預期規則，使用多個路徑案例驗證最長匹配與 Allow／Disallow 結果，再確認舊 crawler 規則沒有被共同 token 覆蓋。草案規定萬用 User-agent: * 不應被視為共同訓練偏好；不能把既有的全站抓取規則直接解讀成新用途聲明。

發布後以 HTTP 實際取得每個 hostname 的 /robots.txt，檢查狀態碼、轉址、內容型別、CDN 合併順序與快取。接著用供應商文件或驗證工具檢查解析結果，監看伺服器與 CDN bot log；但 log 只能證明請求與識別資訊，不能直接證明內容是否進入模型訓練。

變更應保留版本、核准者、發布時間與回滾方式。若調整後一般搜尋抓取量、索引頁數或 AI referral 異常，先比對是否誤封搜尋 crawler、WAF challenge 或子網域規則，而不是立刻把波動歸因於共同訊號。

現階段怎麼選

只想表達訓練偏好的網站，可先設計共同 token，但應等目標供應商確認實作細節後再把它當主要控制。需要立即限制存取的網站，應保留逐家 crawler 規則，並視風險加入 CDN 或 WAF 封鎖。希望保有 AI 搜尋曝光的品牌，則要把訓練與搜尋分開決策，避免用全域封鎖換來無法預期的可見度損失。

這次公告的重要性，不在於多了一行可以複製的 robots.txt，而在於內容用途開始有跨供應商的共同語言。現在先完成內容授權、用途矩陣、實際回應與回滾驗收；等供應商正式落地時，才能從容合併規則，而不是在標準仍變動時誤把偏好聲明當成技術防線。