結構化資料怎麼做？JSON-LD 寫法、常用類型與測試工具

假設一家做工業零件的 B2B 公司，官網有兩百個產品頁。規格寫在圖片裡，公司地址只出現在頁尾的 PDF 型錄。有人搜尋公司名稱時，Google 結果只顯示一行標題和一段從導覽列抓來的文字；隔壁同業的結果卻有公司 logo、網站路徑，產品頁還帶著價格和庫存狀態。

兩者的差別，常常出在結構化資料。它不會改變頁面的長相，讀者也看不到，是專門寫給搜尋引擎的說明：這一頁是公司介紹、那一頁是產品，這個數字是價格、那串字是地址。

你可以把網站想成一間倉庫。每個頁面都是外觀差不多的紙箱，揀貨員要開箱才知道裡面裝什麼。結構化資料就是貼在箱子外面的標籤和裝箱單，讓人不用拆開就知道箱子裡有什麼、有幾件。

結構化資料是什麼：寫給搜尋引擎的標籤

依 Google 的說明，結構化資料是一種標準化格式，用來提供網頁的相關資訊，並替網頁內容分類。Google 會用它來理解頁面內容，也用它判斷頁面能不能出現在某些特殊的搜尋結果樣式裡。

標記用的詞彙來自 schema.org。這是 Google、Microsoft、Yahoo、Yandex 共同發起的社群專案，定義了 Organization（組織）、Product（產品）、Article（文章）這些類型，以及每個類型有哪些欄位，所以大家也常直接叫它「Schema 標記」。

搜尋「結構化資料」時，也會看到資料科學講的「結構化 vs 非結構化資料」，那是指資料表和一般文字的差別，和這裡談的網頁標記是兩件事。

Google 支援三種寫法：

JSON-LD：寫在 <script type="application/ld+json"> 裡的一段資料，和畫面上的 HTML 分開放。
Microdata：把屬性直接寫在 HTML 標籤上，和內容交織在一起。
RDFa：HTML5 的擴充屬性，一樣寫在標籤上。

Google 建議只要網站架構允許，就用 JSON-LD，理由是它最容易大規模實作和維護。JSON-LD 和頁面排版分開，改版時比較不會被一起改壞，這也是我會優先選它的原因。

一段 JSON-LD 長什麼樣子

以開頭的零件商為例，首頁可以放一段 Organization 標記（公司名稱與網址都是虛構的）：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "範例精密工業股份有限公司",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "telephone": "+886-4-2345-6789",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "台中市",
    "addressCountry": "TW"
  },
  "sameAs": ["https://www.linkedin.com/company/example"]
}
</script>

@type 說明這是一個組織，name、url、logo、telephone、address 分別是名稱、網址、標誌、電話和地址，sameAs 列出這家公司在其他平台的官方頁面。Google 的 Organization 文件說，這類標記可以幫它理解組織的基本資料，並在搜尋結果裡區分同名的公司；它沒有必填欄位，建議放在首頁或「關於我們」這類介紹公司的頁面。

寫的時候有一個原則：JSON-LD 裡的每一欄，頁面上都要找得到。標記寫了電話，頁尾就要有同一支電話；標記寫了地址，聯絡頁就要有這個地址。公司名稱在標記、頁尾、關於我們各寫一種版本，是很常見的問題，可以用品牌實體一致性檢查先把名稱統一。

中小企業先做哪幾種

Google 的搜尋結果庫列出目前支援的類型，例如食譜、活動、職缺都有，中小企業官網常用的是這幾種：

類型	放在哪裡	可能帶來的呈現	要注意
Organization	首頁或關於我們	搜尋結果裡的 logo、知識面板的公司資料	沒有必填欄位，填和公司有關的就好
BreadcrumbList	所有內頁	在結果裡顯示頁面在網站中的路徑	目前只在桌機搜尋結果顯示
Product	產品頁	價格、庫存、評分、運費	可直接購買的頁面用商家資訊（merchant listings），只介紹產品的頁面用產品摘要（product snippets）
Article	部落格、新聞	較完整的標題、圖片與日期	作者與日期要和頁面一致
LocalBusiness	有門市或服務據點的頁面	知識面板裡的營業資訊	必填名稱與地址

