結構化資料是什麼?複合式搜尋結果的原理與三種格式
語意化 HTML 告訴搜尋引擎「哪一段是主內容」,結構化資料(Structured Data)則進一步告訴它「這段內容是什麼」,是一篇文章、一個商品、一場活動,還是一組問答。
它用的詞彙表來自 Schema.org ,這是由 Google、Microsoft、Yahoo 與 Yandex 共同維護的標準。標記完成後,搜尋引擎就可能用 複合式搜尋結果(Rich Results)來呈現這一頁:多出星等、價格、麵包屑路徑或縮圖。
它爭取的是呈現,不是排名
結構化資料不會直接提升排名
這是最需要先講清楚的一點。標記正確不會讓頁面往前排,它爭取的是 搜尋結果長什麼樣。
實際的收益路徑是:多出的資訊(星等、價格、路徑)讓結果更醒目 → 點擊率上升 → 成效改善。排名本身仍由內容相關性與品質決定。
三種格式怎麼選
同一份語意可以用三種格式寫,實務上只有一個選擇。
| 格式 | 寫在哪 | 維護成本 | 建議 |
|---|---|---|---|
| JSON-LD | 獨立的 <script> 區塊 | 低,與版面解耦 | 選這個 |
| Microdata | 散落在 HTML 標籤的屬性上 | 高,改版面就會動到 | 既有專案才維護 |
| RDFa | 同上,語法更繁瑣 | 高 | 不建議新用 |
JSON-LD 的優勢很直接:標記集中在一處、與 HTML 結構無關、可以由後端或建置流程整批產生。以本頁自己的 Article 標記為例:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "結構化資料是什麼?複合式搜尋結果的原理與三種格式",
"author": { "@type": "Person", "name": "Away" },
"datePublished": "2026-09-07"
}
</script>語法細節、@graph 的用法與常見錯誤,見 JSON-LD 語法與驗證 。
常用的類型
Schema.org 定義了上千種類型,但搜尋引擎只對其中一部分提供複合式結果。下表是實務上最常用的幾種。
| 類型 | 適用頁面 | 說明 |
|---|---|---|
Article | 文章、部落格、新聞 | 最通用的一種,內容型網站的預設選擇 |
BreadcrumbList | 有階層的任何頁面 | 讓搜尋結果顯示網站路徑而非長網址 |
FAQPage | 常見問答區 | 顯示範圍已被縮減,但語意仍有價值 |
HowTo | 步驟教學 | 已停止顯示複合式結果 |
Product | 商品頁 | 顯示價格、庫存與評價 |
Organization | 首頁、關於頁 | 品牌識別與知識面板 |
VideoObject | 含影片的頁面 | 影片縮圖與關鍵時刻 |
LocalBusiness | 門市、據點頁 | 地址、營業時間與地圖資訊 |
政策紅線:標記必須對應真實內容
這是唯一會招致處罰的部分,務必記清楚。
這些做法屬於違規
- 標記不存在的內容:頁面上沒有評價,卻標了
AggregateRating。 - 標記隱藏的內容:問答藏在使用者展不開的區塊裡,卻標成
FAQPage。 - 自己給自己評價:在自家商品頁標記由自己產生的星等。
- 標記與畫面不一致:畫面顯示售價 1200,標記寫 990。
後果是複合式結果被取消,嚴重時會收到人工處罰通知。
反過來說,正確的順序永遠是 先有內容、再加標記。本系列在示範 Product、LocalBusiness、VideoObject 這些類型時,範例一律只寫在程式碼區塊裡,不會真的注入到頁面的檔頭,因為這些頁面本身並不是商品頁或門市頁。
驗證流程
寫完不要憑感覺,跑一遍這三個工具:
| 工具 | 看什麼 |
|---|---|
| 複合式搜尋結果測試 | 這一頁能不能取得複合式結果、缺哪些欄位 |
| Schema Markup Validator | 純語法與型別是否合法,不限於 Google 支援的類型 |
| Search Console 強化報告 | 全站範圍的錯誤統計與趨勢 |
前兩者測單頁、給即時結果;第三者看全站、有延遲但能發現整批錯誤。
這一組還有這些主題
| 主題 | 說明 |
|---|---|
| JSON-LD 語法與驗證 | @context、@type、@id 與 @graph 的用法 |
| 文章 Article | 與 BlogPosting、NewsArticle 的差別 |
| 常見問答 FAQPage | 結構、可見性規定與顯示現況 |
| 麵包屑 BreadcrumbList | 與網址階層一致的重要性 |
| 步驟教學 HowTo | 欄位寫法與停止顯示後的定位 |
| 商品與報價 Product | 價格、庫存、評價與政策紅線 |
| 組織與網站 Organization | logo、sameAs 與網站名稱 |
| 影音與圖片 | 縮圖、時長、關鍵時刻與授權欄位 |
| 在地商家與活動 | 地址、營業時間與售票資訊 |
常見問題
加了結構化資料排名就會上升嗎?
不會直接上升。結構化資料爭取的是搜尋結果的呈現方式,例如:顯示星等、價格或麵包屑路徑。這些額外資訊會提高點擊率,而點擊率的改善才可能間接反映在成效上。
三種格式該選哪一個?
選 JSON-LD。它把標記集中在一個獨立的 <script> 區塊裡,與版面結構完全解耦,改版面不會動到標記,也是 Google 明確建議的格式。Microdata 與 RDFa 需要把屬性散落在 HTML 標籤上,維護成本高得多。
標記的內容一定要跟頁面上看到的一樣嗎?
一定要。這是搜尋引擎結構化資料政策的硬性規定:標記必須描述頁面上使用者真正看得到的內容。標記不存在的評價、不存在的價格或隱藏起來的問答,屬於違規行為,可能導致複合式結果被取消甚至人工處罰。
為什麼驗證通過了卻沒有出現複合式結果?
驗證通過只代表語法與必填欄位正確,不保證會顯示。搜尋引擎仍會依內容品質、網站權重與該次搜尋的情境決定要不要用。此外部分類型已被官方縮減顯示範圍,例如:HowTo ,即使標記正確也不再顯示。
單頁應用程式的結構化資料怎麼處理?
最穩的是在伺服器端渲染或建置階段就把標記寫進 HTML。若只能在用戶端注入,要確認注入時機在頁面渲染完成前,並用 網址檢查工具 確認搜尋引擎渲染後真的讀到了那段標記,做法見 SPA 動態 title 與 meta 。