Schema.org 結構化資料是什麼？完整了解 Structured Data、JSON-LD 與 SEO 應用

Schema.org 結構化資料 (Structured Data) 是網站用來向搜尋引擎清楚說明頁面內容的標準語彙系統,可以把它理解為「寫給機器看的內容說明書」。同樣一篇文章、一個商品、一間公司,使用者看得懂文字,但搜尋引擎需要更明確的欄位與語意提示,才能正確理解頁面內容。在 2026 年的 AI 搜尋時代,當 ChatGPT、Perplexity、Google AI Overviews、Claude 等 AI 引擎逐漸取代部分傳統搜尋,結構化資料的角色也從「爭取 rich results」進化為「讓 AI 引擎正確引用您的內容」。本篇文章適合網站經營者、SEO 從業人員、行銷企劃、企業官網管理者閱讀,完整涵蓋 Schema.org 的定義、與其他名詞的差別、SEO 與 AEO 應用、實作範例、檢查工具與常見錯誤。

什麼是結構化資料 (Structured Data)?

結構化資料的重點,不是把內容「寫更多」,而是把內容「標示更清楚」。同樣一段文字,搜尋引擎未必能立刻分辨哪一段是作者、哪一段是發布日期、哪一段是公司名稱、哪一段是商品價格;但若透過結構化資料標記,搜尋引擎就能更容易判斷這些資訊的角色與彼此的關係。

換句話說,結構化資料的價值在於「讓搜尋引擎更精準理解您的頁面」,而不只是「多塞一段程式碼」。這也是為什麼它常被用在文章、產品、企業資訊、FAQ、麵包屑、在地商家資料等頁面上。

結構化資料的三層概念

很多人會把「Schema.org」「Structured Data」「JSON-LD」當成同一件事,但其實它們屬於不同層次的概念:

Schema.org、Structured Data、JSON-LD、Microdata 的差別

這幾個名詞很常被混用,但其實它們不是同一件事。如果用一個比喻來說明,可以這樣理解:Structured Data 是「想要把書本資訊整理清楚」的這個概念;Schema.org 是「圖書館使用的分類詞彙表」 (定義「書名」「作者」「ISBN」這些欄位);JSON-LD 與 Microdata 則是「實際把這些資訊寫在書背上的方法」。

三種寫法的比較

為什麼 Schema.org 對 SEO 有幫助?

Schema.org 的核心價值,不是神奇加分,而是幫助搜尋引擎更有效理解您的頁面,並讓頁面有機會取得更豐富的搜尋呈現。Google 把這類呈現稱為 rich results (複合式搜尋結果)。例如:

• 產品頁可能顯示價格、庫存、星級評分
• 文章頁可能顯示標題、發布日期、封面圖片
• 商家頁可能顯示地址、電話、營業時間、評論摘要
• FAQ 頁則可能顯示展開式問答型呈現
• 食譜頁可能顯示烹飪時間、卡路里、評分

因為搜尋結果看起來更完整、更醒目,所以結構化資料常被視為提升 CTR (點擊率) 的工具之一。Google 官方文件也列出多個案例,顯示網站在導入結構化資料後,曾觀察到較高的點擊率、互動率或停留表現。

Schema.org 在 AEO 時代的新角色

進入 2026 年,搜尋行為正在發生根本性的變化。AEO (Answer Engine Optimization,答案引擎優化) 取代了部分傳統 SEO 的角色,因為使用者越來越常透過 ChatGPT、Perplexity、Google AI Overviews、Gemini、Claude 等 AI 引擎,直接獲得「答案」而不是「連結列表」。

Schema.org 在 AEO 的三大新功能

• 幫助 AI 引擎正確識別實體 (Entity Recognition) AI 引擎在抓取網頁時,需要快速理解「這個頁面在講誰、講什麼」。如果您透過 Schema 明確標記 Organization、Person、Product 等實體資訊,AI 引擎就更容易把您的內容與相關搜尋意圖配對。
  使用者問 ChatGPT「台中有哪些網頁設計公司」,若您的網站有完整的 LocalBusiness Schema (含地址、營業時間、服務範圍),被引用的機率會明顯高於只用純文字描述的競爭對手。
