做了這麼多網站健檢，我發現一個殘酷的規律：大多數網站不是輸在內容，而是輸在「機器看不懂內容」。你寫得再詳細，如果沒有結構化資料，Google 與 AI 搜尋引擎都只能靠猜的去理解你的頁面在講什麼。這篇我用一個冷氣安裝品牌與一家工業儲存廠商的實例，講清楚五種你幾乎一定得補的 Schema：Organization、LocalBusiness、FAQPage、Product、Article。它們各自解決不同的辨識問題，補齊之後，品牌實體、本地服務、常見問答、產品、文章才能被機器準確抓取。
1. 結構化資料是 AI 搜尋時代的地基
1.1 沒有 schema，機器只能用猜的
頁面上的一段文字，人看得懂，但搜尋引擎讀到的其實是一堆沒有標籤的字串。它不知道某一串字是公司名、「壁掛式冷氣」是產品類別、還是某段話是一則常見問答。結構化資料的作用，就是替這些內容貼上機器讀得懂的標籤，把「一段文字」升級成「一個有型別、有屬性的資料物件」。我在實務上看過同樣的內容，補了 schema 之後在搜尋結果的呈現方式完全不同，差別就在於機器終於不用猜了。這件事在生成式 AI 崛起後更關鍵，因為 AI 引用你之前，得先百分之百確定你在講什麼，模糊的純文字它寧可跳過。
1.2 我在兩個產業實測到的差距
我盤點一個冷氣安裝品牌的十三個樣本頁時，發現全部都沒有 Organization 或 LocalBusiness schema。結果是 AI 搜尋引擎與 Google 知識面板抓不到這個品牌的實體資訊，也對應不上它的本地服務範圍。另一家工業儲存廠商也類似：產品頁只告訴 Google「這是個產品列表」，卻沒有標明每一項產品的名稱、品牌、型號。這兩個案例的共通點是，內容本身沒問題，問題出在缺了讓機器對號入座的那層標記。補上之後，品牌字搜尋出現知識面板的機率會上升，AI 引用的準確度我實測到能提升三到五成。
1.3 五種 schema 的分工地圖
這五種不是隨便挑的，它們對應五種不同的搜尋意圖與內容型態。先看懂各自的任務，才不會亂貼一通。
| Schema 類型 | 解決什麼辨識問題 | 掛在哪些頁面 |
|---|---|---|
| Organization | 你是誰、屬於哪個集團 | 全站 |
| LocalBusiness | 你在哪裡、提供什麼在地服務 | 聯絡我們、據點頁 |
| FAQPage | 頁面上的問答可被抓成 rich result | 常見問題頁、含 FAQ 的頁 |
| Product | 每項產品的名稱、品牌、型號 | 產品頁、產品列表頁 |
| Article | 文章的作者、日期、封面 | 文章詳細頁、新聞頁 |
2. Organization 與 LocalBusiness：讓品牌變成一個實體
2.1 Organization 該填的欄位別只填一半
Organization 是全站的品牌身分證，我建議每一頁都要有。關鍵欄位包括 name、legalName（正式登記的公司全名）、taxID（統一編號）、url、logo、sameAs（臉書、IG、官方帳號等社群連結），以及 contactPoint。如果品牌隸屬於某個母集團，還要補 parentOrganization，把集團關係也標出來。我在實務上看過很多網站只填了 name 和 url 就交差，這樣機器認得出「有這家公司」，卻拼不出完整的品牌輪廓。欄位填得愈完整，知識面板能呈現的資訊就愈豐富。sameAs 這一格我特別看重，因為它把官網和社群帳號串成同一個實體，等於告訴搜尋引擎「這些帳號都是同一個品牌」，是消歧義的重要依據。母集團明確的品牌尤其別漏 parentOrganization，這會讓機器理解你在整個集團裡的定位。
2.2 LocalBusiness 要選對子類型
LocalBusiness 專門處理「你在哪裡、做什麼在地生意」。這裡有個常被忽略的細節：Schema.org 提供了很多更精確的子類型，選對了辨識度更高。以冷氣安裝品牌為例，我會用 HVACBusiness 這個子類型，而不是籠統的 LocalBusiness；醫療診所則有對應的醫療類子型別。核心欄位是 address（公司或據點地址）、telephone、priceRange。這一組資料是本地搜尋與地圖收錄的基礎，掛在聯絡我們頁最合適。
2.3 全站掛還是單頁掛，我的分法
Organization 與 LocalBusiness 的擺放位置不同，這點很多人搞混。我的做法是：Organization 全站每頁都掛，因為品牌身分在任何一頁都成立；LocalBusiness 只掛在聯絡我們或據點頁，因為在地服務資訊有明確的歸屬頁面，全站亂掛反而會讓機器混淆。做完一定要用 Google 的 Rich Results Test 與 Schema.org Validator 兩個工具交叉驗證，我遇過不少案例是欄位漏填或格式錯誤，肉眼看不出來，靠驗證工具才抓得到。
3. FAQPage 與 Product：把頁面內容變成搜尋結果的亮點
3.1 FAQPage 的一致性紅線
很多網站的常見問題頁其實內容很扎實，卻完全沒有 FAQPage schema，等於把 FAQ rich result 的機會白白丟掉。做法不難：把現有的 FAQ 內容轉成 JSON-LD 的 FAQPage 結構，每一題的 question 與 answer 注入對應頁面。但這裡有一條紅線我要特別強調：結構化資料裡的問答文字，必須與頁面上使用者實際看得到的內容一致。我在實務上看過有人為了塞關鍵字，在 schema 裡寫了頁面根本沒有的問答，這種「隱藏內容」是 Google 明令禁止的，被抓到會連累整頁。
3.2 用 Product 或 OfferCatalog 標記產品列表
產品列表頁如果只有麵包屑，Google 只知道「這是個列表頁」，卻不知道列表裡有哪些產品。要解決這點，我會用 OfferCatalog 把整個產品系列包起來，底下每一項用 Product 型別展開。以一個列了八個冷氣系列的產品頁為例，我會把每個系列做成 ListItem，item 裡填入 Product，包含 name、brand、category、description、image、url。這樣機器就能理解「這頁有八項產品，各屬什麼品牌與類別」，長期有助於「品牌加系列名」這類關鍵字的收錄與圖片辨識。
3.3 產品欄位一定要動態帶入
工業儲存廠商的產品頁我也用同一套邏輯，只是型別換成單一 Product：name、brand、sku（型號）、description、image、offers 都要填齊。這裡有個實作重點：這些欄位必須動態帶入每個產品的實際資料，不能寫死。我看過有網站把 image 全部指到同一張公司 logo、description 全用同一段罐頭文字，這種偷懶的 schema 不但沒加分，還可能被判定為低品質標記。sku 和 name 更是要精確對應真實型號，否則產品搜尋根本對不上。
4. Article：讓文章進入 AI 摘要管道
4.1 必填欄位就是 E-E-A-T 的核心
文章詳細頁如果只有 BreadcrumbList，缺了 author、datePublished、dateModified、image、publisher，就進不了 Google 的文章 rich result，也進不了 AI 摘要的引用管道。我會在文章頁注入 Article 或 BlogPosting 的 JSON-LD，必填 headline、image、author（型別用 Organization 或具名作者）、publisher（含 logo）、datePublished、dateModified、mainEntityOfPage。這裡要點出一個關鍵：author 與 publisher 這兩個欄位，正是 E-E-A-T 訊號的核心。機器判斷「這篇文章是誰寫的、誰發布的」，靠的就是這兩格。缺了它們，文章在權威性的評分上等於裸奔。
4.2 發布日期從哪裡取才不會出錯
datePublished 常讓工程端卡住，其實來源很清楚。我的做法是優先從 sitemap 的 lastmod 欄位，或文章的 frontmatter 取得發布與修改時間，這兩處通常是系統自動維護的，比人工填寫可靠。工業儲存廠商的新聞頁與成功案例頁我也是同一套：新聞頁用 NewsArticle、成功案例用 Article、技術說明頁用 TechArticle，headline 與 datePublished 全部動態帶入各文章的實際資料，避免整站日期長得一模一樣這種明顯的破綻。
4.3 上線前的驗證清單
五種 schema 補完不是結束，驗證才是。我整理了實務上最常出包的幾個點，供你上線前逐項檢查。
| 檢查項目 | 常見錯誤 | 驗證方式 |
|---|---|---|
| FAQPage 內容一致 | schema 問答與頁面可見內容不符 | 逐題比對頁面文字 |
| Product 動態資料 | image、description 全站共用同一份 | 抽查數個產品的欄位值 |
| Article 作者與日期 | 缺 author、publisher 或日期寫死 | Rich Results Test |
| Organization 完整度 | 只填 name、url | Schema.org Validator |
| LocalBusiness 位置 | 全站亂掛而非只掛據點頁 | 檢查每頁 schema 類型 |
我的經驗是，文章補齊 Article schema 後，自然流量在四到八週內成長兩到四成並不罕見，AI 引用的機率更是明顯翻倍，因為你終於把文章的來源資訊完整交給了機器。
5. 常見問題
5.1 這五種 schema 一定要全部都做嗎？
看你的網站型態。有實體據點的品牌，Organization 與 LocalBusiness 幾乎是必補；有產品的補 Product；有文章的補 Article；有問答的補 FAQPage。原則是「頁面上有那種內容，就補對應的 schema」，沒有的內容不要硬掛，機器對不上反而扣分。
5.2 JSON-LD 和 Microdata 該用哪一種？
我一律建議 JSON-LD。它以獨立的 script 區塊注入，不需要和 HTML 標籤纏在一起，維護和除錯都最單純，Google 官方也長期推薦這種格式。Microdata 要嵌進每個標籤裡，改版時很容易漏改或破損。
5.3 補了 schema 就一定會出現 rich result 嗎？
不保證。結構化資料是取得 rich result 的必要條件，不是充分條件。Google 會綜合頁面品質、內容一致性等因素決定要不要呈現。正確的心態是：schema 讓你「有資格」被選中，而不是「保證」被選中。但沒有 schema，連入場券都沒有。
5.4 FAQPage 的問答內容可以只放在 schema、不顯示在頁面上嗎？
不行，這是明確的紅線。Google 要求 FAQPage 的問答必須是使用者在頁面上實際看得到的內容。只藏在 schema 裡的問答屬於隱藏內容，違反品質指南，可能導致標記失效甚至人工處分。
5.5 Product schema 的 offers 一定要放價格嗎？
不一定要放實際數字，但要盡量填齊可提供的欄位，例如 availability（供應狀態）、priceCurrency（幣別）、seller。工業產品常採詢價制、沒有公開定價，這種情況可以省略 price，但保留其他欄位仍有助於機器理解這是一項可銷售的產品。