SEO 報告書上常出現一行「建議新增結構化資料」，後面跟著一段大括號包起來的程式碼，多數老闆看到這裡就跳過了。其實概念不難。結構化資料（Structured Data，常被直接叫做 Schema）是一段加在網頁裡、依照共通格式寫成的標記，用來明確告訴搜尋引擎「這個頁面是一篇文章、一項商品還是一家店，以及它的名稱、價格、地址各是什麼」。人看網頁時一眼就知道哪一串數字是電話、哪一串是價格，機器不一定分得出來，結構化資料就是替它標好。
重點摘要
- 結構化資料是寫給搜尋引擎讀的標準化標記，詞彙表由 Schema.org 維護，Google 建議用 JSON-LD 格式撰寫。
- 它讓頁面有資格顯示星等、價格、麵包屑等複合式搜尋結果，但 Google 不保證一定會顯示。
- 中小企業優先做四種就夠：組織或在地商家、文章、麵包屑，有賣東西再加商品。
- 標記的內容必須是頁面上看得到的資訊，標記不存在的評價或價格會違反 Google 的規範。
結構化資料解決的是什麼問題？
解決「機器要用猜的」這個問題。一個食譜頁面上寫著「30 分鐘」，是準備時間、烹調時間還是影片長度？Google 在 結構化資料簡介 中的說法是，這些標記為頁面的意義提供了明確的線索。搜尋引擎不用推測，就能把資訊正確地用在搜尋結果上。
使用者看得到的成果，是搜尋結果裡那些比一般藍色連結更豐富的呈現方式：商品旁邊的價格與庫存、文章的發布日期、網址位置顯示成一層一層的分類路徑、店家的營業時間。這些統稱為複合式搜尋結果。同樣排在第三名，帶著價格與星等的結果通常比純文字的結果更吸引人點擊。
至於標記用的詞彙，例如什麼叫 Product、它有哪些屬性，是由 Schema.org 這個共通詞彙表定義的，主要的搜尋引擎都看得懂。這也是為什麼大家習慣把結構化資料直接叫做 Schema。
JSON-LD、Microdata、RDFa 該用哪一種？
用 JSON-LD。三種格式 Google 都支援，但它建議 JSON-LD，理由是最容易實作與維護。差別在寫的位置：Microdata 和 RDFa 要把屬性一個一個加在頁面的 HTML 標籤上，版面一改就容易弄壞；JSON-LD 是獨立的一段，放在一個 script 標籤裡，跟版面完全分開，設計師改版不會動到它。
一段最簡單的 JSON-LD 大概長這樣，用白話讀就是：這是一家在地商家，名稱是什麼、電話是什麼、地址在哪裡。
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "範例咖啡",
"telephone": "+886-2-1234-5678",
"address": {
"@type": "PostalAddress",
"addressLocality": "台北市",
"streetAddress": "範例路 1 號"
},
"openingHours": "Mo-Fr 08:00-18:00"
}看得出來它並不複雜，就是「欄位名稱：值」一組一組列出來。難的不是語法，而是每一種類型有哪些必填欄位、值要用什麼格式，這些都要對照 Google 針對各類型的說明文件。
中小企業網站該先做哪幾種？
先做跟你的頁面類型直接對應的那幾種，不用貪多。Schema.org 上有幾百種類型，Google 實際會拿來顯示複合式結果的只是其中一部分。下面是我們幫一般企業網站規劃時的優先順序。
| 類型 | 放在哪些頁面 | 說明的內容 | 誰該做 |
|---|---|---|---|
| Organization | 首頁 | 公司名稱、標誌、聯絡方式、官方社群 | 所有公司 |
| LocalBusiness | 首頁或門市頁 | 地址、電話、營業時間 | 有實體據點的商家 |
| Article／BlogPosting | 每篇文章 | 標題、作者、發布與更新日期 | 有部落格或消息區的網站 |
| BreadcrumbList | 首頁以外的所有頁面 | 頁面在網站中的層級位置 | 頁面超過一層的網站 |
| Product | 商品頁 | 價格、庫存、評價 | 購物網站 |
| FAQPage | 有問答內容的頁面 | 問題與答案 | 視情況，見下方說明 |
FAQPage 需要特別說明。它曾經是最熱門的類型，因為搜尋結果下方會直接展開問答、版面占得很大。但依 Google 文件（截至 2026 年），常見問題的複合式結果只會顯示給知名且具權威性的政府與健康類網站，一般企業網站加了也不會出現那個展開的樣式。它仍然能幫助機器理解頁面上哪些是問題、哪些是答案，所以加了沒有壞處，只是不要因為報告上寫「可增加搜尋版面」就抱著過高期待。
有實體店面的商家，LocalBusiness 要跟 Google 商家檔案的資料保持一致，名稱、地址、電話寫法都相同。在地搜尋的整體做法請看 本地 SEO 優化。
做了結構化資料，搜尋結果就會出現星星嗎？
不一定。Google 的文件寫得很清楚，加上結構化資料只是讓頁面「有資格」顯示複合式結果，不保證會顯示。要不要顯示、顯示哪一種，由 Google 依查詢、裝置、頁面品質等因素決定。我們遇過客戶因為「標記都驗證通過了，為什麼搜尋結果沒變」來問，答案通常就是這個。
排名也一樣要講清楚。結構化資料的作用是幫助搜尋引擎理解內容與改變結果的呈現方式，Google 並沒有說加了就會提升名次。如果有廠商用「加 Schema 保證排名上升」來推銷，請保留一點懷疑。它是一項做了有好處、成本不高的基礎工程，但不能取代內容本身的品質。
最常見的錯誤：標記頁面上沒有的東西
Google 的規範要求結構化資料只能標記使用者在頁面上看得到的內容。最常見的違規是評價：頁面上根本沒有顧客評論的區塊，卻在標記裡寫了 4.9 顆星、兩百則評論，想騙出搜尋結果的星等。這種做法被發現後，網站可能失去顯示複合式結果的資格，嚴重時會收到人工處置通知。
不是故意的錯誤也很多。商品價格改了，標記裡的價格沒跟著改；文章改版後標題換了，JSON-LD 裡的 headline 還是舊的；整個網站每一頁都貼上同一段首頁的標記。這些都是「標記與實際內容不一致」。解決方法是讓標記由系統從同一份資料自動產生，而不是手動貼上後就忘記它。網站改版時也要檢查新版型有沒有把標記帶過去，這一點我們在 網站改版怎麼做才不掉排名 裡也提到過。
怎麼加上去？怎麼確認有做對？
加法看網站是怎麼架的。WordPress 與多數套版架站平台已內建或可透過 SEO 外掛自動產生基本的結構化資料，你要做的是把公司資訊填完整，並檢查輸出是否正確。客製網站則請工程師在版型裡依資料自動輸出 JSON-LD。不論哪一種，做完都照下面的步驟驗證。
驗證步驟
- 用 Google 的複合式搜尋結果測試工具貼上網址，確認偵測到預期的類型，沒有錯誤。
- 逐項對照標記裡的值與頁面上顯示的文字，名稱、價格、日期是否一致。
- 每一種頁面類型各抽一頁測試：首頁、文章頁、商品頁、分類頁。
- 上線後到 Search Console 用網址審查工具，確認 Google 實際抓到了結構化資料。
- 之後定期查看 Search Console 的強化項目報表，有新的錯誤或警告就處理。
警告與錯誤的差別也順便說明：錯誤代表缺了必填欄位，該頁沒有資格顯示複合式結果，一定要修；警告代表缺了建議欄位，不影響資格，有資料就補，沒有就算了，不需要為了消除警告去編造內容。
結構化資料對 AI 摘要有幫助嗎？
有間接的幫助，但不是必要條件。Google 官方的說法是，出現在 AI 摘要不需要特殊的結構化資料。它的價值在於降低機器誤讀的機會：這篇文章是誰寫的、什麼時候更新、這家公司的正式名稱與官方網站是哪一個，這些資訊標清楚，對任何需要理解你網站的系統都有好處。
所以我們的建議是把它當成地基，不是捷徑。該做的四種基本類型做好、保持與頁面內容一致，然後把心力放回內容的寫法上。段落怎麼寫才容易被引用，請接著看 怎麼讓內容被 AI 摘要引用。
常見問題
結構化資料和 meta 標籤、Open Graph 有什麼不同？
三者的對象不同。meta 的標題與描述主要影響搜尋結果顯示的文字；Open Graph 決定連結分享到社群與通訊軟體時的預覽圖文；結構化資料則是向搜尋引擎描述頁面內容的類型與屬性。三種可以同時存在，互不取代。
一個頁面可以放多種結構化資料嗎？
可以，而且很常見。一篇文章頁同時有文章、麵包屑與組織三種標記是正常的做法。原則是每一種都要對應頁面上實際存在的內容，並且彼此的資訊不互相矛盾。
加上結構化資料後，多久會在搜尋結果看到變化？
要等 Google 重新抓取並處理該頁面，短則幾天，長則數週，沒有固定時間。可以在 Search Console 用網址審查工具要求重新建立索引來加快。即使處理完成，是否顯示複合式結果仍由 Google 決定。