• 建立內容的權威性訊號 (Authority Signal) AI 引擎需要判斷答案來源是否可信。透過 Schema 標記作者 (author)、發布者 (publisher)、發布日期 (datePublished)、修改日期 (dateModified) 等資訊,等於告訴 AI:這篇內容有明確的作者與時間戳記,可信度較高。
  同樣是討論「2026 SEO 趨勢」的兩篇文章,有完整 Article Schema (作者、發布者、日期) 的版本,比沒有 Schema 的純文字頁面,更容易被 Perplexity 列為引用來源。
• 提升 FAQ 與短答內容的引用機率 AI 引擎特別偏好「問題-答案」結構清楚的內容。FAQPage Schema 把您的問答內容結構化,讓 AI 引擎更容易抽取「答案片段」用於回應使用者。
  使用者問「Schema.org 跟 JSON-LD 一樣嗎?」,有 FAQPage Schema 標記的頁面,答案被 Google AI Overviews 直接引用顯示的機率,通常高於只在內文埋藏答案的頁面。

SEO vs AEO 的 Schema 策略差異

Schema.org 會直接影響排名嗎?

以 Google 官方文件來看,結構化資料的重點在於幫助理解內容、提高取得 rich results 的資格,而不是承諾「加了就排名上升」。Google 甚至明確表示:即使您的結構化資料標記正確,也不保證一定會出現在搜尋結果中;是否顯示,仍取決於演算法、搜尋情境、裝置、地點與其他因素。

因此,比較務實的說法是:

至於最終是否帶來更多流量,還是要回到內容品質、頁面主題明確度、網站權威性與整體 SEO 基礎。簡單來說,Schema 是「放大器」,而不是「發電機」——它能放大好內容的效益,但無法把壞內容變好。

常見可使用 Schema.org 的內容類型

Schema.org 可描述的內容非常廣,從文章、組織、產品、人物、地點、評論到事件都能標記。Google Search 結構化資料圖庫 目前列出 30+ 種支援的 structured data 類型。

如果以一般企業官網來看,最常見也最實用的優先順序如下:

• Organization (組織資訊) 適合放在首頁,協助 Google 與 AI 引擎理解公司名稱、Logo、聯絡資訊、社群連結與組織識別資訊。這是建立品牌實體 (Brand Entity) 最基本的一步。
  必要欄位:name (公司名)、url (官網)、logo (Logo 圖片)。建議欄位:sameAs (社群連結)、contactPoint (聯絡方式)、address (地址)。
• Article / BlogPosting (文章內容) 適合文章頁、部落格頁,幫助 Google 理解標題、圖片、日期與作者資訊。BlogPosting 是 Article 的子類型,更貼近部落格內容的語意。
  必要欄位:headline、image、datePublished、author。建議欄位:dateModified、publisher、mainEntityOfPage。
• BreadcrumbList (麵包屑導覽) 適合分類頁、文章頁、產品頁,讓搜尋結果直接呈現頁面階層 (如「首頁 › 部落格 › SEO 教學」),使用者更容易判斷頁面在網站中的位置。
  必要欄位:itemListElement (含 position、name、item)。每個層級都要按順序排列。
• Product / Offer (商品資訊) 適合商品頁,能提供價格、庫存、運送、評分等商品資訊,是電商網站取得 rich results 的關鍵類型。
  必要欄位:name、image、offers (含 price、priceCurrency、availability)。若有評論還可加 aggregateRating、review。
• LocalBusiness (在地商家) 適合有實體服務範圍的店家或公司,可補充營業時間、地址、聯絡方式、地圖座標等資訊。在 Google Maps 與在地搜尋中特別重要。
  必要欄位:name、address、telephone。建議欄位:openingHours、geo (經緯度)、priceRange、image。
