盤點一個冷氣安裝品牌的十三個樣本頁，我們發現全部都沒有 Organization 或 LocalBusiness 結構化資料，結果 AI 搜尋引擎與 Google 知識面板抓不到這個品牌的實體資訊，也對應不上它的在地服務範圍。問題不在內容寫得好不好，而在缺了讓機器對號入座的那一層標記。這篇用一個冷氣安裝品牌與一家工業倉儲商的實例，講清楚五種你幾乎一定得補的 Schema：Organization、LocalBusiness、FAQPage、Product、Article，它們各自解決不同的辨識問題，補齊之後，品牌實體、本地服務、常見問答、產品、文章才能被機器準確抓取。
1. 結構化資料是 AI 搜尋時代的地基
做過這麼多網站健檢，我們觀察到一個現象：大多數網站不是輸在內容，而是輸在「機器看不懂內容」。你寫得再詳細，如果沒有結構化資料，Google 與 AI 搜尋引擎都只能靠猜的去理解你的頁面在講什麼。猜得準不準，就決定了你會不會被收錄、會不會被引用。
1.1 沒有 schema，機器只能用猜的
頁面上的一段文字，人看得懂，但搜尋引擎讀到的其實是一堆沒有標籤的字串。它不知道某一串字是公司名、「壁掛式冷氣」是產品類別、還是某段話是一則常見問答。結構化資料的作用，就是替這些內容貼上機器讀得懂的標籤，把「一段文字」升級成「一個有型別、有屬性的資料物件」。我們在實務上看過同樣的內容，補了 schema 之後在搜尋結果的呈現方式完全不同，差別就在於機器終於不用猜了。這件事在生成式 AI 崛起後更關鍵，因為 AI 引用你之前，得先確定你在講什麼，模糊的純文字它寧可跳過。
可以用一個比喻來理解這層差別：沒有 schema 的網頁，就像一份沒有欄位名稱的試算表，人看得出哪一欄是價格、哪一欄是名稱，機器卻只看到一格一格的字，得自己猜每一格代表什麼。猜錯的代價不是報錯，而是安靜地略過，你永遠不會收到通知。這也是為什麼很多網站內容明明寫得不差，表現卻平平，站長遍尋不著原因。我們在健檢時遇到這類情況，第一件事往往不是去改內容，而是先確認機器到底看懂了多少。把猜測的空間收掉，後面所有努力才站得住腳；反過來說，地基沒打好就拼命加內容，常常是事倍功半。
1.2 我們在兩個產業實測到的差距
我們盤點一個冷氣安裝品牌的十三個樣本頁時，發現全部都沒有 Organization 或 LocalBusiness schema。結果是 AI 搜尋引擎與 Google 知識面板抓不到這個品牌的實體資訊，也對應不上它的本地服務範圍。另一家工業倉儲商也類似：產品頁只告訴 Google「這是個產品列表」，卻沒有標明每一項產品的名稱、品牌、型號。這兩個案例的共通點是，內容本身沒問題，問題出在缺了讓機器對號入座的那層標記。補上之後，品牌字搜尋出現知識面板的機率會上升，根據我們的服務經驗，AI 引用的準確度也能提升三到五成。更實際的影響是，當潛在客戶在 AI 助理裡問「某地區有沒有推薦的冷氣安裝」時，有完整實體標記的品牌比較容易被列為可靠答案，而沒有標記的同業，就算內容再詳細也可能被整個略過。這道落差在搜尋行為逐漸往 AI 轉移的當下，只會愈拉愈開。
1.3 五種 schema 的分工地圖
這五種不是隨便挑的，它們對應五種不同的搜尋意圖與內容型態。先看懂各自的任務，才不會亂貼一通。把對的 schema 貼到對的頁面，效果遠比每頁都塞一堆標記來得好。
| Schema 類型 | 解決什麼辨識問題 | 掛在哪些頁面 |
|---|---|---|
| Organization | 你是誰、屬於哪個集團 | 全站 |
| LocalBusiness | 你在哪裡、提供什麼在地服務 | 聯絡我們、據點頁 |
| FAQPage | 頁面上的問答可被抓成 rich result | 常見問題頁、含 FAQ 的頁 |
| Product | 每項產品的名稱、品牌、型號 | 產品頁、產品列表頁 |
| Article | 文章的作者、日期、封面 | 文章詳細頁、新聞頁 |
2. Organization 與 LocalBusiness：讓品牌變成一個實體
這兩種 schema 處理的是「你是誰、你在哪」。一個回答品牌身分，一個回答在地據點，合起來才讓搜尋引擎把一個模糊的網站，辨識成一個有名有姓、有地址有電話的真實實體。
2.1 Organization 該填的欄位別只填一半
Organization 是全站的品牌身分證，我們建議每一頁都要有。關鍵欄位包括 name、legalName（正式登記的公司全名）、taxID（統一編號）、url、logo、sameAs（臉書、IG、官方帳號等社群連結），以及 contactPoint。如果品牌隸屬於某個母集團，還要補 parentOrganization，把集團關係也標出來。我們在實務上看過很多網站只填了 name 和 url 就交差，這樣機器認得出「有這家公司」，卻拼不出完整的品牌輪廓。欄位填得愈完整，知識面板能呈現的資訊就愈豐富。sameAs 這一格我們特別看重，因為它把官網和社群帳號串成同一個實體，等於告訴搜尋引擎這些帳號都是同一個品牌，是消歧義的重要依據。母集團明確的品牌尤其別漏 parentOrganization，這會讓機器理解你在整個集團裡的定位。
logo 這一格也有不少人踩坑。我們看過有網站把 logo 指向一張尺寸過小、或背景透明到幾乎看不出輪廓的圖，結果知識面板那格就是空的。比較穩的做法是準備一張方正、背景單純、尺寸足夠的品牌標誌，網址能直接開啟、回傳的是實際圖檔而不是一個會跳轉的連結。contactPoint 則建議至少標出客服電話與聯絡類型，讓機器知道這是一個真的能被聯繫到的品牌，而不只是掛個網站。這些欄位填起來不花多少時間，差別在於補齊之後，搜尋引擎對這個品牌的信任基礎才算立得起來。我們的習慣是把 Organization 的欄位當成品牌的「對外名片」逐格檢查一遍，缺哪格補哪格，而不是填到機器不報錯就收手。
2.2 LocalBusiness 要選對子類型
LocalBusiness 專門處理「你在哪裡、做什麼在地生意」。這裡有個常被忽略的細節：Schema.org 提供了很多更精確的子類型，選對了辨識度更高。以冷氣安裝品牌為例，我們會用 HVACBusiness 這個子類型，而不是籠統的 LocalBusiness；醫療診所則有對應的醫療類子型別。核心欄位是 address（公司或據點地址）、telephone、priceRange。這一組資料是本地搜尋與地圖收錄的基礎，掛在聯絡我們頁最合適。子類型選得愈貼近實際業態，搜尋引擎對你的歸類就愈準確。
選子類型時有個實用的判斷順序：先到 Schema.org 的 LocalBusiness 分類底下，看看有沒有直接對應你業態的型別，有就用最貼近的那一個；真的找不到對得上的，再退回用通用的 LocalBusiness，而不是硬套一個沾邊的。我們遇過一家做居家清潔的業者，原本被標成通用 LocalBusiness，後來改用對應清潔服務的子類型後，在地搜尋的相關度明顯更集中。另一個容易被忽略的是地址要和 Google 商家檔案、以及頁面上實際顯示的地址三邊一致，連寫法、樓層、門牌的格式都盡量統一，因為名稱、地址、電話這三項資訊若在不同地方寫得不一樣，搜尋引擎比對時會產生疑慮，反而削弱在地辨識。priceRange 不必寫到精確數字，用符號或區間表達大致的消費級距即可，重點是給機器一個定位這家店價位帶的依據。
2.3 全站掛還是單頁掛，我們的分法
Organization 與 LocalBusiness 的擺放位置不同，這點很多人搞混。我們的做法是：Organization 全站每頁都掛，因為品牌身分在任何一頁都成立；LocalBusiness 只掛在聯絡我們或據點頁，因為在地服務資訊有明確的歸屬頁面，全站亂掛反而會讓機器混淆。做完一定要用 Google 的 Rich Results Test 與 Schema.org Validator 兩個工具交叉驗證，我們遇過不少案例是欄位漏填或格式錯誤，肉眼看不出來，靠驗證工具才抓得到。兩個工具的判讀角度略有不同，交叉比對能補上彼此的盲點。
3. FAQPage 與 Product：把頁面內容變成搜尋結果的亮點
這兩種 schema 的共同點，是把頁面上已經有的內容，轉成搜尋結果裡更醒目的呈現。FAQPage 讓問答有機會被抓成 rich result，Product 讓產品列表被機器看懂裡面有哪些東西。
3.1 FAQPage 的一致性紅線
很多網站的常見問題頁其實內容很扎實，卻完全沒有 FAQPage schema，等於把 FAQ rich result 的機會白白丟掉。做法不難：把現有的 FAQ 內容轉成 JSON-LD 的 FAQPage 結構，每一題的 question 與 answer 注入對應頁面。但這裡有一條紅線我要特別強調：結構化資料裡的問答文字，必須與頁面上使用者實際看得到的內容一致。我們在實務上看過有人為了塞關鍵字，在 schema 裡寫了頁面根本沒有的問答，這種隱藏內容是 Google 明令禁止的，被抓到會連累整頁。schema 是替既有內容貼標籤，不是偷渡額外內容的後門。
FAQPage 還有一個分寸要拿捏：不是每一頁都適合塞一堆問答進 schema。我們建議只標那些真的對使用者有用、而且頁面本來就存在的問答，題數貴精不貴多。把三五題真正常被問到的問題標清楚，勝過硬湊十幾題把關鍵字都塞進去，後者不但顯得刻意，也稀釋了每一題的價值。另外要提醒的是，同一組 FAQ 不要重複標在站內很多不同頁面上，那會讓搜尋引擎難以判斷哪一頁才是這組問答的主場。實務上我們的做法是把完整的常見問題集中在一個 FAQ 頁，其他頁面若要放問答，就只放與該頁主題直接相關的一兩題，各司其職，而不是整站到處複製同一份。
3.2 用 Product 或 OfferCatalog 標記產品列表
產品列表頁如果只有麵包屑，Google 只知道「這是個列表頁」，卻不知道列表裡有哪些產品。要解決這點，我們會用 OfferCatalog 把整個產品系列包起來，底下每一項用 Product 型別展開。以一個列了八個冷氣系列的產品頁為例，我們會把每個系列做成 ListItem，item 裡填入 Product，包含 name、brand、category、description、image、url。這樣機器就能理解「這頁有八項產品，各屬什麼品牌與類別」，長期有助於「品牌加系列名」這類關鍵字的收錄與圖片辨識。產品結構清楚，機器才接得住更細的產品查詢。這對工業或 B2B 類的網站尤其有價值，因為這類買家往往直接搜品牌加型號，或是系列名稱，頁面若沒把每項產品標清楚，這些高意圖的查詢就接不住。把列表頁的每一項都用 Product 展開，等於替每個產品在搜尋引擎裡建了一個可被辨識的節點，而不是讓它們全部淹沒在一個沒有層次的列表裡。
3.3 產品欄位一定要動態帶入
工業倉儲商的產品頁我們也用同一套邏輯，只是型別換成單一 Product：name、brand、sku（型號）、description、image、offers 都要填齊。這裡有個實作重點：這些欄位必須動態帶入每個產品的實際資料，不能寫死。我們看過有網站把 image 全部指到同一張公司 logo、description 全用同一段罐頭文字，這種偷懶的 schema 不但沒加分，還可能被判定為低品質標記。sku 和 name 更是要精確對應真實型號，否則產品搜尋根本對不上。動態帶入雖然前期要和系統對接，卻是產品 schema 能不能真正發揮的關鍵。
4. Article：讓文章進入 AI 摘要管道
Article schema 處理的是內容型頁面的身分：這篇文章是誰寫的、什麼時候發的、封面是什麼。這些資訊不只影響文章 rich result，也直接關係到 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」，沒有的內容不要硬掛，機器對不上反而扣分。先盤點頁面型態，再決定要補哪幾種。我們通常會先把全站頁面按型態分類，列出每一類該對應的 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 裡的問答屬於隱藏內容，違反品質指南，可能導致標記失效甚至人工處分。要放進 schema 的問答，頁面上就要看得到。
5.5 Product schema 的 offers 一定要放價格嗎？
不一定要放實際數字，但要盡量填齊可提供的欄位，例如 availability（供應狀態）、priceCurrency（幣別）、seller。工業產品常採詢價制、沒有公開定價，這種情況可以省略 price，但保留其他欄位仍有助於機器理解這是一項可銷售的產品。填得愈完整，機器對產品的理解就愈到位。
5.6 網站改版或搬家後，原本做好的 schema 需要重做嗎？
要重新驗證，不一定全部重做。改版最怕兩件事：一是模板換了，原本由系統動態帶入的欄位對應錯位，例如日期、作者抓到別的欄位；二是網址結構變了，schema 裡寫死的 url、或 sameAs、item 這些指向連結還停在舊網址，變成失效連結。我們的建議是改版上線後，挑每一種頁面型態各抽一頁，用驗證工具重跑一遍，確認欄位都對得上新結構。如果改版同時做了網址搬遷，那更要逐一檢查 schema 裡所有寫到網址的地方有沒有一起更新。只要資料來源是動態帶入、而非人工寫死，多數情況重驗通過就好，不需要整批重做。
5.7 schema 要自己寫 JSON-LD，還是用外掛產生就好？
看團隊的技術能量與網站規模。小型網站用成熟的外掛或 CMS 內建功能產生 JSON-LD，通常就夠用，省下不少開發工。但外掛是依你填的欄位和它的預設邏輯輸出，它不會替你判斷內容對不對，也可能和佈景主題重複輸出同一類型造成撞車。我們的做法是外掛照用，但上線前一定親自把幾個代表性頁面丟進驗證工具，確認欄位齊全、沒有重複標記。如果是產品量大、或欄位要精確對應資料庫的網站，讓工程端直接從資料來源動態產生 schema 會更可靠，既能保證每項資料正確，也避免人工維護的疏漏。關鍵不在用哪種方式產生，而在產生之後有沒有人真的去驗證它。不論自己寫還是外掛產生，最後一關都一樣：上線前務必實際驗過才算數。