有網頁，不等於 AI 讀得懂
過去我們談 SEO，重點是讓搜尋引擎「找到」你的頁面；現在多了一個新對象——生成式 AI。消費者不再只是打關鍵字，而是直接問 AI：「幫我找一雙適合寬楦、預算兩千以內的慢跑鞋。」AI 要回答這個問題，得先能正確讀到你的商品名稱、價格、規格、庫存。問題是，一個對人類漂亮好看的網頁，對機器來說常常是一團看不懂的視覺排版。
人眼看到的是「NT$1,680 現貨供應」，機器看到的可能是一串被 CSS 拆散、混在導覽列與廣告之間的文字節點。它不確定這個數字是售價、原價還是運費；不確定「現貨」是這一款還是旁邊那一款。當 AI 沒把握，它要嘛猜錯，要嘛乾脆略過你、改用一個資料更清楚的競品。這就是「供給端」的核心命題：不是你有沒有內容，而是你有沒有把內容用機器可讀的方式「餵」出去。
這篇文章不談怎麼寫給 AI 看的行銷文案，而是談更底層的事——把你的商品、庫存、價格、知識，整理成 AI 生態能穩定取用的資料格式。我們把這種「品牌供資料給 AI、AI 再服務消費者」的模式，稱為 B2AI2C（Business to AI to Consumer）。以下用白話拆解三個層次，並給一張對照表與導入順序。
機器可讀資料的三個層次
把資料餵給 AI，不是一件事，而是一組由淺到深的層次。你不需要一次做完，但要知道自己在哪一層、下一步往哪走。
第一層：結構化資料（Schema.org）——讓單一頁面自己會說話
Schema.org 是一套全球通用的「資料標籤語言」。你在商品頁的 HTML 裡，額外埋一段機器看得懂的標記（通常用 JSON-LD 格式寫在頁面裡，人眼看不到，但爬蟲和 AI 讀得到），明白告訴機器：這是商品名稱、這是品牌、這是售價、這是幣別、這是庫存狀態、這是評價星數。
白話講，就是幫網頁的每個重要資訊「貼標籤」。原本機器要用猜的，現在你直接說清楚。對電商最關鍵的是 Product 這個型別，底下再掛 Offer（價格、幣別、供貨狀態）與 AggregateRating（評分）。這一層的好處是門檻最低、效益最直接：不用開發後端 API，只要在頁面模板加一段標記，Google 的商品結果、以及讀取網頁的 AI 都能更準確地引用你。
誰適合先做：所有電商都該做，這是地基。用開店平台（如 Shopify、Cyberbiz、91APP 等）的商家，很多主題已內建，只要確認欄位有填滿即可。
第二層：商品 Feed／資料層——讓整批商品一次交出去
Schema 是「一頁一頁貼標籤」，商品 Feed 則是「把整個商品目錄打包成一份清單交出去」。Feed 通常是一個 CSV、TSV 或 XML 檔，一列一個商品，每一欄是一個欄位（商品編號、標題、描述、價格、庫存、圖片網址、規格）。Google Merchant Center 的商品 Feed 就是最典型的例子，Meta、各大比價與導購平台也吃這套。
Feed 的價值在於「大量、一致、可定時更新」。你有五千個商品，不可能靠 AI 一頁一頁爬；但一份每天自動更新的 Feed，能讓外部系統一次拿到全部、而且知道哪些改了價、哪些缺貨。對想被 AI 購物助理、比價引擎收進去的品牌，Feed 是必經之路。
誰適合做：品項多、常變價變庫存的電商。開始的方式很簡單——先做出一份符合 Google Merchant 規格的商品 Feed，因為它的欄位定義（Google product data specification）幾乎是業界公版，做好這一份，往別的平台複製只是換格式。
第三層：開放 API 或 MCP——讓 AI 主動來查你的即時資料
前兩層是「你把資料推出去」，第三層是「讓 AI 主動來拉」。API（應用程式介面）就是你開一個查詢窗口，讓外部程式能問「這個商品現在多少錢、還有沒有貨」，你即時回一個機器格式的答案。這適合資料變動快、需要即時的場景，例如限時特價、動態庫存。
MCP（Model Context Protocol）則是近兩年出現、專門為 AI 設計的一種標準連接方式。你可以把它想成「專門開給 AI 用的資料插座」：過去每接一個 AI 工具都要客製，MCP 讓你用同一套標準，把你的商品查詢、庫存查詢、訂單狀態，包成 AI 助理能直接呼叫的「工具」。當消費者在支援 MCP 的 AI 裡問到你的商品，AI 不必猜、不必爬舊網頁，而是直接透過 MCP 向你的系統問到當下最新的答案。
誰適合做：有技術資源、且把「被 AI 直接取用」當成策略優先的品牌。中小電商不必一開始就做 MCP，但要知道它的方向——當 AI 從「讀網頁」進化到「呼叫工具查資料」，有 MCP 的品牌就能提供最即時、最不會出錯的答案。
餵 AI 的資料供給層對照表
| 層次 | 白話定義 | 常見格式 | 更新即時性 | 技術門檻 | 適合對象 |
|---|---|---|---|---|---|
| 結構化資料 Schema | 幫單頁資訊貼機器標籤 | JSON-LD（Product／Offer） | 跟頁面同步 | 低 | 所有電商（地基） |
| 商品 Feed／資料層 | 整批目錄打包成清單 | CSV／TSV／XML | 定時（每日或每小時） | 中 | 品項多、常變價變庫存 |
| 開放 API | 開查詢窗口讓外部即時問 | REST／JSON | 即時 | 中高 | 限時特價、動態庫存 |
| MCP | 開給 AI 用的標準資料插座 | MCP Server（工具化） | 即時 | 高 | 把被 AI 取用當策略優先者 |
商品資料的欄位一致性：餵得多不如餵得準
不管你走到哪一層，資料本身的品質決定成敗。AI 最怕的不是資料少，而是資料互相打架——網頁寫 1,680，Feed 寫 1,880，API 回 1,780。消費者被 AI 報了一個錯價，責任會回到你身上。以下是每個商品都該對齊的核心欄位。
- 價格：售價、原價、幣別要分清楚，特價要標明起訖，避免 AI 把過期特價當現價。
- 庫存／供貨狀態：現貨、預購、缺貨、停售要有明確狀態值，不要只靠一句文案。
- 規格：尺寸、顏色、材質、容量等變體要結構化，每個變體有自己的價格與庫存。
- 唯一識別碼：商品編號（SKU）、國際條碼（GTIN／EAN）能讓 AI 跨平台認出「這是同一個商品」。
- 圖片與描述：主圖網址穩定可存取，描述講清楚用途與適用情境，別塞滿關鍵字。
跨通路 Feed 一致性
很多品牌同時上官網、蝦皮、momo、Google 購物，每個通路一份 Feed。如果這幾份不同步，AI 從不同來源讀到不同價格與庫存，就會對你的品牌失去信任。務實做法是設一個「單一真實來源」（single source of truth）——通常是你自家的商品資料庫或 PIM（商品資訊管理）系統，所有通路的 Feed 都從這裡自動產生，而不是各通路各自手動維護。改一次、全通路同步，才不會越舖越亂。
把 FAQ 與知識做成 AI 可取用的資產
AI 回答消費者時，除了商品規格，還常引用「這台除濕機適合幾坪」「這件外套能不能水洗」這類知識。這些答案往往藏在你的客服對話、商品問答、部落格裡，是散的、非結構化的。把它們整理成結構化的 FAQ，是低成本高回報的一步。
做法：在商品頁或知識頁使用 FAQPage 這個 Schema 型別，把常見問題與答案成對標記起來；同時維護一份內部的問答資料表，未來要接 API 或 MCP 時，這份表就是 AI 能直接查詢的知識庫。重點是答案要準、要更新，一個過期的退換貨政策被 AI 引用出去，比沒答案更傷。
風險與資料治理：別把錯的、過期的餵出去
把資料開放給 AI 取用，等於把你的資料品質「公開曝曬」。過去頁面寫錯，可能沒人發現；現在 AI 會把它當事實講給每個問到的人。所以供給策略一定要配上治理機制。
- 單一真實來源：所有對外資料從同一個源頭產生，杜絕多份手抄版本互相矛盾。
- 時效控管：特價、庫存、政策要有到期與更新機制，過期資料自動下架或標記，別讓它繼續被讀。
- 錯誤可回溯：Feed 與 API 要有版本與紀錄，出錯時查得到是哪次更新、哪個欄位錯。
- 敏感資料界線：成本、進貨價、內部備註絕不能混進對外 Feed，開 API／MCP 時明確界定哪些欄位可查、哪些不可。
- 存取控管：對外 API 與 MCP 要有流量與權限控制，避免被濫用爬走全站資料。
循序漸進的導入順序
台灣中小電商資源有限，不必也不該一次做四層。建議這樣排：
- 第一步（本週就能做）：檢查商品頁的 Schema，確認 Product／Offer 欄位填滿、價格與庫存正確。這是地基，效益立即。
- 第二步（一個月內）：整理出一份符合 Google Merchant 規格的商品 Feed，並讓它自動每日更新。同時建立「單一真實來源」的觀念，別再各通路手動維護。
- 第三步（一季內）：把 FAQ 與商品知識結構化，做成 FAQPage 與內部問答表，補齊 AI 回答時需要的情境知識。
- 第四步（有餘力時）：對變動快的資料（即時庫存、動態價）開放查詢 API；若把「被 AI 直接取用」當戰略，再進一步評估建置 MCP Server，讓 AI 能主動查你的即時資料。
總結一句：SEO 時代比的是誰的網頁被找到，B2AI2C 時代比的是誰的資料被 AI 讀得懂、信得過。從貼好每一個 Schema 標籤開始，把價格、庫存、規格對齊，建立單一真實來源，你就已經走在多數同業前面。當 AI 成為消費者的第一個問句，你的商品資料，就是你留在答案裡的門票。