選錯類型、漏填必填欄位、同一頁塞了兩份同類型，是結構化資料最常見的三個失效原因。JSON-LD 不是「加了就有效」的裝飾，搜尋引擎讀它的方式其實很務實：類型對不上內容、該有的欄位缺一角，或同頁出現互相矛盾的兩份標記，輕則豐富結果不顯示，重則整段標記被略過。這篇把六種最常用的 JSON-LD 類型講清楚，包括各自用在哪、哪些欄位非填不可、怎麼驗證，以及同頁為什麼不能重複同一種類型。內容以 2026 年當下搜尋引擎實際採信的規則為準。
1. 拿到一個頁面，先判斷它該套哪一種類型
選型錯誤是我們稽核時最常抓到的問題。很多人看到 Schema.org 上百種類型就慌了，其實一般商業網站真正會用到的，不超過六種。判斷的方式不是背類型表，而是先問這一頁「對讀者是什麼」，再決定標記。
1.1 WebSite 與 Organization：整站的身分證
這兩種是首頁幾乎都該有的基礎標記。Organization 描述的是品牌本身，名稱、官網網址、標誌、社群連結；WebSite 描述的是這個網站這個實體，可以搭配站內搜尋動作，讓搜尋引擎理解你的搜尋框。根據我們的服務經驗，這兩種只放在首頁、內頁不重複就夠了，因為品牌身分不需要在每一頁重講一遍，重複反而讓搜尋引擎難判斷哪一頁才是品牌的主場。
這裡面最容易出錯的其實是 sameAs。我們診斷過一家做教育訓練的公司，社群連結貼了五個，其中兩個是早就停用的舊帳號，一個還連到別人同名的粉專。sameAs 的用意是幫搜尋引擎把你的品牌跟這些外部檔案串成同一個實體，連結若指向失效或不相干的頁面，串接就會斷掉，嚴重時反而讓搜尋引擎對這個品牌的身分起疑。我們的建議是只放目前還在經營、內容與品牌一致的官方帳號，數量不用多，三到五個活躍的比十個半死不活的有用。標誌網址也要能直接開得起來，指向一張實際存在的圖片，不要填一個會跳轉或回傳錯誤的路徑，這些小地方搜尋引擎都會實際去抓。
<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，結果搜尋結果既沒有價格資訊、也沒有文章日期，兩頭落空。判斷的關鍵是問：使用者是想「讀」還是想「買」。
實務上會讓人猶豫的，通常是那種介於兩者之間的頁面。像是一篇很長的產品介紹文，既在講技術觀念、又列了規格和售價，這時到底算 Article 還是 Product。我們的判準是看這一頁的主要目的與主要的轉換行為：如果讀者看完最直接的動作是加入購物車或詢價，那它本質就是 Product，技術說明只是輔助；如果它不帶任何購買入口、純粹在建立信任與知識，那就是 Article。碰到真的難分的頁面，我們寧可拆成兩頁，一頁純知識、一頁純銷售，各自套對應的類型，也不要在同一頁硬塞兩種主類型。這樣做不只標記乾淨，對使用者的動線、對內部連結的規劃也都更清楚，長期看反而省下反覆修改的成本。
1.3 FAQ 與 Breadcrumb：點擊率的加分項
FAQPage 適合把頁面上真實存在的問答標記出來，有機會在搜尋結果多佔幾行版面；BreadcrumbList 則讓搜尋結果顯示頁面的層級路徑，讓使用者一眼看出這頁在網站的哪個位置。這兩種我們通常視內容補上，但有個前提：FAQ 標記的問答必須是頁面上使用者看得到的內容，不能只寫在 JSON-LD 裡騙版面，這點搜尋引擎抓得很嚴。與其硬加，我們更傾向只標頁面真的存在的問答。值得一提的是，Breadcrumb 的階層要跟網站實際的目錄結構對得上，如果麵包屑寫「首頁＞產品＞示範產品」，網址卻是另一套分類，搜尋引擎對照後同樣可能忽略整段。我們的經驗是，這兩種標記的價值不在多，而在跟畫面與網址一致，一旦對不上，加了反而是扣分。
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 當成頁面內容的鏡子，畫面改，標記就要跟著改，兩邊永遠同步。
會出現不一致，多半不是故意造假，而是兩邊由不同機制維護、更新節奏對不上。常見的情況是價格和庫存在後台改了，頁面即時反映，但結構化資料是另一段靜態模板或快取，沒有跟著刷新，於是畫面顯示新價、標記還停在舊價。我們替客戶排查時會特別問一句：這段 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 外掛的結構化資料設定、以及頁面內容區是否被手動貼了一段。這三處只要有兩處同時輸出同一類型，就會撞車。清點完之後，同一種類型只留一個來源，其他關掉，是我們一貫的收尾方式。與其靠直覺猜，不如把這三處逐一排查一遍。
盤點的手法其實很土法煉鋼，但很有效：打開頁面原始碼，把所有 application/ld+json 的區塊全部找出來，一段一段看它們各自宣告了哪些 @type。如果數出兩段都寫著同一種類型，那就是撞車現場。判斷該留哪一段時，我們的優先順序是留下欄位最完整、且資料來源最可靠的那一份，通常是能跟頁面內容連動的系統產生版，把手動貼的、或外掛和主題重複輸出的多餘那份關掉。關閉外掛某一類標記時要留意，有些外掛是全站統一開關，關掉會連帶影響其他頁面，這時得改用頁面層級的設定或例外規則，而不是一刀全關。處理完一頁，最好把同一套模板的其他頁面也一起驗一遍，因為重複輸出往往是模板層級的問題，單修一頁治標不治本。
5. 常見問題
5.1 結構化資料會直接讓我的排名上升嗎
不會直接改變排名。它的作用是幫搜尋引擎更快理解內容，並讓你有機會取得豐富結果的顯示版面。版面變好、點擊率提升，長期對成效有幫助，但把它當成排名開關並不符合實際。它是加分項，不是排名因子本身。
5.2 一頁沒有任何結構化資料會被扣分嗎
不會被扣分。沒有標記只是少了拿到豐富結果的機會，頁面本身仍能被正常索引。我們的建議是先把首頁的品牌基礎標記，與有豐富結果潛力的頁面補齊，其他頁面依內容價值排序處理，不需要為了有而有。
5.3 我可以只放在部分頁面而不是全站嗎
可以，而且我們更傾向依內容性質分配，而不是全站一律套同一份。品牌基礎標記放首頁、文章標記放文章頁、產品標記放產品頁，每種類型出現在適合的頁面即可，沒有必要每頁都塞。
5.4 JSON-LD 一定要放在 head 裡嗎
不一定。放在 head 或 body 都能被讀取，重點是這段程式碼要出現在初始的原始碼裡，讓搜尋引擎在抓取時就看得到。如果它是靠前端腳本後來才注入，被漏讀的風險會提高，這點要特別留意。
5.5 標記的內容和頁面文字不完全一樣，有關係嗎
有關係，而且風險不小。結構化資料被要求與頁面可見內容一致，若標記寫了畫面上根本沒有的資訊，可能被判定為誤導而失去豐富結果資格。我們的原則是標記只描述頁面上真實存在、使用者看得到的內容。
5.6 六種以外的類型我需要學嗎
看你的業務。多數商業網站用這六種就能涵蓋常見情境。若你的內容有明確場景，例如活動、食譜、影音、評論，再依需求補上對應類型即可。與其貪多，我們更在意這幾種有沒有寫對、驗證有沒有過。
5.7 外掛自動產生的結構化資料，我可以完全信任嗎
不能照單全收。外掛能省很多事，但它是依你填的欄位和它的預設邏輯輸出，填得不完整、或跟佈景主題重複輸出，都會出問題。我們的做法是外掛照用，但上線前一定親自把幾個代表性頁面丟進驗證工具看實際結果，確認欄位齊全、沒有同類型撞車。工具幫你產生，不代表你可以不檢查。
5.8 結構化資料要多久檢查一次才合理
沒有標準頻率，但可以綁在既有的節奏上。我們給客戶的建議是：每次網站改版、換佈景主題、換 SEO 外掛或大版本更新後，一定要重驗一次，因為這些動作最容易把原本好好的標記弄壞。平時則維持每季抽查一輪重要頁面就夠了，不需要天天盯。另外，搜尋引擎的結構化資料規範本身偶爾會調整，某些欄位從建議變成必要、或某類豐富結果改了顯示條件，所以每年找一個時間點對照最新規範複查一遍，也能避免用著過時的寫法還不自知。把檢查排進固定的維運行程，比想到才做更不容易漏。
5.9 小網站沒有工程資源，結構化資料值得做嗎
值得，而且小網站更該挑重點做。資源有限時不必全站鋪滿，先把投報率最高的兩塊補上：首頁的 Organization 基礎標記，讓搜尋引擎把品牌當成一個清楚的實體；還有最想被搜尋的那幾頁，文章就補 Article、服務或商品就補對應類型。這兩塊用外掛或現成工具大多能處理，不太需要動到程式。我們看過不少只有幾十頁的小站，光是把首頁品牌標記和幾篇主力文章的標記補齊驗好，就在搜尋結果的呈現上明顯比同業完整。關鍵不在做得多，而在把少數真正重要的頁面做對、做到驗證通過。