GEO 實作：AI crawler 存取治理，為什麼 robots.txt 不是防火牆

先講結論：robots.txt 告訴 crawler 你的偏好，但不是網路防火牆。GEO 的存取治理要把「宣告、觀測、執行、驗證」分成四層，否則你可能以為已封鎖，實際上仍被讀取；也可能為了擋訓練流量，誤傷 AI 搜尋的引用入口。

四層治理模型

1. 宣告：robots.txt 說清楚意願

Google 的 AI 搜尋功能沿用既有 SEO 基礎，沒有額外必加的特殊檔案或 Schema；符合要求也不保證呈現。這項說明適用於 Google，不能當成所有平台共用的引用規則。

在各需治理主機的根路徑提供 /robots.txt，檢查實際回應與適用範圍；子網域也須分別確認。私有內容先以身分驗證與授權保護，不把敏感網址列入公開 sitemap，也不把公開 robots 檔當作秘密路徑清單。不要把 Disallow: / 當成存取控制系統，也不要假設所有 crawler 都會遵守。

2. 觀測：知道誰在讀、讀什麼、拿到什麼狀態碼

Cloudflare AI Crawl Control 文件（2026-08-14）提供 crawler 活動、請求模式、robots.txt 遵循度與狀態碼的觀測；可比對 robots 回應、邊緣事件與應用日誌，確認觀測範圍與缺漏。

最小可用的觀測欄位如下：

• crawler：例如 OAI-SearchBot、GPTBot、ClaudeBot、PerplexityBot。
• purpose：AI search、assistant、training 或未知。
• path 與 status：被請求的頁面、圖片、sitemap 及 HTTP 結果。
• policy_result：allow、disallow、enforced-block。

HTTP 狀態碼與政策結果是不同欄位：403 可能就是預期封鎖，429 可能來自速率限制，不能把所有 4xx 歸為可用性故障。核對時間、規則與請求識別碼；user agent 只是宣稱身分，須依官方驗證方式核對來源。日誌有抽樣或 CDN 快取時，缺紀錄不代表沒有請求。

3. 執行：需要真正阻擋時使用安全控制

Cloudflare 的 robots.txt 設定文件（2026-08-03）明確說明：robots.txt 遵循是自願的，無法在技術上阻止 crawler；若要強制封鎖，應使用 AI Crawl Control 或其他安全控制。這是最容易被 GEO 文章忽略的界線。

建議按目的制定政策：

1. AI search / assistant：通常保留公開知識頁，確保正文、canonical 與圖片可讀。
2. training crawler：依授權、商業策略與內容條款決定；不要用一條全域規則代替分類。
3. preview、未完成或敏感路徑：先用身分驗證與授權限制存取，測試未登入請求不能取得正文；robots 與 bot 規則僅是補充，不能只封鎖已知 crawler。
4. 未知或違規 crawler：保存證據後以明確規則處理，避免只靠 User-Agent 字串做唯一判斷。

4. 驗證：把政策改動當成 GEO 回歸測試

每次修改後用同一份 URL 與 crawler 測試矩陣重跑。以下網址是佔位範例，換成自己的測試路徑；-A 只模擬 user agent，不代表官方爬蟲來源：

curl -i https://example.com/robots.txt
curl -i https://example.com/sitemap.xml
curl -A 'OAI-SearchBot' -i https://example.com/core-guide
curl -A 'GPTBot' -i https://example.com/preview/draft
curl -H 'Accept: text/markdown' -i https://example.com/core-guide

記錄狀態碼、Content-Type、canonical、正文是否存在，以及政策命中原因。200 也可能是挑戰頁；Accept: text/markdown 只是請求偏好，不保證伺服器支援 Markdown。封鎖測試應包含一般未登入請求，不只列出的 bot 字串。再用固定的 AI 搜尋問題檢查：品牌是否仍被正確引用、引用 URL 是否是正式頁面、答案是否把 draft 或 preview 當成事實。單次或多次回答都不能單獨證明政策有效；平台可能使用舊索引或其他來源。保存引擎、模式、日期、發布版本與完整來源，品牌提及與實際引用分開計算；未知來源保留未知，執行失敗不算零引用。

GEO 團隊今天可以落地的清單

1. 列出涵蓋各類頁面的核心 URL，標記公開、preview、敏感三類。
2. 盤點 crawler：將 AI search、assistant、training 分開，不用「AI bot」一個標籤帶過。
3. 先確認私有頁的存取限制，再檢查公開頁的 robots、sitemap、canonical 與正文。
4. 對私有路徑驗證登入與授權；WAF/bot 規則依政策補充，保存命中日誌。
5. 每週比較 crawl success、政策違規、AI citation 與錯誤引用四條時間序列。

來源與判讀界線

• Google Search Central：AI features and your website，2026-09-09 查閱。說明 Google AI 搜尋沿用 SEO 基礎及呈現不保證。
• Cloudflare：AI Crawl Control overview，2026-08-14。官方產品文件，說明 crawler 觀測、政策與 robots.txt 遵循度。
• Cloudflare：robots.txt setting，2026-08-03。官方文件，明確區分 robots.txt 意願宣告與強制封鎖。
• Cloudflare：Control how AI crawls your docs，2026-04-24。官方工程文件，說明 preview 站遭 AI crawler 讀取時的 robots 與安全控制案例。

上述文件支持 crawler 分類、觀測與強制控制的事實基礎；本文的四層模型、測試矩陣與指標欄位是 YOTRON 的實務分析，不是任何平台公開的排名公式。

結語

AI crawler 治理不是在 robots.txt 寫完一行就結束。把意願宣告、請求觀測、強制執行與 GEO 回歸測試接成一條管線，才能在「讓正確的 agent 進來」與「阻擋不該進來的流量」之間做出可驗證的取捨。

相關推薦與延伸閱讀

• AI crawler 存取治理：用 robots.txt、WAF 與日誌驗證 GEO 可見性：以 robots.txt、WAF 與日誌排查特定爬蟲的存取問題，分清模擬請求、已驗證來源及實際 AI 引用；技術通過不等於被採用。本文先把三種控制分開，用請求路
• AI Agent 可讀性與 GEO：把可讀性變成可測試的內容契約：建立 AI agent 可讀性的驗收方法：分開檢查 HTTP 內容、瀏覽器操作、資料一致性及實際引用，避免把技術檢查通過誤當成引擎採用證據。本文先定義四個可測試
• GEO 引用驗證：用固定查詢找出 AI 搜尋的真實缺口：AI 搜尋的曝光不是單一排名。本文把 GEO 轉成固定查詢、引用證據與正確性回歸測試，分開觀測條件、有效分母與失敗原因，避免從單次答案推定成效。內容包含如何定義