結構化資料與 JSON-LD：實用 SEO 實作指南

結構化資料可以幫助搜尋引擎理解頁面內容。JSON-LD 是目前最常用的實作方式之一，因為它把機器可讀資料和可見 HTML 分離，維護起來更清楚。

結構化資料可以讓頁面具備展示增強搜尋結果的資格，但不保證一定出現富結果。Google 和其他搜尋引擎會根據頁面品質、查詢意圖、資格規則和很多其他訊號決定最終展示方式。

常用參考：

結構化資料有什麼作用

結構化資料為頁面內容提供明確語意。搜尋引擎不只看到文字，還能理解頁面是一篇文章、一個產品、一個軟體應用、一組麵包屑導覽、一個 FAQ 區塊，或其他可識別實體類型。

好的結構化資料應該：

與頁面可見內容一致。
使用最具體且相關的 Schema.org 類型。
包含必需欄位和推薦欄位。
在內容變化後保持準確。
上線前通過驗證。

不要用結構化資料描述使用者看不到的內容。這是常見品質問題，也可能讓標記失去展示資格。

為什麼通常選擇 JSON-LD

結構化資料有多種格式，但 JSON-LD 通常最容易維護。

格式	加入方式	維護成本
JSON-LD	`<script type="application/ld+json">` 程式碼區塊	與 HTML 分離，維護清楚
Microdata	寫在 HTML 元素屬性裡	模板改動時容易損壞
RDFa	寫在 HTML 元素屬性裡	功能強，但複雜度更高

使用 JSON-LD 後，前端 HTML 結構變化時，不必到處修改結構化資料屬性。

JSON-LD 基礎結構

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "結構化資料與 JSON-LD：實用 SEO 實作指南",
  "description": "學習如何安全加入 JSON-LD 結構化資料。",
  "author": {
    "@type": "Person",
    "name": "Sarah Miller"
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16"
}
</script>

核心欄位包括：

@context：通常是 https://schema.org。
@type：Schema.org 類型，例如 Article。
屬性欄位：描述實體的資訊，例如 headline、author、datePublished。

Article 標記

編輯類內容可以使用 Article、BlogPosting 或 NewsArticle。普通部落格文章通常適合 BlogPosting。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "如何安全拆分 PDF",
  "description": "一篇關於擷取和拆分 PDF 頁面的方法指南。",
  "image": "https://example.com/images/pdf-split-guide.png",
  "author": {
    "@type": "Person",
    "name": "Rachel Kim"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Tools",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "datePublished": "2026-07-16",
  "dateModified": "2026-07-16",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/pdf-split-guide"
  }
}
</script>

日期要真實。不要為了讓內容看起來更新，就在沒有實際修改時刷新 dateModified。

BreadcrumbList 標記

麵包屑結構化資料可以幫助搜尋引擎理解頁面層級。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "PDF Split Guide",
      "item": "https://example.com/blog/pdf-split-guide"
    }
  ]
}
</script>

JSON-LD 中的麵包屑路徑應該與使用者能理解的頁面導覽一致。

FAQPage 標記

只有當頁面上真的有可見問答內容時，才加入 FAQPage 標記。不要為了爭取富結果而硬塞虛假的 FAQ。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "結構化資料能保證富結果展示嗎？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "不能。結構化資料可以讓頁面具備資格，但搜尋引擎會決定是否展示增強結果。"
      }
    },
    {
      "@type": "Question",
      "name": "JSON-LD 是否必須匹配頁面可見內容？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "是的。結構化資料應該描述使用者也能在頁面上看到的內容。"
      }
    }
  ]
}
</script>

FAQ 標記不是搶占搜尋結果空間的捷徑。只有當它確實能幫助使用者理解頁面時才使用。

SoftwareApplication 標記

線上工具、Web App 或可下載軟體頁面，可以使用 SoftwareApplication 描述頁面提供的功能。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "SoftwareApplication",
  "name": "PDF Split Tool",
  "applicationCategory": "UtilitiesApplication",
  "operatingSystem": "Web",
  "url": "https://example.com/pdf/split",
  "description": "Split a PDF into selected pages or smaller files in the browser.",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}
</script>

只填寫真實欄位。如果加入評分、評論、價格或平台支援說明，它們必須能被頁面可見內容和真實產品狀態支撐。

多個 JSON-LD 區塊

一個頁面可以包含多個結構化資料實體。例如，一篇部落格文章也可以有麵包屑。

可以使用多個獨立腳本：

<script type="application/ld+json">{ "...Article data..." }</script>
<script type="application/ld+json">{ "...Breadcrumb data..." }</script>

也可以使用陣列：

<script type="application/ld+json">
[
  { "@context": "https://schema.org", "@type": "BlogPosting" },
  { "@context": "https://schema.org", "@type": "BreadcrumbList" }
]
</script>

在模板系統裡，多個獨立腳本通常更容易維護。

驗證流程

上線前建議使用簡單流程：

從頁面同一份元資料生成 JSON-LD。
檢查它是不是合法 JSON。
用富結果測試檢查 URL 或程式碼。
頁面被索引後，在 Search Console 中監控結構化資料報告。
大改設計、路由或 CMS 模板後重新檢查。

驗證通過說明語法和部分資格規則滿足要求，但仍然不保證一定出現富結果。

常見錯誤

標記與可見內容不一致

如果 JSON-LD 裡寫了評論、FAQ、價格或作者資訊，使用者也應該能在頁面上看到或驗證這些資訊。

類型選擇錯誤

不要因為產品富結果看起來吸引人，就把所有工具頁都標成 Product。類型必須匹配頁面實際內容。

虛構評分或評論

評論和評分標記需要真實、可見的評論內容。不要編造聚合評分。

日期不真實

datePublished 和 dateModified 應該反映真實內容生命週期。只有發生有意義修改時才更新修改日期。

URL 無法存取

圖片、Logo、規範頁和頁面 URL 應該使用絕對地址，並且可以被抓取。

多語言頁面不匹配

多語言網站中，每個本地化頁面的結構化資料應使用該頁面語言，並配合頁面裡的 canonical 和 alternate 連結策略。

實作建議

從 CMS 或頁面元資料生成結構化資料，不要每頁手寫。
正確轉義使用者生成內容，保證 JSON 合法。
每類頁面維護一個可重用模板。
測試有代表性的頁面，不要只測首頁。
改路由、Slug、作者資料或圖片生成邏輯後重新驗證。
優先處理錯誤，警告可以作為後續優化項。

發布前清單

發布 JSON-LD 前確認：

標記描述的是頁面可見內容。
Schema.org 類型符合頁面。
必填欄位完整。
URL 是絕對地址且可抓取。
日期、作者、標題和描述與頁面一致。
適用頁面通過富結果測試。
發布後繼續看 Search Console 報告。

結構化資料不是強行取得富結果的技巧，而是讓頁面含義更清楚的方式。當它準確、可維護，並與可見內容一致時，搜尋引擎更容易正確理解頁面。