做 SEO 二十年，我看過太多網站把結構化資料當成「加了就有效」的裝飾。實際上，搜尋引擎讀 JSON-LD 的方式很務實：類型選錯、必填欄位缺一角，或是同一頁塞了兩份同類型，輕則豐富結果不顯示，重則整段標記被略過。我是吳承學，這篇想把六種最常用的 JSON-LD 類型講清楚，包括各自用在哪、非填不可的欄位、怎麼驗證，以及同頁為什麼不能重複同一種類型。內容以 2026 年當下搜尋引擎實際採信的規則為準。

1. 我拿到一個頁面，先問自己該套哪一種類型

選型錯誤是我最常在稽核時抓到的問題。很多人看到 Schema.org 上百種類型就慌了，其實一般商業網站真正會用到的，不超過六種。我判斷的方式不是背類型表，而是先問這一頁「對讀者是什麼」。

1-1 WebSite 與 Organization：我把它們當成整站的身分證

這兩種是首頁幾乎都該有的基礎標記。Organization 描述的是品牌本身，名稱、官網網址、標誌、社群連結；WebSite 描述的是這個網站這個實體，可以搭配站內搜尋動作讓搜尋引擎理解你的搜尋框。我的習慣是只在首頁放這兩種，內頁不重複，因為品牌身分不需要在每一頁重講一遍。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "示範品牌",
  "url": "https://example.com",
  "logo": "https://example.com/images/logo.png",
  "sameAs": [
    "https://www.facebook.com/example",
    "https://www.linkedin.com/company/example"
  ]
}
</script>

1-2 Article 與 Product：我用內容的本質決定，而不是版型

如果這一頁在講一件事、一則觀點、一篇教學，就是 Article 家族（新聞用 NewsArticle、技術文用 TechArticle、部落格用 BlogPosting）。如果這一頁在賣一個具體的商品或方案，可標名稱、價格、庫存，那就是 Product 搭配 Offer。我遇過一個匿名的工業零件客戶，把產品分類頁硬套成 Article，結果搜尋結果既沒有價格資訊、也沒有文章日期，兩頭落空。判斷的關鍵是問：使用者是想「讀」還是想「買」。

1-3 FAQ 與 Breadcrumb：我把它們當成點擊率的加分項

FAQPage 適合把頁面上真實存在的問答標記出來，有機會在搜尋結果多佔幾行版面；BreadcrumbList 則讓搜尋結果顯示頁面的層級路徑，讓使用者一眼看出這頁在網站的哪個位置。這兩種我通常視內容補上，但有個前提：FAQ 標記的問答必須是頁面上使用者看得到的內容，不能只寫在 JSON-LD 裡騙版面，這點搜尋引擎抓得很嚴。

2. 必填欄位我漏了哪一個，整段標記就等於白寫

結構化資料最容易被忽略的，是「語法沒錯但欄位不齊」。驗證工具會告訴你這是警告還是錯誤，但我的原則更保守：只要是該類型豐富結果所需的欄位，我一律當必填處理，寧可多填。

2-1 六種類型我的必填清單

下面這張表是我實際稽核時用的檢查基準，欄位名稱以 Schema.org 為準。

類型	用途	我當必填的欄位
Organization	品牌身分	name、url、logo
WebSite	網站與站內搜尋	name、url（站內搜尋另加 potentialAction）
Article／BlogPosting	文章內容	headline、image、datePublished、author、publisher
Product	商品資訊	name、image、offers（含 price、priceCurrency、availability）
FAQPage	問答呈現	mainEntity（每題含 name 與 acceptedAnswer.text）
BreadcrumbList	層級路徑	itemListElement（每層含 position、name、item）

2-2 我最常抓到的三個缺漏

第一個是 Article 缺 dateModified。datePublished 大家都記得填，但文章改過內容卻沒更新修改日期，搜尋引擎會覺得這頁很久沒動。第二個是 Product 的 offers 只填了 price 卻漏 priceCurrency，價格沒有幣別等於無效。第三個是 BreadcrumbList 最後一層還硬塞 item 網址，其實最末層（也就是當前頁）通常不需要再指回自己。這些欄位單看都不起眼，缺了卻會讓豐富結果整段消失。

2-3 欄位內容要與畫面一致，這條我不讓步

結構化資料裡的資訊必須跟使用者實際看到的畫面一致。我看過有人 Product 標記寫「有現貨」，頁面上卻顯示缺貨；也看過 FAQ 標記的答案比頁面上寫的還詳細。這種不一致被判定為誤導的風險很高。我的做法是把 JSON-LD 當成頁面內容的鏡子，畫面改，標記就要跟著改。

3. 我怎麼確認自己真的寫對了，而不是自我感覺良好

寫完 JSON-LD 不代表生效。我一定會走兩道驗證，一道看語法，一道看能不能拿到豐富結果資格。

3-1 兩個驗證工具，我分工使用

Schema Markup Validator 用來檢查語法對不對、欄位有沒有寫錯，它涵蓋的類型比較廣。Rich Results Test 則是站在搜尋引擎角度，告訴你這段標記「有沒有資格」拿到對應的豐富結果。我的順序是先用前者把語法錯誤清乾淨，再用後者確認資格。兩者都通過，我才算這頁的結構化資料收工。

