先建立 crawler 用途表，而不是只抄 User-agent 名單
同一供應商可以有不同用途的識別字。以 OpenAI 為例，OAI-SearchBot 關乎 ChatGPT 搜尋可見度，GPTBot 則關乎潛在模型訓練；Anthropic 亦分開 Claude-SearchBot、ClaudeBot 及使用者觸發的 Claude-User。政策應逐項記錄用途、允許或封鎖的理由、最後覆核日期與負責人，避免日後有人把訓練選擇誤當成搜尋可見度設定。
有些 token 控制用途，並不會自己發出抓取請求
Google-Extended 與 Applebot-Extended 是重要例子：它們用來表達已抓內容可否用於特定生成式或訓練用途，而不是可用 curl 模擬、會獨立抓頁的 HTTP crawler。測試報告要把「robots 規則存在」與「某個 User-agent 實際回應」分開，否則很容易把沒有請求行為的 token 寫成連線成功或失敗。
robots.txt、HTTP 回應與渲染內容是三個不同檢查
robots.txt 是合規 crawler 會讀取的政策；403 或挑戰頁代表請求在 CDN、WAF 或 origin 被拒絕；200 亦不保證看到正確內容，因為地區分流、登入牆或 JavaScript 可能令 bot 得到不同版本。每個重要 User-agent 都應分別抓首頁、代表服務頁、robots.txt、sitemap.xml 與 llms.txt，記錄狀態、最終 URL、內容類型及頁面 canonical。
地區分流要為真正的搜尋 crawler 設計例外
按 IP 或普通瀏覽器語言做地區分流時，crawler 可能被送到另一個國家站，導致 canonical、hreflang 及索引內容不一致。例外名單亦會隨供應商新增識別字而過時，因此不能只測 Googlebot。較穩妥的做法是保留一組代表搜尋、使用者抓取及訓練用途的定期測試，發現新識別字時先確認官方用途，再決定是否加入例外。
Cloudflare 或其他邊緣平台可能有多個獨立開關
Managed robots、AI crawler 控制、一般 Bot 管理、WAF 規則、速率限制及快取可以同時影響結果。關閉其中一個功能不代表其他層亦已放行。修改後應清除相關 robots 或頁面快取，再由外部以指定 User-agent 重測；同時保留 origin 的直接測試，才能分辨問題來自邊緣還是應用程式。
redirect 必須去真正對等的新內容
舊文章若有清楚的新版本，301 應指向最接近的對等頁；大量不相關舊 URL 一律轉去分類或首頁，可能被搜尋引擎視為 soft 404。沒有替代內容而且不再需要的 URL，可按流量、連結與合規需要決定 404 或 410。遷移前先列出舊 URL、目標、狀態與理由，推出後再檢查 redirect chain、canonical 及 sitemap 是否一致。
把政策變成可重複的驗收表
最小驗收表應包括：origin robots 內容與單一 Sitemap 行、邊緣是否注入 managed 內容、各 User-agent 的最終狀態與 URL、重要頁的 lang／canonical／hreflang、JSON-LD 是否可解析，以及 sitemap 只列 200 canonical URL。每次 CDN、分流、robots 或網站路由改動後重跑同一套測試，才不會靠一次成功的截圖判斷長期可見度。
先做一個實用檢查
- 免費 SEO＋GEO 網站審核：先檢查網站結構、canonical、robots 與 AI 可讀性的公開訊號。
- 免費 404 流量及轉址檢查：找出失效 URL、redirect chain 及遷移後需要逐一處理的舊頁。