專題文章PageSpeed Insights 裡面有一項【代理瀏覽】，這是哪種稽核？
次閱讀
簡單一句話先給答案：「代理瀏覽（Agentic Browsing）」是 Lighthouse 13.3 在 2026 年 5 月新增的一個稽核類別，用來檢查你的網站對「AI 代理」友不友善，而不是給人看或給搜尋引擎爬蟲用的。它一次跑四項檢查——無障礙樹結構、版面位移（CLS）、WebMCP 工具註冊、以及 llms.txt 檔案——但它不給 0 到 100 的分數，也不影響你的 Google 搜尋排名。
如果你最近打開 PageSpeed Insights 或 Chrome DevTools 的 Lighthouse，發現除了「效能、無障礙、最佳做法、SEO」之外多了一塊看不懂的東西，你不是唯一一個。這篇會把它是什麼、為什麼會冒出來、四項各自在測什麼、要不要理它、以及怎麼自己動手跑一次，一次講清楚。
什麼是「代理瀏覽」稽核？
Lighthouse 是 Google 出的網站健檢工具，內建在 Chrome DevTools、Lighthouse CLI，也就是 PageSpeed Insights 背後的引擎。過去它只有四個計分類別：效能、無障礙、最佳做法、SEO。
2026 年 5 月 7 日，Lighthouse 13.3.0 正式把「代理瀏覽」這個類別從實驗性推進到預設設定裡。換句話說，從那個版本開始，任何人跑一份標準的 Lighthouse 報告——以及稍晚同步的 PageSpeed Insights 和 DevTools——都會自動看到這塊代理就緒度的訊號，不用另外開啟任何設定。
它跟其他類別最大的差別在於「服務對象」。效能是為了人類使用者的體感速度、SEO 是為了搜尋爬蟲，而代理瀏覽衡量的是另一種訪客：自動化的 AI 代理。像是 OpenAI 的 Operator、Anthropic 的 Computer Use、Google 的 Project Mariner、Perplexity 的 Comet，還有各家瀏覽器內建的 AI 助理。這些代理不是用眼睛看你的頁面，而是用程式去讀結構、點按鈕、填表單，代替使用者完成任務。
Google 官方文件的說法很直白：這個類別評估的是「你的網站對機器互動的建構程度有多好」，用的是一組確定性（deterministic）的稽核。
Google 為什麼現在要加這個？
答案藏在流量數據裡。Chrome 的工程團隊看得到，打到公開網站伺服器的請求中，有一塊持續成長的比例既不是人類、也不是傳統搜尋爬蟲，而是 AI 代理。當愈來愈多購物、訂位、查資料的動作是由代理代勞，「這個網站對代理來說能不能用」就變成一個實際的品質問題，不再是科幻情節。
這裡有個容易讓人誤會的時間點要特別講清楚。因為代理瀏覽稽核裡包含了對 llms.txt 的檢查，而它上線的時間又剛好跟一波「llms.txt 是不是新的排名因素」的討論撞在一起，很多人以為 Google 在暗示 llms.txt 能幫助 SEO。這是誤讀。Google Search 和 Chrome Lighthouse 是兩個不同團隊、指向兩個不同的未來——Search 排名的是可爬取的 HTML，而且公開表示不使用 llms.txt；Lighthouse 衡量的則是「網站對 AI 代理準不準備好」，是完全不同的問題。這點下面第五節會再展開。
四項檢查逐一拆解
代理瀏覽目前跑四項稽核，每一項都對應到「AI 代理實際操作網站時真正需要的東西」。有趣的是，其中兩項其實是老朋友——做過無障礙和效能優化的團隊，等於已經先跑了一段。
| 稽核項目 | 它在檢查什麼 | 對代理的意義 | 是不是全新概念 |
|---|---|---|---|
| 無障礙樹結構（Accessibility Tree） | 頁面的無障礙樹是否結構完整、標籤清楚 | 代理跟螢幕報讀器一樣是「非視覺使用者」，靠語意結構判斷這是按鈕還是連結、這個欄位要填什麼 | 否，無障礙優化多年來的老功課 |
| 累計版面位移（CLS） | 頁面載入過程中元素會不會亂跳 | 代理在「辨識元素」和「點下去」之間有時間差，版面一位移，它就可能點錯地方 | 否，核心網頁指標的老項目 |
| WebMCP 工具註冊 | 網站有沒有用 WebMCP 把功能以結構化工具的方式暴露給代理 | 讓代理直接呼叫「加入購物車」「搜尋」這種功能，而不是靠截圖或硬爬 DOM 去猜 | 是，2026 年才進入 Origin Trial 的新標準 |
| llms.txt 檔案 | 網域根目錄有沒有一份符合規範的機器可讀摘要檔 | 讓代理不用把整站爬過一遍，就能快速搞懂「你是誰、你有什麼」 | 是，社群提案的新慣例 |
WebMCP：從「用截圖操作」到「直接呼叫功能」
WebMCP 大概是這四項裡最值得認識的一個。它是瀏覽器原生的 API，讓網站用兩種方式把自己的功能開放給代理：一種是宣告式的，直接在 HTML 表單上加註特定屬性；另一種是命令式的，透過 navigator.modelContext.registerTool 用 JavaScript 註冊工具。這個稽核會去看你的表單有沒有加註、加註的 schema 對不對。
它跟 llms.txt 的差別可以這樣記：llms.txt 是一張讓代理讀完就懂方向的靜態地圖；WebMCP 則是一個代理可以直接呼叫、真的把事情做完的即時介面。一個管「讀」，一個管「做」。
llms.txt：一份放在根目錄的自我介紹
llms.txt 這項檢查很單純，就是看根目錄有沒有這份檔案、能不能存取、格式對不對——規範上要有一個 H1 標題、一段可選的摘要引言（blockquote 形式），底下用 H2 分區塊列出重要連結。Google 的說法是，少了這份檔，「代理可能得花更多時間爬整站，才搞得懂網站的高層結構和主要內容」。
為什麼它沒有 0 到 100 的分數？
如果你習慣看效能那個綠色圓圈數字，第一次看代理瀏覽會有點錯亂——它不給你一個加權後的總分，而是給一個「通過比例」，例如「4 項通過 3 項」，再加上每一項各自的通過或失敗狀態。
這是 Google 刻意的決定。原因也很實際：整個代理網頁的標準——包括 WebMCP 和 llms.txt——都還在成形當中，此刻硬給一個加權總分只會誤導人，讓大家以為分數高就代表某種確定的優勢。Google 明說了，現階段目的是「蒐集數據、提供可行動的訊號」，而不是給出一個確定的排名。等底層規格穩定下來，官方保留了未來加上數字分數的空間。
會影響我的 Google 排名嗎？
不會，至少目前不會直接影響。這是最多人問、也最需要講白的一點。
Google 的 John Mueller 已經公開確認，Google 不會爬取也不使用 llms.txt 檔案，Google 的 AI 系統目前也不吃這份檔。Anthropic、OpenAI 同樣沒有確認會使用它。代理瀏覽這個類別本身，也根本不評估搜尋排名這件事。
不過話說回來，「不直接影響排名」不代表「沒價值」。四項稽核裡有三項——無障礙樹、CLS、語意化 HTML——本來就跟「對真人更好用」高度重疊。也就是說，你為了通過代理瀏覽去修的東西，很大一部分同時讓你的網站對真實使用者、對螢幕報讀器、對搜尋引擎都更友善。這種「一魚多吃」才是它真正的實用之處，而不是去追一個不存在的排名紅利。
把它當成 AEO（面向 AI 代理的優化）的免費基礎建設來做，別把它當成引用或排名的槓桿——這是我目前給客戶的建議。
怎麼自己跑一次代理瀏覽稽核？
方法不難，但版本是關鍵。整理成可以照著做的步驟：
- 確認 Chrome 版本。代理瀏覽類別隨 Lighthouse 13.3 進入預設設定，需要 Chrome 150 或更新版本。如果你在 Chrome 130 到 149 之間，得先到
chrome://flags/#enable-webmcp-testing把旗標設成「Enabled」再重開瀏覽器；其中 WebMCP 這項稽核還需要註冊 WebMCP 的 Origin Trial 才會完整運作。 - 打開 DevTools。Mac 按 Cmd+Option+I，Windows 按 F12，切到 Lighthouse 分頁。
- 勾選「Agentic Browsing」類別，然後點「Analyze page load」。
- 看 pass/fail 結果。報告會列出四項各自的通過或失敗，以及整體的通過比例，而不是一個 0 到 100 的分數。
實務上，建議先拿「互動最重」的頁面來測——結帳流程、表單、會員後台、訂位介面。這些頁面正是代理最可能替使用者操作、也最容易卡關的地方。首頁通常反而沒什麼好測的。
預算有限的話，先修哪一項？
四項不必一次全上。按投入成本和效益排，我的實作優先順序是這樣：
| 如果你有的時間 | 先做這件事 | 為什麼 |
|---|---|---|
| 一小時 | 修無障礙樹 | 重疊效益最高：同時改善代理可讀性、鍵盤操作、螢幕報讀器體驗，一次修三種使用者 |
| 一個下午 | 寫一份像樣的 llms.txt，順手修掉明顯的 CLS | 兩者都是確定性的、成本低、容易驗證是否通過 |
| 一週加一點研究預算 | 在一條高價值流程上試做 WebMCP | 挑搜尋、加入購物車、或找文件這種單一關鍵動作先原型化，不用全站上 |
對多數中小型網站來說，比較務實的路線是：把 llms.txt 當成最好拿的分數先出，跑一次代理瀏覽當基準線，補掉無障礙樹的破洞（反正這對真人也有幫助），然後持續觀察 WebMCP、但先別急著全面導入。畢竟目前 WebMCP 只支援 Chrome，真正會呼叫 WebMCP 工具的代理也還不多。等你下一次要重建結帳、訂位或搜尋這類關鍵流程時，再順勢把它做進去，時機剛剛好。
llms.txt 和 WebMCP 差在哪？別搞混
這兩個最常被混為一談，但它們解決的是完全不同層次的問題。用一張表看最清楚：
| 面向 | llms.txt | WebMCP |
|---|---|---|
| 本質 | 靜態的機器可讀摘要檔 | 即時的程式化介面 |
| 代理拿它做什麼 | 「讀」——快速orient自己，搞懂網站方向 | 「做」——直接呼叫功能、完成動作 |
| 放在哪裡 | 網域根目錄的一份文字檔 | HTML 屬性標註或 JavaScript 註冊 |
| 導入成本 | 低，一份 Markdown 就能起步 | 高，需要工程投入與 Origin Trial |
| 成熟度 | 社群提案，採用率約一成 | 提案中的瀏覽器標準，實驗階段 |
我自己的觀察是：很多討論卡在「llms.txt 到底有沒有用」的文字檔之爭，反而忽略了代理瀏覽稽核裡真正被 Google 放上重量的是 WebMCP。前者是輔助定位的地圖，後者才是讓代理真正在你網站上「動手」的那一層。兩件事都可以成立，因為它們本來就不是在回答同一個問題。
接下來該怎麼看待這件事
回到最初的問題：PageSpeed Insights 裡那項「代理瀏覽」，是一個衡量你的網站對 AI 代理友不友善的稽核類別，跑無障礙樹、CLS、WebMCP、llms.txt 四項，給通過比例而不是分數，也不直接影響 SEO 排名。
它現在還掛著「開發中」的標籤，標準也還在跑，所以不用把它當成必須立刻衝滿的 KPI。但它傳達的方向很清楚：Google 第一次正式對「AI 代理就緒度」放上了一個可追蹤的訊號。與其把它當成又一個 buzzword，不如當成一份健檢清單——先修那些對真人和代理都有好處的基礎（無障礙、版面穩定），再視自家業務對代理流量的重視程度，決定要不要投資 WebMCP。
換個角度看，這其實是件好事：讓網站對機器更好讀、更好操作的那些工程，幾乎每一項都同時讓它對人更好用。這種方向，值得現在就開始動手。