3-2 我看驗證報告時，先分清楚錯誤與警告

驗證結果分成錯誤與警告。錯誤代表這欄位不合規、可能讓整段失效，一定要修；警告代表建議補上、補了效果更完整，但不補通常還能運作。我的判斷是錯誤全修，警告則看這個欄位對呈現有沒有實質幫助再決定。下面這張表是我區分處理的方式。

驗證提示	代表意義	我的處理
錯誤（Error）	欄位不合規，可能導致整段失效	一律修正後重測
警告（Warning）	建議補上，補了呈現更完整	評估欄位價值，多數會補
無提示	語法與資格皆通過	視為可上線

3-3 上線後我還會回頭抽查

驗證工具測的是當下貼上去的那段程式碼。實際網站是動態產生的，模板改版、資料帶錯，都可能讓線上版本跟你測的不一樣。我的習慣是上線一兩週後，用搜尋引擎的網址檢查工具抽幾頁看實際抓到的標記，確認沒有因為模板變動而壞掉。這一步很多人省略，卻是我認為最能避免長期出錯的一步。

4. 同一頁放兩個同類型，我踩過的坑講給你聽

這是我在稽核時反覆遇到的隱形問題。同一頁出現兩份同類型的標記，搜尋引擎會不知道該採信哪一份，輕則忽略，重則整頁結構化資料都打折。

4-1 為什麼會冒出兩份 Article

最常見的原因是外掛與手動標記打架。我遇過一個用內容管理系統的客戶，佈景主題自己會輸出一份 Article，SEO 外掛又輸出一份，作者手動再貼一份，同一頁三份 Article。這三份的欄位還互相矛盾，日期不一樣、作者不一樣。搜尋引擎面對這種情況，最保險的做法就是全部略過。要解，得先盤點這頁到底有幾個來源在輸出標記。

4-2 我用 @graph 把多種類型收在一起

一頁需要多種不同類型是正常的，例如產品頁同時要 Product 和 BreadcrumbList。我的做法是用 @graph 把它們裝在同一段 JSON-LD 裡，各自一個節點，類型不重複。這樣結構清楚，也不會出現同類型撞車。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Product", "name": "示範產品", "image": "https://example.com/p.jpg",
      "offers": { "@type": "Offer", "price": "1200", "priceCurrency": "TWD",
        "availability": "https://schema.org/InStock" } },
    { "@type": "BreadcrumbList", "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "首頁", "item": "https://example.com/" },
      { "@type": "ListItem", "position": 2, "name": "產品", "item": "https://example.com/products/" },
      { "@type": "ListItem", "position": 3, "name": "示範產品" }
    ] }
  ]
}
</script>

4-3 盤點時我固定看這三個地方

要找出重複來源，我固定檢查三處：佈景主題或版型本身是否內建輸出、SEO 外掛的結構化資料設定、以及頁面內容區是否被手動貼了一段。這三處只要有兩處同時輸出同一類型，就會撞車。清點完之後，同一種類型只留一個來源，其他關掉，是我一貫的收尾方式。

5. 常見問題

5-1 結構化資料會直接讓我的排名上升嗎

不會直接改變排名。它的作用是幫搜尋引擎更快理解內容，並讓你有機會取得豐富結果的顯示版面。版面變好、點擊率提升，長期對成效有幫助，但把它當成排名開關並不符合實際。

5-2 一頁沒有任何結構化資料會被扣分嗎

不會被扣分。沒有標記只是少了拿到豐富結果的機會，頁面本身仍能被正常索引。我的建議是先把首頁的品牌基礎標記與有豐富結果潛力的頁面補齊，其他頁面依內容價值排序處理。

5-3 我可以只放在部分頁面而不是全站嗎

可以，而且我更傾向依內容性質分配，而不是全站一律套同一份。品牌基礎標記放首頁、文章標記放文章頁、產品標記放產品頁，每種類型出現在適合的頁面即可，沒有必要每頁都塞。

5-4 JSON-LD 一定要放在 head 裡嗎

不一定。放在 head 或 body 都能被讀取，重點是這段程式碼要出現在初始的原始碼裡，讓搜尋引擎在抓取時就看得到。如果它是靠前端腳本後來才注入，被漏讀的風險會提高，這點要特別留意。

5-5 標記的內容和頁面文字不完全一樣，有關係嗎

有關係，而且風險不小。結構化資料被要求與頁面可見內容一致，若標記寫了畫面上根本沒有的資訊，可能被判定為誤導而失去豐富結果資格。我的原則是標記只描述頁面上真實存在、使用者看得到的內容。

5-6 六種以外的類型我需要學嗎

看你的業務。多數商業網站用這六種就能覆蓋常見情境。若你的內容有明確場景，例如活動、食譜、影音、評論，再依需求補上對應類型即可。與其貪多，我更在意這幾種有沒有寫對、驗證有沒有過。

5-7 外掛自動產生的結構化資料，我可以完全信任嗎

不能照單全收。外掛能省很多事，但它是依你填的欄位和它的預設邏輯輸出，填得不完整、或跟佈景主題重複輸出，都會出問題。我的做法是外掛照用，但上線前一定親自把幾個代表性頁面丟進驗證工具看實際結果，確認欄位齊全、沒有同類型撞車。工具幫你產生，不代表你可以不檢查。