Cloudflare 在 2026 年 11 月 4 日新增 Personal Agent 的流量分析與個別存取控制。網站管理者可以在 Security Analytics 看到 Personal Assistants 類別、請求路徑與狀態碼，並在重新命名的「AI Crawler and Agent access policies」中，對支援的 personal agent 分別選擇 Allow、Block on pages with ads 或 Block，而不必只用一個整體 Agents 政策處理所有代理流量。

Personal agent 是代表某位使用者即時取用或操作網站的代理，例如比較商品、尋找客服文件或協助完成購買。它與預先蒐集內容的 Search crawler、拿內容訓練模型的 Training crawler 不完全相同。這次更新也不是 Google 排名演算法公告，更不代表允許代理就一定增加 SEO 流量；它提供的是邊緣層的辨識、觀察與存取決策工具。

為什麼全面封鎖可能不是最安全的商業決策

對內容網站而言，Training crawler 涉及內容是否被用於訓練；Search crawler 牽涉未來回答的索引；Personal Agent 則可能正替一位潛在讀者找文章。三種行為的目的、時效與商業價值不同，用同一條「所有 AI bot 全擋」規則處理，容易把授權與風險完全不同的請求混在一起。

電商網站更明顯。代理讀取公開商品資料、比較規格與查詢庫存，可能是有效導購；但登入會員、加入購物車、套用折扣與結帳會碰到身分、付款、防詐與庫存狀態。允許讀取不等於授權交易，允許某個 verified personal agent 也不等於應略過 WAF、rate limit、bot protection 或登入驗證。

Cloudflare 官方說明中，Personal Agents 預設繼承整體 Agents policy，修改整體政策也會更新個別 agent，之後才可再覆寫。若團隊過去已設置 Agents 規則，這個繼承關係要先記錄；否則管理者可能以為只改一個總開關，實際上覆蓋先前逐一調整的選擇。

先用流量資料建立頁面風險分級

不要在沒有基準資料時直接 Allow 或 Block。先觀察一段具代表性的期間，按 agent、path、status code、來源 network 與時間分布整理。特別找出大量 401、403、404、429、反覆登入、搜尋濫用、購物車建立與高成本動態頁面。請求量只是訊號，不能單獨證明是好流量或攻擊；要與轉換、客服、錯誤與基礎設施成本一起判讀。

接著把路徑分成公開內容、公開商品、站內搜尋、登入後資料、會改變狀態的操作與高敏感交易。公開內容可優先允許已辨識的 personal agent；會員資料與交易 API 必須維持一般授權、CSRF、防重送與風控。robots.txt 適合表達 crawler 偏好，但官方文件也提醒 robots 指令是自願遵循；需要強制限制時，應使用 edge policy 或 WAF，不要把 robots.txt 當成存取控制。

對有廣告的 publisher，Block on pages with ads 是介於全面允許與全面封鎖之間的選項，但仍需確認 Cloudflare 對實際頁面的偵測是否符合自己的版位與商業規則。若付費牆、會員文章或授權條款有另外要求，應由應用層根據使用者身分執行，而不是只依 agent 名稱決定。

電商、內容與服務網站的政策起點

內容型網站可從「允許公開文章、封鎖管理與會員路徑」開始，Training policy 則依內容授權另行決定。電商可允許商品、分類、FAQ 與公開庫存資訊，但對搜尋端點設定合理 rate limit，對購物車和結帳維持正常 session、冪等鍵、價格重算與庫存檢查。不要讓 agent 傳來的商品價格或折扣成為可信來源。

預約與服務網站可允許代理讀取服務項目、可預約條件與公開時段，但建立、修改與取消預約仍應驗證使用者、同意條款與通知管道。若代理代填表單，要在 audit log 留下 user、agent、action、request id 與結果，避免日後只能看到一串自動化流量而無法還原授權關係。

在地商家官網則應先確保地址、營業時間、服務區域與聯絡方式有一致且可讀的 HTML 與結構化資料。允許 personal agent 無法彌補內容缺漏、JavaScript 才能看到關鍵資訊或錯誤 canonical。這次功能是存取治理，不是傳統 SEO 基礎工作的替代品。

上線前的驗收與回滾

先匯出或截記目前 Search、Agents、Training 與個別 personal agent 設定，建立變更 owner 和觀察窗口。一次只調整一個 agent 或一類路徑，從公開低風險頁面開始。使用實際 user flow 驗證頁面內容、狀態碼、登入、購物車、結帳與錯誤處理；同時確認人類使用者、傳統搜尋 crawler 與其他 API client 沒有被連帶封鎖。

監看至少包含成功率、403／429、origin 負載、搜尋成本、cart 建立、checkout 啟動與完成。這些指標只能顯示關聯，不能因政策變更後轉換上升就直接宣稱全部由 agent 帶來；要用 request、session 或可接受的 attribution 設計分辨。對高風險 endpoint，應準備立即回到繼承政策或 Block 的操作步驟。

選擇上，純公開文件與商品內容可以較積極允許已辨識的 personal agent；靠廣告變現的頁面可評估 Block on pages with ads；會員、金融、醫療或高價交易流程則應先完成身分與授權模型，再逐步開放。無法從資料判斷 agent 是否有價值時，先觀察而非猜測。

網站流量正在從「人或 crawler」變成 Search、Training、Agent 與人類混合的多種意圖。Cloudflare 這次更新的實際價值，是讓團隊能把不同用途拆開決策。好的政策不會以允許或封鎖作為終點，而會清楚定義哪些公開資訊可被代理取用、哪些動作需要使用者授權，以及發生異常時如何撤回。