PageSpeed Insights 多年來一直為效能、無障礙、最佳做法與 SEO 四個項目評分。2026 年，這一列悄悄加入了第五個項目：Agentic Browsing（代理式瀏覽）。它回答了其他四個類別長久以來忽略的一個問題——AI 代理真的能操作這個頁面嗎？
本文要談的是如何把這項檢查實際用在你的網站上：跑一次、讀懂每一項稽核到底在說什麼，最後帶著一份修正清單離開。
讀完這篇你會得到什麼
適合誰讀： 想知道網站在 AI 代理而非人類瀏覽時會如何表現的 SEO、開發者與網站經營者。
讀完後你手上會有： 自己網站的實際 Agentic Browsing 結果、逐項判讀通過／失敗／不適用的紀錄，以及一份排好優先順序的修正清單。
前置條件： 一個可公開存取的網址、第一次執行約十分鐘，以及當天就要動手修正所需的程式碼存取權。
完成標準： 你能逐項說明分數的組成，並判斷哪些失敗會真正阻礙代理在你的頁面上完成任務。
這項檢查的由來，以及為什麼是現在
Agentic Browsing 類別在一年前並不存在。上線分成三個階段，全部都有 Google 的官方紀錄：
- 2026 年 5 月 7 日： Lighthouse 13.3 將這個類別加入預設設定，成為標準執行的一部分。
- 2026 年 6 月 22 日： Chrome for Developers 部落格在〈A developer toolkit to make your website agent-ready〉一文中發表這個類別，同時介紹代理用的 DevTools 與 WebMCP 指引。
- 2026 年 7 月 20 日： Lighthouse 13.4.1 讓這個類別在 PageSpeed Insights API 路徑上啟用，並在版本說明中寫道，這個版本「預計兩週內」進入 PageSpeed Insights。也就是說，正式上線落在 2026 年 8 月初。
我在 2026 年 9 月 11 日執行這項檢查時，報告頁尾顯示的是 Lighthouse 13.4.1 的模擬執行，而 Agentic Browsing 就緊鄰在 SEO 旁邊。換句話說，這個功能已經正式上線，不是 Canary 專屬。但它同時也明確尚未完成。報告中的類別說明就寫得很直白：這個類別仍在開發中，隨時可能變動。
開始之前有一個實務提醒：PSI 是在 Google 端為你執行這個類別。頁面層級的檢查不需要 Chrome 150，也不需要 origin trial。有版本要求的是在 Chrome DevTools 本機執行的情況。
在自己的網站上執行這項檢查
- 打開 pagespeed.web.dev，貼上你的網址。先跑行動版，再跑一次桌機版，因為兩次實驗室執行是分開評分的。
- 等待實驗室資料完成。 頁面上方的實測資料來自 Chrome UX Report，載入很快；下方的 Lighthouse 執行較久，類別就在那裡。
- 找到分數那一列。 依序是效能、無障礙、最佳做法、SEO，接著是以分數而非 0–100 呈現的 Agentic Browsing。
- 展開類別。 稽核清單會分成 Agent Accessibility、WebMCP，以及一貫的通過與不適用兩堆。
- 逐一點開失敗的稽核。 每一列展開後都會顯示造成失敗的具體規則、元素或檔案，這正是開修正工單所需的資訊。
第五個類別就坐在 SEO 團隊每天查看的分數旁邊。2026 年 9 月 11 日於 PageSpeed Insights 擷取。
品質檢查： 和同事比較結果之前，先確認執行詳情中的 Lighthouse 版本。PSI 會依自己的時程更新 Lighthouse，而這個類別仍在版本之間持續變動。
如果失敗： PSI 偶爾會在沉重頁面上回傳 RPC 逾時。我在研究期間就在一個大型網站上遇過。請重試，或改用本機 Lighthouse 測試。
正確解讀分數
Agentic Browsing 沒有加權的 0–100 分數，這是刻意的設計。Lighthouse 的文件指出，代理網頁的標準仍在成形，因此重點放在可採取行動的訊號，而不是排名。
真正重要的算術是這個：
顯示 | 意義 |
|---|---|
3/3 | 所有計分稽核都通過。不適用的稽核不列入。 |
1/3 | 一項通過、兩項失敗。分母只包含通過與失敗的稽核。 |
0/3 | 計分項目目前都還沒通過。在廣告密集的沉重頁面上首次執行時很常見。 |
沒有分數 | 所有稽核都不適用，或這個類別沒有執行。請檢查執行詳情。 |
陷阱在於把 1/3 讀成「代理就緒度 33%」。它不是任何東西的百分比，而是一個計數：該頁面可計分的三項檢查中有一項通過，而不適用的稽核完全沒有進入計算。在我擷取的報告裡，共執行六項稽核，三項不適用，剩下三項產生了 1/3。
同一頁面的分數也會在多次執行之間變動。Lighthouse 點名的三個原因是：動態工具註冊（以 JavaScript 註冊的 WebMCP 工具會因時序而被捕捉或錯過）、改變無障礙樹的 DOM 變動，以及廣告、未指定尺寸的圖片或注入內容造成的版面位移。數字若在晃動，通常就是這些原因。
逐項檢視六項稽核
目前的 PSI 版本會執行六項稽核，還有一項即將加入：Lighthouse 的開發分支已經在新的 Agent Discoverability 群組下加入 ai-catalog.json（Agent Resource Discovery）檢查，所以請把這份清單視為版本相依。
稽核 | 檢查內容 | 「不適用」代表什麼 |
|---|---|---|
無障礙樹格式不正確 | 以代理為重點的無障礙規則子集：程式可讀的名稱與標籤、有效的 ARIA 結構，以及即使被隱藏仍可互動的元素 | 不會出現；永遠會計分 |
llms.txt 未遵循建議 |
| 檔案回傳 404。缺少 llms.txt 被視為選用，而不是失敗 |
累積版面位移 | 視覺穩定性，讓依元素位置行動的代理不會在位移過程中點錯東西 | 不會出現；永遠會計分 |
WebMCP 工具註冊 | 頁面是否透過宣告式或指令式 API 註冊任何 WebMCP 工具 | 未偵測到任何 WebMCP 工具 |
WebMCP 表單涵蓋範圍 | 缺少工具註解的宣告式表單 | 同上 |
WebMCP 結構描述驗證 | 已註冊工具是否發布有效的輸入與輸出結構描述 | 同上 |
展開後的類別檢視：兩項失敗、一項通過、三項不適用。失敗清單就是最短的工作清單。
三項 WebMCP 稽核顯示「不適用」在 2026 年是正常的。WebMCP 是提案中的標準，處於 origin trial 與早期預覽階段，有兩套 API：一套是為標準 HTML 表單加上註解的宣告式 API，另一套是從 JavaScript 註冊工具的指令式 API。多數網站兩者都還沒實作，所以多數報告在那裡會出現三個灰圓。灰色不是紅色，不要把它當成失敗。
修正檢查標記的問題
四大修正主題涵蓋六項稽核。三列 WebMCP 只有在你真的提供代理工具時才需要處理。
讓無障礙樹可供代理讀取
代理把無障礙樹當成頁面的主要地圖，它列出角色、名稱與狀態。一個沒有可存取名稱的按鈕，對它們是死路，對螢幕閱讀器使用者也是。
做法： 逐一處理展開稽核中的失敗規則。常見的嫌疑犯包括只有圖示的按鈕、沒有標籤的表單欄位、文字只有「點這裡」的連結、無效的 ARIA 角色組合，以及被 ARIA 參照的重複 ID。優先使用語意化 HTML，為標籤加上 for 屬性，無法使用原生元素時，為自訂元件指定明確的 role 與 tabindex。
預期結果： 稽核轉為通過，而且無障礙分數通常會同時提升，因為 Agentic Browsing 版本是同一套檢查的精簡子集。
卡住時的補救： 如果修正清單累積到數百個元素，不要逐一追。先修共同元件，例如頁首那顆只有圖示的按鈕，然後重新執行。一個元件往往能清掉數十列。
發布能通過格式檢查的 llms.txt
這裡有個會絆倒細心人的陷阱。這項稽核不只看 /llms.txt 是否存在，它還檢查檔案內容，而只列出裸網址的檔案會失敗，因為檢查要找的是 Markdown 形式的連結。
做法： 在根網域建立 /llms.txt，包含 H1 標題與真正的 Markdown 連結：
# 公司名稱
簡短說明網站涵蓋的內容，以及希望它被如何使用。
## 主要頁面
- [產品總覽](https://example.com/product)
- [價格](https://example.com/pricing)
- [文件](https://example.com/docs)預期結果： 稽核轉綠。相對地，404 會顯示為不適用，目前是可接受的狀態。500 系列回應或抓取錯誤則是真正的失敗，需要從伺服器端修正。
品質檢查： 在終端機抓取自己的 /llms.txt，數一數連結。如果它們長得像 https://example.com/pricing、沒有中括號，那麼即使檔案已上線、人看得懂，稽核仍會失敗。
一個誠實的提醒：Google 搜尋並不使用 llms.txt。Google 自家的 AI 最佳化指南寫得很清楚，這個檔案「對網站在 Google 搜尋中的能見度或排名既無幫助也無害，因為 Google 搜尋會忽略它們」。請為會讀這個慣例的代理工具而寫，而不是為了排名。
穩定版面配置，讓代理能準確點擊
版面位移比以前更重要了。代理先是找到按鈕，接著點擊它的座標；如果廣告、橫幅或晚載入的圖片在這兩個瞬間之間把按鈕往下推了 200 像素，點擊就會落空。
做法： 為圖片與嵌入內容設定明確的 width 與 height（或 aspect-ratio）、為廣告版位與同意聲明橫幅保留固定空間、避免在載入後於既有內容上方插入新內容，並以 transform 而非觸發版面的屬性製作動畫。
預期結果： 實驗室執行中的累積版面位移低於 0.1，也就是 Core Web Vitals 採用的同一門檻。
品質檢查： 報告中效能區塊的「版面位移主因」洞察會指出確切的元素。從那裡開始，不要憑猜測。
WebMCP 可以之後再決定
三項 WebMCP 稽核只有在網站註冊工具時才會計分。如果你有預約流程、結帳、支援表單，或任何代理能完成的結構化任務，WebMCP 值得做個原型：它直接告訴代理該呼叫哪個工具，而不是讓代理從 DOM 猜測。Chrome 把這項功能放在 origin trial 與本機測試旗標之後，所以它是真實的選項，不是空談。
如果沒有值得自動化的任務，就別碰 WebMCP。三個灰圓沒有任何問題。唯一不該做的事，是為了讓分數好看而註冊裝飾性工具。這個類別是就緒度的訊號，取巧只會讓它失去意義。
驗證修正結果
在 PSI 重新執行同一個網址，並比較三件事而非一件：分數、個別稽核狀態，以及裝置類型。修正可能只推動了分數、卻沒解決你在意的問題；而行動版與桌機版會產生各自的實驗室結果。
想加快迭代，就別等 PSI，直接在本機執行 Lighthouse。這個類別自 Lighthouse 13.3 起納入，安裝本機版即可使用。若你想用 DevTools 面板版本，Google 的文件指出測試這個類別需要 Chrome 150 以上，而 WebMCP 稽核還需要註冊 origin trial。
留下一份簡短的修正前後紀錄。像「2026-09-11：行動版 1/3，無障礙樹與 llms.txt 失敗」這樣一行帶日期的筆記就夠了。它能讓你知道後來的退步是真的，還是只是單次執行的波動。
這項檢查不是什麼
有三件事它不做，因為誤解相當普遍：
- 它不是排名因素。 Chrome 的公告稱這個類別為資訊性質、未納入基準評分。Google 搜尋排名不受你的 Agentic Browsing 分數影響。
- 它不是 AI 能見度分數。 它衡量代理能否操作你的頁面，完全不說明 ChatGPT 或 Perplexity 是否會在回答中引用你。
- 它不是網站的及格／不及格判定。 簡單的行銷頁面分數偏低，通常只是沒什麼可評，而不是代理被擋在門外。
有幫助的視角是這樣：這個類別檢查的是當訪客不是人類時，你的網站站不站得住。它獎勵的每一件事本來就值得做：語意化 HTML、穩定的版面、有標籤的控制項。Google 自家的代理友善指引也用同一個結論收尾——讓網站對代理就緒的事，同時也讓人類用得更好。
納入例行檢視
代理就緒度這類領域，平台的移動速度比檢查清單快。兩個習慣就能讓你保持現況，而不必把它變成一個專案：
- 任何範本、導覽、表單或結帳流程變更之後，就重跑這項檢查。這些正是會移動無障礙樹與版面穩定性的編輯。
- 追蹤分數時以範本為單位，而非以網址為單位。十個產品頁分數都一樣，那就是範本問題，修一次就能全部解決。
PSI 的檢查刻意狹窄：六項稽核，一次一頁。如果你想要更完整的圖像，包括 robots 規則、MCP 伺服器卡片、OAuth 探索與代理商務訊號是否到位，Auspia 提供免費的 Agent Readiness 檢查，會依這些協定層級標準掃描網址，並提供排行榜供比較。
常見問題
Agentic Browsing 分數會影響 Google 排名嗎？不會。Google 將這個類別描述為資訊性質，不屬於搜尋排名系統。請把它當成給代理用的就緒度檢查，而不是 SEO 分數。
為什麼同一頁面兩次執行的分數不同？動態工具註冊、改變無障礙樹的 DOM 變動，以及晚發生的版面位移，都會造成執行間的變異。請重新測試，並比較稽核清單，而不是只看分數。
為什麼三項 WebMCP 稽核全都顯示不適用？因為你的頁面沒有註冊 WebMCP 工具。這是 2026 年多數網站的預期狀態，並不是失敗。
缺少 llms.txt 是問題嗎？就這項稽核而言不是。404 會被視為不適用。但存在的檔案若格式錯誤就會失敗，所以要發布就正確地發布。
可以在 CI 裡執行嗎？可以，只要你的 Lighthouse 版本已包含這個類別。這些稽核在設計上是確定性的，因此適合放進流水線檢查。請留意 WebMCP 部分取決於瀏覽器支援與 origin trial 註冊，在多數 CI 環境中預期會顯示為不適用。
我需要 Chrome 150 才能用嗎？不需要。PageSpeed Insights 是在伺服器端執行。Chrome 150 的要求適用於在 DevTools 本機執行這個類別。
作者：Alice Monroe，Auspia 的 AI SEO 工具分析師，研究超過 150 款工具。她撰寫 SEO 與 AI 搜尋工具、哪些檢查值得投入時間，以及如何把它們納入日常工作。
