建議：先補強 SEO 與 GEO，再判斷 WebMCP 是否真的能解決任務
WebMCP 與 SEO、GEO 有交集，但不是同一件事。把這些概念混在一起，很容易出現兩種誤判：以為加入 agent API 就能獲得 AI 搜尋曝光；或以為 LLM 能閱讀內容，就代表 agent 能安全完成預約、設定或送出表單。
實務上的劃分很清楚。SEO 讓頁面被找到；GEO 讓 AI 系統能理解、引用並正確描述資訊；Agent Readiness 讓已獲授權的 agent 能完成站內有邊界的任務；WebMCP 則是最後一層可採用的瀏覽器原生工具機制之一。
如果站點內容薄弱、產品事實不完整或可抓取性有問題，WebMCP 很少是下一筆最值得的投資。只有在成熟站點存在篩選、設定、長表單、支援受理或預約等反覆且高價值的任務時，才值得納入試點。
可發現、答案適格性、任務完成與可呼叫能力是一條連續路徑，但每一層都需要不同的證據。
用一張表釐清邊界
| 層級 | 主要對象 | 解決的問題 | 典型工作 | 不保證的事 |
|---|---|---|---|---|
| SEO | 搜尋引擎與搜尋者 | 頁面能否被抓取、索引並匹配查詢 | 資訊架構、渲染、標題、內鏈、結構化資料 | agent 自動完成交易 |
| GEO | AI 答案系統與讀者 | 資訊能否被正確理解、再利用、引用或推薦 | 直接答案、證據、實體清晰度、可擷取段落 | 在所有地方直接提高排名 |
| Agent Readiness | 已授權 agent 與使用者 | agent 能否安全地導覽、篩選並完成任務 | 穩定狀態、錯誤、權限、確認 | 繞過使用者控制 |
| WebMCP | 瀏覽器中的網站與 agent | 如何將特定頁面功能公開為結構化工具 | 工具 schema、參數、origin 邊界、輸出限制 | 通用 AI 搜尋爬蟲協定 |
WebMCP 是什麼，不是什麼
依據 Google Chrome 的 WebMCP 文件 ，WebMCP 是一項提議中的 Web 標準，可將 JavaScript 函式或 HTML 表單，以帶有自然語言描述與結構化 schema 的工具形式公開。imperative API 用於 JavaScript 功能，declarative API 用於標註標準 HTML 表單。
它的價值在於減少 agent 對 DOM 的猜測。旅行網站可以公開航班搜尋與篩選；SaaS 可以公開建立支援單草稿；電商可以公開已授權的商品設定或公開庫存查詢。
它不是新的 sitemap，不保證 ChatGPT、Google AI Overviews 或 Perplexity 一定會引用頁面，也不是後端 MCP server 的替代品，更不能繞過身分驗證、付款驗證或伺服器端授權。
截至本文撰寫時，WebMCP 仍處於 Chrome early preview 與 origin trial 階段。應把它視為值得測試的介面方向，而不是已成熟的獲客管道。
為什麼 WebMCP 會出現在 GEO 的討論中
兩者都在回應同一個行為改變：使用者未必親自讀完每頁、按完每個按鈕。AI 可能先比較、摘要、篩選，並在使用者同意後執行操作。
GEO 的核心仍是成為可信的答案來源。產品頁應說明產品是什麼、適合誰、價格或限制、證據在哪裡，以及和替代方案有何實質差異。即使完全不採用 WebMCP，這些改善仍有價值。
WebMCP 的核心是把既有且受權限保護的操作交給 agent。若產品描述、價格、庫存與退貨條款本來就混亂，加入更多工具只會讓 agent 更快傳播混亂。
什麼情況該把 WebMCP 放進路線圖
| 現況 | 第一優先 | 現在考慮 WebMCP 嗎 |
|---|---|---|
| 核心頁面無法穩定抓取，產品事實零散 | 技術 SEO、內容與實體整理 | 否 |
| 頁面能運作，但 AI 回答常誤解品牌或漏掉限制 | GEO、證據與內容結構 | 暫緩 |
| 使用者在複雜篩選、設定或長表單中流失 | UX 與事件分析 | 尋找唯讀試點 |
| 具備明確權限模型、可稽核伺服器 API 與可撤銷操作 | Agent Readiness 與安全設計 | 建立受控原型 |
| 想讓 agent 直接購買、刪除或修改敏感資料 | 風險審查與確認 UX | 不作為第一批能力 |
從任務開始，而不是從協定開始
不要先問「我們是否該支援 WebMCP？」。應問「使用者正委託 agent 完成哪一項重複工作？」
好的候選任務通常有明確目標、少量可驗證輸入、可預覽的結果與安全退出方式。「依預算與尺寸篩選公開商品」比「替使用者完成購買」更適合作為第一步。
接著檢查：既有使用者流程是否可靠？哪些欄位必要？輸出是否包含評論、第三方文字或敏感資料？任務能否先回傳唯讀結果或草稿？使用者必須在哪一步確認，又該看到什麼？
不要把安全問題留到實作完成後才問。請參考 WebMCP 安全檢查清單：在網站 Agent Ready 前先做到 Agent Safe ，其中整理了可信任 origin、不可信 UGC、讀寫邊界與確認的發布檢查項。
SaaS 範例：支援單草稿比自動支援更適合起步
假設客戶請 agent 把過去三天的錯誤整理成支援請求。
較差的設計會讓 agent 讀取每個專案、推測問題並直接送出支援單。它可能越權讀取、把日誌文字當成指令，或選到錯誤的處理佇列。
較好的設計是：只公開使用者原本已可查看的錯誤摘要；讓 agent 用唯讀工具依時間範圍與專案篩選；建立草稿而不是送出；向使用者顯示標題、描述、附件與送達對象；並保留伺服器端身分、專案權限與欄位驗證。
SEO 讓文件被找到；GEO 讓 agent 與客戶理解定義、限制與處理方式；WebMCP 只讓這個既有任務流程更少依賴頁面猜測。
衡量 Agent Readiness，不要幻想「WebMCP 排名」
| 指標 | 要問的問題 |
|---|---|
| 任務成功率 | agent 能否以少量重試完成已授權目標？ |
| 人工接管率 | 使用者最常在哪一段修正或接手？ |
| 安全中止率 | 工具能否正確拒絕未知、未授權或危險輸入？ |
| 確認後完成率 | 使用者看見影響後仍願意核准操作嗎？ |
| 內容與答案品質 | 相關頁面是否仍被理解、引用並帶來合格訪問？ |
這些指標應與 SEO、GEO 報表並列，而不是取代它們。
把 WebMCP 放在正確位置
WebMCP 值得持續追蹤，因為它為瀏覽器 agent 提供比 raw DOM 自動化更明確的操作介面。對成長團隊來說，順序比新協定名稱更重要：先讓頁面可發現、可理解、值得信任；再把有價值的任務設計成安全且可驗證的流程；最後才決定 WebMCP 是否適合實作。
若要進行實務網站審計，請繼續閱讀 SEO、GEO 與 Agent Readiness 的四層網站審計 。它把證據、風險與 30 天優先順序拆開，避免團隊把整筆預算花在實驗性協定上。
FAQ
WebMCP 與 Model Context Protocol 相同嗎？
不同。兩者共享工具與 schema 等詞彙，但 WebMCP 著重目前瀏覽器頁面的前端功能與 DOM 互動；MCP 通常連接後端服務、資料來源或本地工具。兩者可以互補。
做 GEO 必須採用 WebMCP 嗎？
不必。大多數 GEO 工作是內容品質、實體事實、證據、頁面結構與技術可存取性。只有使用者確實需要 agent 完成複雜站內任務時，才需要考慮 WebMCP。
WebMCP 只適合電商嗎？
不是。客戶支援、旅行搜尋、SaaS 設定、預約與資料篩選都可能適用。共同點不是產業，而是存在明確、可限制、可確認的任務。
資料來源
作者：Maya Ellison，Auspia 擁有 12 年經驗的 GEO 策略研究員。Maya 專注於 AI 搜尋可見性、品牌實體清晰度，以及成長團隊可執行的 GEO 營運系統。
