先講結果：代理瀏覽到底在測什麼

先把定義釘死，後面才好聊。代理瀏覽（Agentic Browsing）是 Lighthouse 這套 Google 的網站健檢工具在 2026 年 5 月新增的一個分類。它衡量的是一件過去所有分類都沒碰過的事：當一個 AI 代理（不是人、也不是傳統搜尋爬蟲）打開你的頁面，它能不能讀懂內容、看懂上面的按鈕和表單、信任版面不會亂跳，然後在沒有人在旁邊手動操作的情況下，把一件事做完。

過去我們講「網站好不好」，其實只顧兩種訪客：一種是等頁面載入的人類，一種是來爬來索引的 Googlebot。Lighthouse 這幾年幾乎就是繞著這兩位設計的。代理瀏覽等於是承認第三種訪客已經到場了——它會自己點、自己填、自己買。

我自己拿幾個客戶的站去跑，最直接的體感是：這一項跟你有沒有花錢做「AI 功能」沒什麼關係。一個內容乾淨、標籤語意正確的簡單頁面，反而輕鬆拿滿；反倒是那些用一堆 JavaScript 硬刻出來、看起來很炫的互動元件，代理讀起來一片茫然。

這東西是什麼時候悄悄冒出來的

時間點其實很好追。Lighthouse 13.3.0 在 2026 年 5 月 7 日釋出，把代理瀏覽這個分類從「實驗性、要自己去開旗標」直接搬進了預設設定。因為 PageSpeed Insights 底層就是用 Lighthouse 在跑實驗室診斷，所以大約兩週後（差不多五月下旬），每一個到 pagespeed.web.dev 打網址的人，報告裡都自動多了這一塊，Chrome 150 的開發者工具接著跟上。

沒有記者會、沒有部落格大張旗鼓宣布，就是改版說明（changelog）裡的一行字。等大部分人「發現」它的時候，它已經在每一份報告裡跑了一陣子了。這種「實驗性功能→兩週後變預設」的節奏，比多數人想像的快很多。

Google 為什麼「現在」要加這一項

核心原因只有一句話：AI 代理已經是真實流量，而且大到不能假裝沒看到。

OpenAI 的 Operator、Anthropic 的 Computer Use、Google 自己的 Project Mariner、Perplexity、還有 ChatGPT 的瀏覽模式——這些代理現在會替使用者跑到你的網站上比價、查資料、訂位、下單。打進公開網站伺服器的請求裡，有相當一部分、而且比例還在長，已經不是人，是軟體。Adobe 的資料就抓到，2026 年第一季美國零售網站的 AI 導入流量，年增了 393%。這不是未來式，是正在發生的事。

問題是，這些代理到了大多數網站，大多數時候是做不完事情的。原因很結構性：現代網頁是為「一顆人類眼睛看著圖形化瀏覽器」而設計的，不是為「一個上下文預算可能只有幾十 KB 的語言模型」而設計的。滿版的導覽列、廣告、追蹤程式碼、一堆靠 JavaScript 才點得動的自訂元件，對人來說是體驗，對代理來說全是雜訊和障礙。

效能分數是給「等一個慢頁面的人」看的；代理瀏覽則是第一次，Google 把量尺對準了「一個看不懂你花俏版面的機器」。

所以 Google 加這一項的動機，說穿了不是要罰你，而是要在代理經濟真的成形之前，先把「你的網站對機器友不友善」這件事，變成一個站長跑報告時會順手看到的東西。它把一個原本只有少數前端和 SEO 圈在討論的抽象議題，塞進了每天有無數人在用的免費工具裡。這個動作本身，就是一種很強的訊號。

代理瀏覽實際檢查哪些項目

網路上已經有不少亂寫的文章，發明了一些根本不存在的檢查項目。這裡照 Google 自己的 Lighthouse 文件講清楚：在 PageSpeed Insights 的預設報告裡，代理瀏覽主要由三個核心檢查構成，而更完整的 Lighthouse 分類還會稽核 WebMCP 相關的項目。下面用表格整理。

看完這張表，你八成會發現一件有趣的事：前兩項——乾淨的語意結構、穩定的版面——根本就是無障礙設計跟核心網頁指標的基本功。也就是說，如果你網站對使用螢幕閱讀器的人友善、CLS 顧得好，你不用為了 AI 特別重蓋一個網站，這一項自然就過一大半。真正「新」的東西，其實只有 llms.txt 和 WebMCP 這兩塊。

一直被提到的 llms.txt 是什麼

既然它是代理瀏覽三大檢查之一，這裡花點篇幅講清楚。llms.txt 是一份放在你網域根目錄的純 Markdown 檔（就像 robots.txt 放的位置），裡面用人和機器都讀得懂的方式，寫下你網站的簡介、有哪些重要頁面、產品服務是什麼。有一個延伸版本叫 llms-full.txt，會把那些連結頁面的內容直接嵌進去，讓代理一次抓取就吃到全部。

