重點摘要
- WebMCP (Web Model Context Protocol) 是一項由 Google 和 Microsoft 共同提出的新興網站標準，旨在讓 AI 代理人 (AI agents) 能以結構化、更有效率的方式與網站進行互動並執行任務。
- 與目前 AI 代理人透過分析視覺排版 (DOM) 來「猜測」操作方式不同，WebMCP 允許網站直接提供明確的「工具」(Tools)，如「搜尋商品」或「預約訂位」，大幅降低錯誤率並提升執行速度。
- 對 SEO 專家而言，WebMCP 是結構化數據 (Schema.org) 的自然延伸，從標記「內容是什麼」進化到定義「頁面能做什麼」，戰場從內容的可檢索性 (discoverability) 擴展到功能的可執行性 (executability)。
- WebMCP 主要處理前端頁面上的使用者行為，而傳統的 MCP 則專注於後端數據系統的串接。兩者並非競爭關係，而是互補的技術，共同構成未來 AI 代理人與網路互動的基礎設施。
過去二十年，SEO 的核心是圍繞著「如何讓機器更好地理解人類的內容」而演進。從單純的關鍵字匹配，到語意分析與結構化數據，我們的目標始終是降低搜尋引擎理解網頁內容的成本，以換取更好的曝光。然而，當使用者代理 (user agent) 從搜尋爬蟲 (crawler) 逐漸轉變為能代為執行任務的 AI 代理人 (AI agent) 時，遊戲規則也隨之改變。我們面臨一個新的課題：如何讓機器不僅能「讀懂」你的網站，更能精準無誤地「操作」你的網站？WebMCP 正是這個新賽局的技術入場券，它將重新定義網站的轉換路徑與 SEO 的價值邊界。
AI 代理人的「盲人摸象」困境, 為何網站需要新的溝通語言？
試想一個場景, 你請 AI 助理幫你預訂一間評價不錯的餐廳。目前，這個 AI 助理的作法極為原始, 它會像個新手使用者一樣，載入餐廳網頁，試圖從畫面截圖和 DOM 結構中辨識出哪個是「日期選擇器」、哪個是「人數欄位」，哪個又是「送出按鈕」。這個過程充滿了不確定性, 只要網站的版面設計稍有不同，或是前端程式碼不夠標準化，AI 就可能判讀失敗。這就像讓一個看不懂文字的人，單憑排版猜測表單的填寫方式，不僅效率低落，錯誤率更是難以控制。
這種「逆向工程」式的互動模式，是當前 AI 代理人與網路世界互動的最大瓶頸。它消耗大量的運算資源，且極度不穩定。WebMCP 的出現，正是為了解決這個根本性的溝通障礙。它提供了一套標準化的「說明書」，讓網站可以透過簡單的 HTML 屬性或 JavaScript，直接告訴 AI 代理人,「這是一個預約工具，它需要姓名、電話、日期這些參數」。AI 不再需要猜測，而是可以直接呼叫這個被明確定義的工具，並傳入所需參數。這不僅是效率的躍升，更是從機率性的猜測走向確定性的執行，為未來更複雜的自動化任務奠定了基礎。
WebMCP vs. MCP, 釐清前端行動與後端數據的楚河漢界
在討論 WebMCP 時，許多人會將其與另一個縮寫「MCP」(Model Context Protocol) 混淆，認為是相互競爭的標準。從技術架構來看，這種理解存在偏差。兩者解決的是不同層面的問題，更像是分工合作的夥伴關係。我們可以從它們的應用場景來劃分界線：
- WebMCP, 專注於前端頁面的「可操作性」, 它的目標是將網站現有的互動元素 (如搜尋框、表單、按鈕) 封裝成 AI 可直接呼叫的工具。整個過程發生在瀏覽器前端，無需改動後端伺服器。例如，電商網站的「加入購物車」、SaaS 服務的「註冊帳號」、餐廳的「線上訂位」，這些都是 WebMCP 的理想應用場景。
- 傳統 MCP, 專注於後端數據與系統的「可存取性」, 它更像是一個傳統意義上的 API。當 AI 代理人需要的是你系統內部的「數據」(如 Moz 的 SEO 數據、Salesforce 的客戶資料、公司的內部資料庫)，而不是在網頁上完成一個「動作」時，MCP 就派上用場。建置 MCP 需要開發並維護一個後端伺服器端點，工程較為浩大。
一個大型企業很可能會同時使用兩者。例如，航空公司網站的訂票頁面，可以使用 WebMCP 將「查詢航班」的表單定義成工具，供 AI 代理人填寫；而當 AI 需要查詢該使用者的會員哩程數時，則會透過後端的 MCP 接口去存取會員資料庫。WebMCP 處理網頁上的行動，MCP 處理後台的數據，兩者各司其職。
從「可檢索」到「可執行」, SEO 戰場的維度擴張
對 SEO 從業人員來說，WebMCP 的概念其實並不陌生。我們可以將它視為 Schema.org 結構化數據的下一個演化階段。過去，我們用 Schema 標記來告訴 Google,「這是一篇食譜，烹飪時間 30 分鐘」、「這是一個產品，售價 500 元」。我們在標記「實體」(Entity) 的屬性，讓搜尋結果能以更豐富的形式呈現 (Rich Snippets)，提升點擊率。這一切都還停留在「內容發現」與「點擊前優化」的範疇。
WebMCP 則將這個概念從「內容」延伸到了「功能」。我們不再只是告訴機器「這是什麼」，而是進一步定義「它能做什麼」。這意味著 SEO 的工作範疇，將從確保網站「可被找到」(findable) 與「可被理解」(understandable)，擴展到確保網站的關鍵功能「可被執行」(executable)。在台灣市場，這點尤為重要。不論是 momo、PChome 這類電商平台的複雜篩選與結帳流程，還是 KKday、Klook 等旅遊體驗的預訂系統，其轉換路徑都相當多層。若未來使用者習慣透過 AI 助理直接下單，哪個網站能提供最流暢、最無錯的「代理人執行體驗」，就等於掌握了新的轉換入口。優化 WebMCP，就是優化這個新興的、由 AI 主導的轉換率。
部署 WebMCP 的第一哩路, 從 HTML 屬性開始的低成本優化
談到新技術，許多行銷人員或企業主的第一反應是「導入成本會不會很高？」幸運的是，WebMCP 的入門門檻極低，特別是其基於 HTML 的宣告式 API (Declarative API)。這完全符合我們 SEO 專家所追求的「低投入、高效益」的優化原則。企業不需要為了 AI 代理人重新開發一套系統，而是在現有網頁上進行「標記增強」。
具體操作上，我們可以採取數據導向的分階段導入策略。首先，透過分析工具 (如 Google Analytics) 找出網站上最重要的轉換節點。對於一個 SaaS 網站，可能是註冊表單；對於內容網站，可能是電子報訂閱表單；對於 B2B 企業，則是聯絡我們或詢價表單。接著，請前端工程師針對這個最重要的表單，加上 `toolname`、`tooldescription` 等幾個簡單的 HTML 屬性。這項工作的開發成本極低，甚至可能比調整一次 CSS 樣式還快。完成後，便可利用 Chrome 擴充功能「Model Context Tool Inspector」進行測試，確保 AI 代理人能正確識別並與該工具互動。
這不僅僅是為了迎接一個尚在萌芽的流量渠道，更是對網站技術體質的一次檢視。一個能輕易部署 WebMCP 的網站，通常也意味著它擁有清晰的 DOM 結構和標準化的表單設計。這本身就是技術 SEO 的最佳實踐。從單一關鍵表單開始，逐步擴展到站內搜尋、商品篩選等其他核心功能，這是一條清晰、可衡量且符合敏捷開發精神的優化路徑。
延伸閱讀：What Is WebMCP? How to Prepare Your Website to Serve AI Agents