AI agent 開始操作網站那天，你的網站準備好了嗎？

去年某次工程師聚會，有人示範了一個瀏覽器外掛：對著頁面說一句「幫我預約下週三下午三點的瑜珈課」，AI 自動填表、按送出、跳轉到確認頁。在場十幾個前端工程師，沒有人接話。那種安靜，就是這篇文章想談的事。

傳統 SEO 做到頂，AI 還是不認識你的網站

過去一年，你可能已經做過這些事：關鍵字佈局、Core Web Vitals 調整、內容改寫、外部連結經營。這些依然重要，但場上多了一個新維度。

Google 在 2024 年公開的數據顯示，AI Overviews 觸及的月活躍用戶已突破 20 億。越來越多人開始問 AI，而不是問搜尋引擎。這代表你的網站不只要被 Google 找到，還要被 AI agent 理解、調用、執行。

問題出在哪裡？大多數網站，AI agent 根本無從下手。

什麼是 WebMCP？

WebMCP 全名是 Web Model Context Protocol，由 Google Chrome 與 Microsoft Edge 兩組團隊共同推進，目標是成為 W3C 標準。概念不算複雜：

讓網站把功能「暴露」給 AI agent 呼叫。

沒有 WebMCP 的世界是這樣：AI 爬到你的頁面，猜哪個欄位該填城市、哪個欄位該填日期，然後祈禱表單會接受。有 WebMCP 的世界是另一回事：你的網站主動告訴 AI「我有 searchFlights 函數，需要起點、目的地、日期三個參數，回傳 JSON 格式的航班列表」。

用白話講，就是你的網站從啞巴變成會自我介紹的人：「我在這裡，我能做這些事。」

這個標準會打到誰？

電商、預約系統、表單多的網站，影響最深。

想像一個情境：使用者跟 AI 說「幫我找一家在台中做網頁設計的公司，能做品牌形象官網、預算抓二十萬以內」。AI agent 不會只讀你的關於我頁，它會直接呼叫你的「服務項目」函數、「報價試算」函數，把結果整理給使用者。

你的網站會從「資訊來源」升級成「AI 會用的工具」。差別很大。

對網站設計業的意義

鍛碼匠每天在做的事，本質上是幫業主建立「在網路上的存在感」。過去這份存在感指的是被搜尋到、被點開；下一階段，它還要能被 AI 執行。

我們在台中的工作室，常常被問到一個問題：「做完網站之後 SEO 要怎麼做？」現在這個問題後面，可能要再加一句：「做完之後，AI agent 能不能用我的網站？」

這不是科幻場景。WebMCP 的瀏覽器支援預計 2026 年中到年底擴大。現在就把網站設計成 AI-ready，會是接下來幾年的差異化關鍵。

現在可以開始的三件事

結構化資料升級

JSON-LD 本來是寫給 Google 看的。下一步要把它升級成「寫給 AI agent 看的」：標記函式、標記動作、標記可完成的任務。想兼顧人類與 AI 讀法，可參考如何在 AI 時代撰寫兼顧人類與演算法需求的網站內容。想兼顧人類與 AI 讀法，可參考如何在 AI 時代撰寫兼顧人類與演算法需求的網站內容。想兼顧人類與 AI 讀法，可參考如何在 AI 時代撰寫兼顧人類與演算法需求的網站內容。

內容顆粒化

不要再只寫「我們提供網頁設計服務」。要寫「這項服務的輸入是產業別、頁數、是否需要後台，輸出是上線時程與維護建議」。讓 AI 看得出你的內容在做什麼、能做什麼。

技術基礎先打底

如果連 Googlebot 都爬不順，AI agent 更不可能正確解析。Core Web Vitals、結構化資料、robots.txt、站內導覽，先把這些處理好。

AI 搜尋的規則正在重寫

Google 說 AI Overviews 是搜尋的未來。Microsoft 說 AI Mode 要重新定義找資料的方式。兩邊聯手把 WebMCP 推進成開放標準。