它存在的理由很實際：HTML 對語言模型來說太吵了。導覽、JavaScript、廣告、追蹤像素，會在模型讀到真正有用的內容之前，就先把上下文預算燒光。有公司改用 Markdown 餵給模型後，回報 token 用量能降到原本的十分之一，這直接換算成更快、更便宜、更準的代理行為。

不過講一句公道話，也是我覺得多數教學沒講的：llms.txt 目前不是 IETF 或 W3C 的正式標準，只是一個有社群熱度的提案；而且它跟「AI 搜尋引用你」之間的關係，證據其實很薄。有研究掃了幾十萬個網域，採用率大概一成上下；在真正會帶來引用的爬蟲流量裡，會去碰 /llms.txt 的比例低到幾乎可以忽略。所以請把它擺對位置——它是「代理讀取準備度」的一張入場券，成本低、順手就做，但別把它當成能拉排名的魔法。

為什麼是 3/3 而不是 92 分

這是代理瀏覽跟其他四個分類最不一樣的地方，也是它在暗示你怎麼看待它。效能、無障礙這些分類都給你一個加權後的 0 到 100 分；代理瀏覽偏偏給你一個通過比例，像 2/3、3/3，就是「幾項檢查有過」的計數而已。

規格團隊是刻意這樣設計的。他們的說法是，agentic web 的標準都還在成形，現階段重點是「先蒐集可行動的訊號」，而不是急著給你一個看起來很精準、其實會誤導的分數。這個分類目前明確被標成「開發中」，檢查項目和計分方式之後都可能變。所以拜託，先別急著把 3/3 寫進你這一季的 OKR。

還有一個細節能幫你抓對心態：一個內容幾乎空空如也的 example.com，反而能拿滿分比例。這說明它不是在懲罰你「沒有 AI 功能」，它比較像一張機會清單、一份提醒你去補的檢查表，而不是一個會扣你分的裁判。

站長現在該做的幾件事

與其焦慮，不如照順序做。這是我實際會給客戶的優先清單：

1. 先去跑一次，看你現在幾分之幾。到 pagespeed.web.dev 輸入網址，或用 Chrome 150 開發者工具的 Lighthouse。想接進 CI 流程的話，指令是 npx lighthouse@latest <url> --only-categories=agentic-browsing，會吐出每一項通過與否的 JSON。
2. 把無障礙的地基顧好。該用 button 就別用一個綁了 onClick 的 div，該有 label 的表單就把 label 補上，標題階層 h1、h2、h3 別亂跳。這是投報率最高的一步，因為它同時餵飽了螢幕閱讀器使用者、傳統 SEO 和 AI 代理三種訪客。
3. 壓低 CLS。圖片、廣告、動態載入的區塊都先預留好尺寸，別讓版面在載入時亂跳。這一項你八成早就在為核心網頁指標做了。
4. 寫一份誠實的 llms.txt。放在根目錄，用 Markdown 寫清楚網站簡介與重點頁面連結。成本很低，就當作 AEO（Agentic / Answer Engine Optimization）基礎建設的一部分順手做掉，但別對它抱不切實際的排名期待。
5. WebMCP 先觀望、選擇性投入。它還在 origin trial 階段（Chrome 149 起），除非代理流量已經是你明確的商業重點，否則不急著全面導入，先把前面四步做扎實更划算。

最後一個大家最想問的：這會影響排名嗎

直接回答：目前不是搜尋排名因素。這點要分清楚兩件事。PageSpeed Insights 會有這個分類，是因為它底層用 Lighthouse 做實驗室診斷，Lighthouse 加了、它就跟著繼承——這不等於 Google 搜尋宣布了一套新的排名系統。Lighthouse 裡本來就有很多「對品質有意義、但不是單獨排名因素」的稽核項目，代理瀏覽現階段就是這一類。

但「不是排名因素」不等於「可以無視」。它是一個很清楚的方向訊號：主流的網站品質標準，正在從「只服務人類體驗」往「也要顧機器互動」擴張。當替使用者比價、下單的代理越來越多，一個代理讀得懂、點得動的網站，拿到的就不只是分數，而是實際的成交機會。你可以把今天的代理瀏覽，看成幾年前剛出現、大家還半信半疑的「行動裝置友善度」——一開始只是個提醒，後來變成不做不行的基本盤。

與其等到你的老闆、客戶或跑稽核的合作對象，某天回頭問你「我們的代理瀏覽怎麼是紅的」，不如趁它還在開發中、大家都還在起跑線的這段空窗期，先把地基顧好。反正這些事——語意乾淨、版面穩、內容清楚——本來就對真人使用者比較好，只是現在多了一群機器訪客，替這些老派的好習慣，補上了一個全新的理由。