很多人在搜尋「結構化資料怎麼加」的時候，查到的答案五花八門：有人說用 Microdata、有人說加 JSON-LD、有人說裝 SEO 外掛就好。但如果你實際打開 Google 官方文件，會發現一件事：JSON-LD 是 Google 唯一明確推薦優先使用的格式。這篇文章的目的很具體：解釋 JSON-LD 是什麼格式、語法邏輯怎麼讀、怎麼加到網站上、怎麼驗證、加了之後出問題怎麼診斷。不是概念介紹，是可以邊看邊操作的技術指南。
JSON-LD 是什麼？為什麼 Google 只推薦這一種格式？
JSON-LD（JavaScript Object Notation for Linked Data）是一種把語意資料嵌入網頁的方式，透過獨立的 <script> 標籤實作，不需要修改頁面的 HTML 結構。Google 之所以推薦 JSON-LD，原因很直接：維護成本最低、最不容易出錯、JavaScript 動態注入也支援。
它的長相是這樣的：
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "JSON-LD Schema 是什麼",
"author": {
"@type": "Person",
"name": "Kevin Wu"
}
}
</script>整段資料放在一個 <script type="application/ld+json"> 區塊內，Google 爬蟲讀取時會解析這段 JSON，不影響頁面樣式或使用者看到的內容。這種「資料與頁面分離」的設計，讓修改和擴充都比 Microdata 容易很多。
有一個常見誤解要先釐清：JSON-LD 是格式，schema.org 是詞彙表。JSON-LD 只是一種語言，schema.org 定義了這個語言裡可以說的「詞」。Schema 結構化資料的完整概念可以參考 Silo 4 的主文章；這篇聚焦在 JSON-LD 這種格式本身。
JSON-LD、Microdata、RDFa 三種格式怎麼選？
結構化資料有三種主要格式，但對大多數網站來說，選擇不需要猶豫太久：Google 官方文件明確推薦 JSON-LD，除非你用的 CMS 只支援 Microdata 或 RDFa。
| 格式 | 語法位置 | 維護難度 | Google 推薦 | 適合場景 |
|---|---|---|---|---|
| JSON-LD | 獨立 <script> 標籤 | 低 | 是（優先） | 大多數網站；WordPress + 外掛；SPA |
| Microdata | 嵌入 HTML 屬性 | 高 | 支援 | 需要結構化資料緊貼 HTML 節點的特殊情境 |
| RDFa | 嵌入 HTML 屬性 | 高 | 支援 | 政府/學術網站；舊有 Drupal 系統 |
Microdata 和 RDFa 的問題在於：資料和頁面 HTML 深度綁定。當你修改頁面排版，很容易把結構化資料一起破壞掉。JSON-LD 因為是獨立區塊，改版時只要維護那段 script 就好。如果你的網站沒有特殊限制，直接用 JSON-LD。
@context、@type、@id：JSON-LD 三個核心屬性怎麼讀？
JSON-LD 語法裡最重要的三個屬性是 @context、@type、@id，搞懂這三個之後，剩下的屬性都是填資料。
@context 宣告你用的詞彙來自哪裡。幾乎所有 SEO 用的結構化資料都寫 "@context": "https://schema.org"，這告訴 Google：接下來用的詞（Article、Product、Person）都是 schema.org 定義的。
@type 宣告這個實體是什麼。"@type": "Article" 說這個頁面是一篇文章；"@type": "Product" 說這是一個產品。Google 根據 @type 決定這個頁面有沒有資格出現在特定的複合式搜尋結果裡。
@id 是這個實體的唯一識別符，通常填頁面的 canonical URL。它的作用是告訴 Google：當你在其他地方看到同一個 URL 或同一個實體，它們是同一件事。對 entity disambiguation（實體消歧）很重要：尤其是當你的品牌名稱可能跟其他東西同名時。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/blog/what-is-seo",
"headline": "SEO 是什麼",
"datePublished": "2026-05-01",
"author": {
"@type": "Person",
"name": "Kevin Wu",
"url": "/author/kevin-wu"
},
"publisher": {
"@type": "Organization",
"name": "Nitikarn Clinic",
"url": ""
}
}
</script>這是一個完整的 Article JSON-LD 最小結構。author 和 publisher 是巢狀物件，各自也有 @type。Google 要的 required fields 因 schema 類型而異，用 Rich Results Test 驗證會直接告訴你少了哪個。
怎麼在網站加入 JSON-LD？四種實作方式比較
JSON-LD 可以放在 HTML 的任何位置，不管是 head 還是 body，Google 爬蟲都能正確讀取和解析。實際選哪種方式取決於你的技術棧和維護需求。
方式一：直接寫在 HTML 模板。最直接，把 <script type="application/ld+json"> 區塊加進 <head>。適合靜態網站或有能力改模板的開發者。
方式二：WordPress 外掛（Yoast SEO / RankMath）。兩個主流 SEO 外掛都會自動輸出 Article、BreadcrumbList、WebSite 等 JSON-LD。問題是輸出內容不一定完整：要怎麼確認？打開 Chrome DevTools，按 F12，Ctrl+F 搜尋 application/ld+json，直接看輸出的 JSON 是否有你需要的欄位。
方式三：Google Tag Manager。透過自訂 HTML 標記把 JSON-LD 注入頁面。優點是不需要改程式碼；缺點是 GTM 是 JavaScript 執行，Googlebot 要等渲染才能讀到（見下節 SPA 問題）。
方式四：後端動態生成。適合電商網站，每個產品頁面的 JSON-LD 根據資料庫資料自動產生。這是最彈性的方式，但要確保輸出格式符合 schema.org 規範。
哪種方式都可以，重點是驗證輸出結果：這在下面的驗證章節會說明。
JSON-LD 能解鎖哪些 Google 複合式搜尋結果？
JSON-LD 標記正確並通過驗證，才有機會觸發 Google 的複合式搜尋結果（Rich Results）。以下是常見類型：
| Schema 類型 | Rich Results 樣式 | 常見頁面 | 關鍵必填欄位 |
|---|---|---|---|
| Article | 標題、發布日期、作者（部分版面） | 新聞、部落格 | headline, datePublished, author |
| FAQPage | 問題直接展開在 SERP | FAQ 頁面 | mainEntity（問題+答案陣列） |
| Product | 價格、星等、庫存狀態 | 電商商品頁 | name, offers（含 price + availability） |
| BreadcrumbList | 麵包屑路徑顯示在 URL 下方 | 所有頁面 | itemListElement（含 name + item + position） |
| HowTo | 步驟卡片 | 教學操作頁面 | name, step（含 name + text 陣列） |
| LocalBusiness | 知識圖譜側欄、地圖資訊 | 實體店面 | name, address, telephone |
注意：通過驗證不等於一定會出現 Rich Results。Google 保有最終顯示決定權：內容品質、索引狀態、使用者搜尋意圖都會影響。驗證是必要條件，不是充分條件。
不同頁面類型要用哪種 JSON-LD schema？
每種頁面類型有對應的 schema 類型，選錯 @type 是最常見的 JSON-LD 設定錯誤。以下是技術 SEO 實務最常碰到的頁面類型與對應 schema 對照。
文章/部落格頁：用 Article 或更具體的 BlogPosting、NewsArticle。一般技術文章用 Article 就夠，新聞媒體用 NewsArticle。
產品頁（電商）：用 Product，搭配 offers 巢狀 Offer 提供價格資訊。這是最能直接提升電商頁面 SERP 曝光的 schema。
常見問題頁 / FAQ 區塊：用 FAQPage。注意：Google 2023 年底開始限縮 FAQ Rich Results 的展示，只有「高知名度」的站才有機會觸發：但加了沒有損失，有比沒有好。
操作教學頁：用 HowTo，每個步驟對應一個 HowToStep。手機版 SERP 可能顯示步驟卡片。
所有頁面：加 BreadcrumbList。這個 schema 對頁面本身的 Rich Results 沒影響，但能讓搜尋結果的 URL 列顯示可讀的麵包屑路徑，提升 CTR。
如果你的頁面同時符合多種 schema（例如一篇有 FAQ 區塊的 HowTo 文章），可以在同一頁面放多個 JSON-LD 區塊，或用 @graph 陣列把多個實體放在同一個 script 標籤裡。
怎麼驗證 JSON-LD 標記有沒有問題？
驗證 JSON-LD 分兩層：語法格式正確，以及符合 Google Rich Results 所要求的 schema 結構。這兩個層次有不同工具對應，各有各的用途。
Google Rich Results Test（search.google.com/test/rich-results）：輸入 URL 或貼上 HTML，工具會告訴你哪種 Rich Results 觸發條件符合、哪些必填欄位缺少。這是你最主要應該用的驗證工具。
操作步驟：
- 打開 Rich Results Test
- 輸入要測試的頁面 URL，按「測試網址」
- 等工具抓取頁面（通常 10-30 秒）
- 看「偵測到的結構化資料」區塊：綠色 = 有效；黃色 = 警告；紅色 = 錯誤
- 點進每個結構化資料類型，看哪個欄位有問題
Schema.org Validator（validator.schema.org）：這個工具不管 Google 的 Rich Results 規則，只驗證 JSON-LD 語法是否符合 schema.org 詞彙。如果 Rich Results Test 說有錯，可以用這個工具進一步排查是詞彙問題還是 Google 特定規則問題。
有個常見情況：Rich Results Test 說「目前沒有觸發任何複合式搜尋結果」，但 JSON-LD 語法完全正確。這不是驗證失敗，而是 Google 判斷條件不符。原因診斷見最後一節。
JSON-LD 常見錯誤有哪些、怎麼修？
Google Search Console 的「Search Appearance > 複合式搜尋結果」（Enhancement 報告）會列出結構化資料錯誤。看到錯誤訊息，對照以下診斷表：
| GSC 錯誤訊息 | 原因 | 修復方式 |
|---|---|---|
| 缺少必填欄位 [field name] | 該 schema 類型的 required 屬性沒有填 | 查 developers.google.com 找該類型的 required fields，補上 |
| 無效的 URL | URL 欄位格式錯誤（少 https://、有空格等） | 確認所有 URL 類型欄位是完整格式 |
| 無效的日期 | 日期格式不符 ISO 8601（例如：2026/05/01 應為 2026-05-01） | 統一改成 YYYY-MM-DD 或 YYYY-MM-DDTHH:MM:SS+08:00 |
| 找不到欄位 [field] | 屬性名稱打錯（schema.org 屬性大小寫敏感） | 對照 schema.org 文件確認屬性名稱 |
| 值超出允許範圍 | enum 類型的值填了不被允許的選項（例如 availability 填了 "inStock"，應為 "https://schema.org/InStock"） | 改成完整 schema.org URL 格式 |
GSC Enhancement 報告的操作路徑是：Google Search Console > 左側「Search Appearance」（或「搜尋結果樣貌」）> 找對應的結構化資料類型 > 點進去看受影響的頁面清單。點擊特定頁面後，會顯示具體錯誤欄位，這時用 Rich Results Test 測同一個 URL，可以看到完整的 JSON-LD 樹狀結構，找出哪個屬性出問題。
修復後要做一件事：在 GSC 的錯誤頁面清單裡，選取已修復的頁面，點「驗證修正」，讓 Google 重新審查。否則 GSC 不會主動更新狀態。
JavaScript 框架網站的 JSON-LD 要特別注意什麼？
如果你的網站是 React、Vue、Next.js、Nuxt 等 JavaScript 框架，JSON-LD 的讀取時機需要特別注意。Googlebot 在爬取頁面時會先讀取 HTML，然後才執行 JavaScript 渲染。如果 JSON-LD 是由 JavaScript 動態插入 DOM，Googlebot 可能在渲染完成前就離開，導致 GSC 看不到結構化資料。
怎麼確認這個問題？到 Google Search Console > URL 審查 > 輸入頁面 URL > 點「檢視已抓取的頁面」> 切換到「螢幕截圖」和「HTML」Tab。如果 HTML Tab 裡看不到 application/ld+json，代表 Googlebot 爬取時還沒執行到那段 JavaScript。
解決方式有兩種：
- Server-Side Rendering (SSR)：讓 JSON-LD 在伺服器端渲染，輸出在初始 HTML 裡。Next.js 可以在
getServerSideProps或generateMetadata裡直接輸出。這是最穩的方式。 - 靜態 HTML 注入：如果框架支援，在建構時把 JSON-LD 寫死進頁面模板的
<head>，不透過 JavaScript 插入。
GTM 注入的 JSON-LD 也有同樣的渲染時機問題。如果你用 GTM 管理結構化資料，建議把重要的 JSON-LD 改到 HTML 模板直接輸出，GTM 只保留不影響索引的追蹤型資料。
JSON-LD 標記正確但沒出現在搜尋結果，原因是什麼？
這是最讓人困惑的情況：Rich Results Test 說 JSON-LD 有效，GSC 也沒有錯誤，但搜尋結果就是不出現 Rich Results。遇到這個情況，按順序排查以下四個條件：
條件一：頁面有沒有被 Google 索引？Rich Results 只出現在已索引的頁面。到 GSC URL 審查工具，確認頁面狀態是「已在 Google 上建立索引」。如果頁面剛發布，等一到兩週讓 Google 重新爬取。
條件二：JSON-LD 的資料和頁面內容是否一致？Google 會比對 JSON-LD 裡的資訊和頁面可見內容。例如 Product schema 裡寫的價格是 NT$ 1,200，但頁面上顯示 NT$ 0 或沒有顯示價格：這會被視為資料不一致，Google 不信任這個 schema 的資料，不會觸發 Rich Results。
條件三：是否有其他品質問題觸發 Spam 判斷？如果頁面內容薄弱（字數極少、複製貼上、純廣告）、網站整體品質低，Google 可能直接跳過你的 JSON-LD。這不是 JSON-LD 本身的問題，而是整體網站品質的問題，需要從內容品質著手。
條件四：該 schema 類型的 Rich Results 顯示門檻。某些 schema 類型（如 FAQ、HowTo）Google 已縮減展示，優先給特定類別的站點。在 技術 SEO 稽核實務中，我的做法是：不因為目前沒出現就移除 JSON-LD，等個三個月，同時把重點放在提升整體頁面品質和索引率，而不是反覆調整 JSON-LD 格式。
上週有個客戶說他的電商網站加了 Product schema 兩個月，搜尋結果還是沒有顯示星等和價格。我拉了 GSC 的 Coverage 報告，才發現那些商品頁面其實根本沒有被 Google 索引：原因是內部的 canonical 設定把流量都導向了一個分頁版的 URL。結構化資料正確與否不是問題所在，索引才是。這是最常被忽略的根本原因。
要系統性管理 JSON-LD 的狀態，GSC 的 Schema 相關報告是主要工具。如果你還沒設定過 GSC，可以參考站內的 Schema 結構化資料完整指南，從基礎到 debug 都有說明。外部資源方面，Google Developers 結構化資料文件和 Schema.org 詞彙表是最終的參考來源。
進一步了解各種 Schema 類型的具體實作，可以從 Article Schema 完整實作指南開始，其中包含 BlogPosting 的完整屬性設定與 GSC 驗證流程。