• FAQPage (常見問答) 適合真正有問答內容的頁面。在 AEO 時代特別重要,AI 引擎很喜歡從這類結構化內容中抽取答案。但需注意:Google 從 2023 年起,FAQ rich results 只顯示給少數權威網站,但對 AI 引擎引用仍然有效。
  必要欄位:mainEntity (Question 陣列,每題含 name 與 acceptedAnswer)。FAQ 內容必須與頁面實際顯示一致。
• HowTo (操作步驟) 適合教學文章、DIY 步驟、操作指南。在 AEO 時代,使用者問「如何做 X」時,HowTo Schema 能讓 AI 引擎更容易引用您的步驟內容。
  必要欄位:name、step (HowToStep 陣列,每步含 text)。建議欄位:totalTime、tool、supply、image。

Schema.org 與 Open Graph 的關係

Schema.org 不會取代 Open Graph,兩者用途不同,是互補關係。

Schema.org 官方也提到,Schema.org 資料可以和其他類型的結構化資料共同存在於同一頁中。實務上,一個完整的網頁通常會「同時使用」 Schema.org + Open Graph + Twitter Card,各自負責不同平台的呈現。

實作 Schema.org 的正確方式

現在最推薦的做法是使用 JSON-LD。它通常放在 <head> 或頁面中適當位置的 <script type="application/ld+json"> 內,不需要把屬性拆散到每個 HTML 標籤上,維護與除錯都較方便,這也是 Google 官方建議的格式。

實作五大原則

Article 結構化資料範例 (JSON-LD)

下面是一個適合文章頁使用的完整 JSON-LD 範例,涵蓋 SEO 與 AEO 都重要的欄位:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema.org 結構化資料完整指南:Structured Data、JSON-LD、SEO 與 AEO 應用",
  "description": "完整介紹 Schema.org 定義、與 Structured Data / JSON-LD / Microdata 的差別,並涵蓋 SEO 與 2026 AEO 時代的實務應用。",
  "image": [
    "https://www.example.com/images/schema-1x1.jpg",
    "https://www.example.com/images/schema-4x3.jpg",
    "https://www.example.com/images/schema-16x9.jpg"
  ],
  "datePublished": "2026-05-22",
  "dateModified": "2026-05-22",
  "author": {
    "@type": "Person",
    "name": "新視野編輯部",
    "url": "https://www.newscan.com.tw/about/",
    "jobTitle": "資深 SEO 編輯"
  },
  "publisher": {
    "@type": "Organization",
    "name": "新視野網頁設計",
    "logo": {
      "@type": "ImageObject",
      "url": "https://www.newscan.com.tw/images/logo.png",
      "width": 600,
      "height": 60
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.newscan.com.tw/seo/schema-structured-data.htm"
  },
  "articleSection": "SEO 教學",
  "keywords": "Schema.org, 結構化資料, JSON-LD, AEO, SEO"
}
</script>

欄位說明與 AEO 重點

• image:建議提供 1:1、4:3、16:9 三種比例,以符合不同 rich results 版型
• datePublished / dateModified:AEO 時代特別重要,AI 引擎會優先引用較新內容
• author.url + jobTitle:建立作者實體權威,協助 E-E-A-T 訊號
• publisher.logo:必須提供圖片寬高,且寬度建議 ≥ 600px
• articleSection + keywords:幫助 AI 引擎判斷主題分類

搭配 BreadcrumbList 強化頁面位置

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "首頁",
      "item": "https://www.newscan.com.tw/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "SEO 教學",
      "item": "https://www.newscan.com.tw/seo/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Schema.org 結構化資料完整指南"
    }
  ]
}
</script>

如何檢查 Schema 是否正確?

完成標記後,不要只靠肉眼看程式碼,務必用 Google 官方工具或第三方驗證工具檢查語法與資格。

三大官方檢查工具

• Rich Results Test (複合式搜尋結果測試) 驗證頁面可產生哪些 rich results,並指出缺少的必要欄位或語法錯誤。這是最常用的 Schema 檢查工具。
  網址:https://search.google.com/test/rich-results