以零件商來說，我建議的順序是：首頁先做 Organization，全站加 BreadcrumbList；產品頁若有公開價格或可以線上下單，再加 Product；有在經營技術文章的話，文章頁加 Article。Article 的欄位細節，可以看 Article schema 對 AI Search 有什麼用。

選類型時，以 Google 搜尋結果庫當下列出的為準，網路上的舊教學常常還在推已經不顯示的類型。

Google 近年收掉了哪些複合式搜尋結果

複合式搜尋結果（rich results）就是帶有星等、價格、路徑這類額外資訊的搜尋結果。這兩年 Google 一直在精簡它們：

2025 年 6 月：宣布逐步淘汰 Book Actions、Course Info、Claim Review、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing 七種。Google 說這項調整不影響排名，這些標記在 Google 搜尋以外的用途也不受影響。
2025 年 11 月：再宣布淘汰一批使用率低的功能，並從 2026 年 1 月起在 Search Console 與 API 中移除這些類型的支援。
2026 年 5 月：FAQ 複合式結果不再顯示，6 月相關文件也被移除。舊網站若加過 FAQ 標記，處理方式可以看 FAQ schema 還能幫助 AI Search 嗎。

已經不顯示的類型，我建議等下次改版時再評估要不要保留，不必急著全站拔除。

標記要和可見內容一致

Google 的一般規範有幾條，每一條都和「頁面上實際有什麼」有關：

讀者看不到的內容不要標記。Google 的例子是：JSON-LD 描述了一位表演者，HTML 正文就要介紹同一位表演者。
標記要代表這頁的主要內容，類型不能選錯。
想取得某種複合式結果，那個類型的必填欄位要填齊。
不能用標記誤導，例如假評論或冒用他人身分。

用零件商的情境來看，最常踩到的是這兩種：產品頁寫著「請來電詢價」，JSON-LD 卻放了一個價格；或是頁面上沒有任何客戶評價，標記裡卻有五顆星。標記只能描述頁面上已經寫出來的東西。

違反規範可能收到手動處置。依 Google 的說明，結構化資料的手動處置會讓頁面失去複合式結果的資格，一般網頁搜尋的排名則不受這項處置影響。即使標記完全正確，Google 也不保證一定顯示複合式結果，顯示與否由 Google 依查詢決定。

做完怎麼測：四個工具各看什麼

測試分成兩個階段：上線前逐頁測，上線後看全站報表。

工具	檢查什麼	什麼時候用
Rich Results Test（複合式搜尋結果測試）	頁面上的標記能產生哪些 Google 複合式結果、有沒有錯誤	上線前、改版後逐頁測
Schema Markup Validator	所有 schema.org 標記的語法，不帶 Google 專屬的警告	用了 Google 沒有對應顯示樣式的類型時，確認語法
Search Console 複合式結果報表	全站有效與無效的項目數、問題類型，修正後可以要求驗證	上線後定期看
Search Console 網址檢查	Google 實際抓到的頁面版本裡有沒有標記	標記由 JavaScript 產生時

檢貨台上打開的紙箱，內容物一一排開，旁邊放著裝箱單與手持掃描器 測試就像檢貨：裝箱單寫的東西，要和箱子裡實際放的一件一件對得上。

Rich Results Test 顯示「符合複合式搜尋結果資格」，意思是這頁有資格，顯示與否仍由 Google 決定。Search Console 的報表也只在 Google 找到支援類型的有效標記後才會出現，新網站一開始看不到報表很正常。