身為網站設計從業者，我們的選項不是焦慮，也不是觀望。實際能做的，是理解這個趨勢、找到具體的著手點、把手上正在進行的專案往前推一步。

網站過去是給人閱讀的。未來，它還得能跟 AI 對話。

實作步驟：把 WebMCP 整合進網站設計

整合 WebMCP 不是一次性的工程，而是設計流程的轉變。五個步驟是我們目前在內部 SOP 裡跑的順序：

盤點現有網站

先全面檢視網站的結構、程式碼品質、現有 SEO 狀態。哪些頁面已經有結構化資料？哪些表單還停留在純 HTML？哪些 API 其實早就存在，只是沒被「宣告」？

拆解內容架構

針對每個頁面思考：這頁能被 AI 呼叫的動作是什麼？例如「聯絡我們」能不能變成 submitInquiry 函式？「產品列表」能不能變成 listProducts 函式？重新設計資訊架構，讓每個頁面都帶有可被呼叫的語意。

補上結構化資料標記

用 Schema.org 與 JSON-LD 標記產品、服務、文章、FAQ。但這次多一層：在頁面加入 WebMCP 描述檔，告訴 AI agent「這裡有什麼函式、輸入什麼、回傳什麼」。

上線後持續觀察

部署不是結束。用 Search Console、伺服器 log、AI 爬蟲記錄（如果有）追蹤：哪些函式被呼叫？哪些頁面被 AI 讀走？回傳結果有沒有錯？根據數據回頭調整。

把流程內建進接案 SOP

下一次報價、寫企劃、開 kick-off，就把 WebMCP 相關項目列進去。讓 AI-ready 成為標配，而不是加購。

常見錯誤：WebMCP 整合的幾個坑

整合過程中容易踩的坑，大致歸成四類：

只顧視覺，內容可讀性崩盤

有些設計師把精力全放在版面上，內文卻塞滿艱澀術語或破碎句子。AI 解析的時候會抓不到重點。寫法上盡量口語化、段落短一點、重點一句話講完。

資料標記做半套

不少人以為有裝一個 Schema.org 外掛就交差了。實際上 Organization、Product、FAQ、Service、Action 各自有不同用途，沒全做完等於沒做。建議直接看 Schema.org 官方文件對照欄位。

上線後就不管

最常見的狀況。網站上線三個月沒人看 log，AI 爬取狀況、錯誤回傳、404 全部沒在追。AI agent 跟你網站互動的過程不像人類會跳出錯誤訊息，它會直接把你列為「不可用」然後繞路。

忽略裝置相容性

WebMCP 標準雖然在瀏覽器層運作，但實際呼叫往往發生在桌機、平板、手機各種類比環境。響應式設計沒做好，等於讓一半的使用情境失效。

案例觀察：市場上開始出現的 AI-ready 網站

鍛碼匠本身還沒做過完整的 WebMCP 客戶專案（這個標準太新，2025 年還在草案階段），但同業之間已經開始流傳一些早期觀察。

一家做線上訂房的業者，2024 年底把訂房流程拆成 RESTful API，並在頁面加上結構化描述。半年內他們回報，從 AI 搜尋導入的訂單雖然量還不大，但轉換率比自然搜尋高出許多，因為 AI agent 已經幫使用者篩選過條件了。

一家做 B2B 零件目錄的網站，把產品搜尋包成可呼叫的函式，並在 Schema 裡宣告輸入欄位。他們發現，AI agent 在回答「找 XX 規格的軸承」時，會直接呼叫並列出他們的產品，而不是連到一篇部落格文章。

這兩個案例都不是 WebMCP 的完整實作，更像是「AI-callable 思維」的早期試驗。但方向很清楚：能被呼叫的網站，正在獲得新的流量入口。

架構與 SEO 技術層的細節｜SEO 完整策略
五種方案的成本結構與報價差異｜網頁設計完整決策指南
互動與動效的技術細節｜形象網站設計原則
台中 SEO 公司怎麼挑
台中 SEO 價格、流程與挑選要點