• URL Inspection (Search Console 網址檢查工具) 檢查 Google 是否能正常抓取與索引頁面,並顯示已偵測到的結構化資料。正式發布後必用。
  需先驗證 Search Console 擁有權,登入後在搜尋框輸入要檢查的網址即可。
• Schema Markup Validator (Schema.org 官方驗證器) 檢查 Schema 語法是否符合 Schema.org 規範 (注意:這不檢查 Google 的特定要求,只檢查 Schema.org 通用語法)。
  網址:https://validator.schema.org/

建議的檢查流程

1. 開發完成後,先用 Schema Markup Validator 檢查語法是否符合 Schema.org 規範
2. 再用 Rich Results Test 檢查是否符合 Google 的 rich results 資格
3. 正式上線後,用 Search Console URL Inspection 確認 Google 確實抓到結構化資料
4. 長期透過 Search Console 的「強化項目」報告監測是否有錯誤或警告

常見錯誤與踩雷

很多網站不是「沒加 Schema」,而是「加了但加錯」。以下是 SEO 顧問實務中最常遇到的六大錯誤:

• 標記內容與頁面實際可見內容不一致 這是最常見也最嚴重的錯誤。例如頁面實際只有 3 個 FAQ,但 Schema 標記了 5 題;或頁面沒有顯示星級評分,Schema 卻標記了評分。改善方式:每次更新內容後,同步更新 Schema,並用 Rich Results Test 重新驗證。
• 缺少必要欄位導致無 rich results 資格 標記了 Schema,但缺少必要欄位 (例如 Article 缺 image、Product 缺 offers、FAQ 缺 acceptedAnswer)。語法雖通過驗證,卻無法取得 rich results。改善方式:對照 Google 官方文件的「必要屬性」清單,逐項補齊。
• 使用不相關或誤導性的類型 把一般介紹文章硬標成 FAQ、Product 或 Event,試圖鑽漏洞取得更多搜尋呈現。這違反 Google 結構化資料準則,可能觸發垃圾內容人工處置。改善方式:選擇最貼近內容實際性質的類型,寧可保守也不要誤導。
• 假評論、假評分被偵測 評論、評分等內容必須是使用者真實提供。憑空生成評分或自行撰寫假評論,可能觸發品質問題甚至人工處置。Google 對此類問題的偵測能力越來越強。改善方式:只標記真實評論;若無評論,就不標 aggregateRating。
• 圖片網址不可抓取或頁面被封鎖 Schema 中的圖片網址必須可公開存取,且頁面本身不能被 robots.txt 或 noindex 擋住。常見問題是測試環境的圖片網址、需登入才能看的圖片。改善方式:上線前測試所有圖片網址都能匿名開啟,並用 URL Inspection 確認頁面可索引。
• 資料已過時但 Schema 未更新 產品已停售、價格已調整、文章已修訂,但 Schema 中的 price、availability、dateModified 仍是舊資料。AI 引擎抓到過時資料時,可能引用錯誤內容傷害品牌信任。改善方式:建立 Schema 維護流程,內容更新時同步更新 Schema 欄位。

結論:Schema.org 不是 SEO 萬靈丹,但是 AEO 時代的必備基礎

Schema.org 結構化資料不是 SEO 的萬靈丹,但它是網站語意化與搜尋呈現優化的重要基礎。它能幫助 Google 與 AI 引擎更清楚理解頁面內容,並讓您的頁面有機會取得更豐富的搜尋結果展示,以及更高的 AI 引用機率。

進入 2026 年的 AEO 時代,Schema 的角色更加關鍵。建議用以下五個問題自我檢查:

• 網站首頁是否已標記 Organization,讓 AI 引擎能識別品牌實體?
• 文章頁是否已標記 Article,並包含 author、publisher、datePublished?
• 是否所有分類頁、內頁都有 BreadcrumbList 強化頁面階層訊號?
• FAQ 內容是否有對應的 FAQPage Schema,且 Schema 與頁面內容完全一致?
• 是否定期用 Rich Results Test 與 Search Console 檢查 Schema 健康度?

常見問答 FAQ