標記用 JavaScript 產生時，Google 能讀取渲染後 DOM 裡的結構化資料，但它提醒電商網站：動態產生的標記可能讓 Shopping 抓取變得較不頻繁、較不穩定，價格和庫存常變動的頁面要特別注意。其他爬蟲不一定會執行 JavaScript，渲染的影響可以看 JavaScript 渲染與 AI 搜尋。

結構化資料對 AI 搜尋有什麼用

Google 的生成式 AI 搜尋指南說得很直接：生成式 AI 搜尋不需要結構化資料，也沒有需要另外加的 schema.org 標記；但它仍建議把結構化資料當成整體 SEO 的一部分繼續使用，因為它有助於取得複合式結果的資格。AI Overviews 與 AI Mode 需要的基礎條件，整理在 Google AI Overviews 與 AI Mode SEO 基礎。

ChatGPT、Perplexity、Claude 這些 AI 服務，目前都沒有公開文件說明它們怎麼使用 schema 標記。

所以我的看法是：結構化資料的價值在於讓 Google 少猜一點，AI 回答真正引用的，仍是頁面上寫清楚的內容。例如公司名稱、產品規格、服務範圍如果只存在圖片或 PDF 裡，JSON-LD 寫得再完整，讀者和 AI 能引用的文字還是很少。先把正文寫清楚，再用標記補上機器可讀的線索，順序比較對。

頁面內容要怎麼讓人信任，可以看 E-E-A-T 是什麼；作者、日期這些欄位怎麼和頁面對齊，則在 AI 搜尋頁面如何做 source attribution。

導入的五個步驟

盤點頁型：列出網站有哪幾種頁面，例如首頁、產品頁、文章頁、門市頁，每一種各挑一頁當範本。
對照支援的類型：到 Google 搜尋結果庫確認每種頁型對應的類型與必填欄位。
寫進模板：用 JSON-LD 寫在頁面模板裡，讓欄位直接讀頁面上的同一筆資料，避免手動維護兩份。
上線前測試：每種頁型用 Rich Results Test 各測幾頁，沒有對應顯示樣式的類型再用 Schema Markup Validator 檢查語法。
上線後追蹤：定期看 Search Console 報表，改版或換網站平台時重測一次。

第三步最關鍵。標記的值直接取自頁面上顯示的資料，價格改了、電話換了，標記會跟著變，自然就和可見內容一致。

我們能協助的部分

我們的官網與電商開發在網站建置時就把結構化資料內建在模板裡。已經上線的網站，GEO 服務的網站診斷會檢查讀取權限、文字內容與相關設定，並處理確認過的技術問題；內容編修與網站實作可以由我們協助，也可以與你的團隊分工，範圍在合作前確認。

常見問題

用 WordPress 或 Shopify 架站，還需要自己寫 JSON-LD 嗎？

很多網站平台和 SEO 外掛會自動輸出基本的 Organization、Article、Product 標記。要檢查的是輸出的內容和頁面一致，以及有沒有外掛和佈景主題各輸出一套、內容互相矛盾的情況。用 Rich Results Test 測一頁就能看出來。

一個頁面可以放好幾種結構化資料嗎？

可以。產品頁同時放 Product 和 BreadcrumbList 很常見。原則是每一種都描述這一頁上真的有的東西，同一個產品只用一套標記描述。

Rich Results Test 顯示有效，搜尋結果卻沒出現，是哪裡出了問題？

有效代表這頁有資格，顯示與否由 Google 依查詢和其他條件決定；也可能是 Google 還沒重新抓取這一頁。可以在 Search Console 用網址檢查確認 Google 目前抓到的版本，再觀察複合式結果報表的有效項目數。

結構化資料要多久更新一次？

跟著頁面內容更新。價格、庫存、營業時間、電話這類會變的資訊，標記最好直接讀頁面上的同一筆資料；改版、換平台或改網址時，再用測試工具把每種頁型重測一次。

參考來源

以下依官方文件整理，支援的類型以 Google 搜尋結果庫當下為準。

結構化資料是什麼？Schema、JSON-LD 對 Google 與 AI 搜尋的實際用途