結構化資料是什麼？Schema.org 標準的起源與設計邏輯
結構化資料是一種標準化的程式碼格式，讓網站擁有者能以搜尋引擎可直接讀取的語言，明確描述頁面內容的類型與屬性。Google 官方的定義是：「一種標準化格式，作用是提供網頁相關資訊並將網頁內容分類。」這個定義刻意簡潔，但背後隱含的邏輯更值得理解：結構化資料的核心目的，是消除自然語言的歧義性。
2011 年，Google、Bing、Yahoo 和 Yandex 四大搜尋引擎聯合創立了 Schema.org，動機直接：各搜尋引擎在獨立發展自己的語意標記系統，造成網站開發者的實作成本極高。Schema.org 的誕生統一了詞彙表，讓「Product」「Article」「LocalBusiness」這些類型在四個搜尋引擎中代表相同的語意意義。目前 Schema.org 官方類型清單收錄 797 個以上的類型，覆蓋從食譜到金融產品的幾乎所有內容領域。
全球有 36% 的網站已部署某種形式的 Schema 標記。換個角度看，這個數字：64% 的網站仍在使用純 HTML，在搜尋引擎眼中，這些頁面的內容分類完全依賴演算法推斷，而非明確宣告。這就是結構化資料的競爭機會所在。結構化資料與 Google 演算法對排名信號的評估邏輯密切相關，理解兩者的互動關係，是制定 Schema 策略的基礎。
語意理解的缺口：為什麼純文字不夠
搜尋引擎從關鍵字比對進化到語意理解，但這個進化並不完美。「Apple」是水果還是科技公司？「Java」是程式語言還是島嶼？搜尋引擎依靠上下文推斷，但推斷本身有成本。Schema 標記的作用是把推斷變成宣告：開發者直接告訴 Google「這個頁面是 Article 類型，作者是 Marcus Fang，發布日期是 2026-04-12」，省去 Googlebot 解析 HTML 文字的中間步驟。 與 Schema 同樣常被歸類為「AI 信號」的 llms.txt，實際採用率與爭議可看 llms.txt 的真實採用率與決策框架。
從搜尋引擎的計算角度，結構化資料是一種預處理信號。Googlebot 爬取頁面時，JSON-LD 標記可以在毫秒內被解析，而理解 5,000 字的正文需要更多的語意計算資源。在爬取預算有限的網站上，這個效率差異實際存在。
Schema.org 的知識圖譜架構
Schema.org 的設計遵循繼承邏輯：所有類型都繼承自 Thing，往下衍生出 CreativeWork、Organization、Person、Event 等一級子類型，再往下細分為 Article、NewsArticle、BlogPosting 等具體類型。這個架構意味著，如果你標記了 Article，你同時繼承了 CreativeWork 和 Thing 的所有屬性。台灣市場最常被使用且有實際 rich results 觸發效益的類型，集中在六個領域：Article、FAQ、Product、Review、LocalBusiness 和 BreadcrumbList。
JSON-LD、Microdata、RDFa：三種格式的戰略選擇
Google 官方明確推薦 JSON-LD，理由是維護成本最低、與 HTML 結構解耦、CMS 整合最簡單。這個推薦不是偏好，而是基於工程現實：JSON-LD 以 <script type="application/ld+json"> 標籤插入頁面，內容與可見 HTML 完全分離，不需要修改頁面結構。Google 搜尋中心的官方文件明確說明這一點。
| 格式 | 與 HTML 耦合度 | 維護成本 | CMS 相容性 | 除錯難度 | Google 推薦度 |
|---|---|---|---|---|---|
| JSON-LD | 低（完全分離） | 低 | 優（可放 head 或 body） | 低 | 優先推薦 |
| Microdata | 高（嵌入 HTML 屬性） | 高 | 中（需修改模板） | 中 | 支援但不推薦 |
| RDFa | 高（嵌入 HTML 屬性） | 高 | 低 | 高 | 支援但不推薦 |
Microdata 在新站沒有選用的理由。但舊站遷移時可能遇到 Microdata 已深度嵌入模板的情況，此時不需要強制轉換，Google 同樣能讀取，優先確保標記的語意正確性，再考慮格式轉移的長期計畫。RDFa 的使用場景更侷限，主要出現在連結開放資料（Linked Open Data）的學術或政府專案。
JSON-LD 實際語法結構解析
JSON-LD 的最小可用結構包含三個必要欄位：@context（宣告詞彙表來源）、@type（宣告內容類型）、以及類型所要求的必填屬性。以下是一個符合 Google 規範的 Article + BreadcrumbList 雙類型示範：
<script type="application/ld+json">
[
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "結構化資料 Schema 是什麼？SEO 效益、JSON-LD 實作解析",
"author": {
"@type": "Person",
"name": "Marcus Fang"
},
"datePublished": "2026-04-12T08:00:00+08:00",
"dateModified": "2026-04-12T08:00:00+08:00",
"publisher": {
"@type": "Organization",
"name": "SmartLink 搜尋智匯"
}
},
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "首頁",
"item": "https://smart-link.com.tw"
},
{
"@type": "ListItem",
"position": 2,
"name": "結構化資料 Schema 是什麼？",
"item": "https://smart-link.com.tw/reports/structured-data-seo"
}
]
}
]
</script>同一頁面可以放多個 JSON-LD 區塊，也可以用陣列 [ ] 合併。Google 兩種方式都支援，但維護上分開比較清楚，每個類型一個 <script> 區塊。
什麼情況下不要依賴 JSON-LD
JavaScript 延遲渲染是一個實際的陷阱。如果 JSON-LD 由前端 JavaScript 動態注入（SPA 架構或依賴框架渲染），Googlebot 在第一次爬取時可能讀到空的 DOM，schema 完全失效。Google 雖然有 JavaScript 渲染佇列，但渲染時間不確定，且有爬取預算限制。解決方案是在伺服器端渲染 JSON-LD（SSR），或確保它直接存在於 HTML 原始碼中，不依賴 JavaScript 執行。
Rich Results 的實際效益：哪些 Schema 類型真正有用
rich results（複合式搜尋結果）是結構化資料最直接的 SEO 回報。根據多項研究，具備 rich results 的頁面平均 CTR 提升約 20-30%，但這個數字會因 Schema 類型和查詢意圖而有顯著差異。重要的是：Google 不保證設定了某個 Schema 就會出現對應的 rich result，觸發與否取決於頁面品質、查詢意圖匹配度，以及 Google 對該內容格式的信任度。
六大高效益 Schema 類型（台灣市場實測）
| Schema 類型 | Rich Result 樣式 | 觸發條件 | CTR 影響估算 | 台灣常見應用 |
|---|---|---|---|---|
| Product | 評分星級、價格、庫存狀態 | 包含 name + offers + review | +15-30% | 電商商品頁 |
| FAQ | 可展開的問答列表（現限 2 則） | FAQPage + Question + Answer | +5-15%（展開空間增加） | 服務說明頁、教學文章 |
| Article | 發布日期、作者、縮圖（Top Stories） | headline + author + datePublished | +10-20%（依查詢意圖） | 新聞、部落格文章 |
| Review | 評分星級（聚合評論） | AggregateRating + ratingValue | +10-25% | 在地商家、產品評測 |
| LocalBusiness | 地圖卡片、營業時間、評分 | name + address + telephone | +20-40%（品牌查詢） | 在地服務業、餐廳 |
| BreadcrumbList | SERP URL 改為麵包屑路徑 | itemListElement + position | +5-10%（信任感提升） | 所有多層架構網站 |
從數字看，Product schema 的 CTR 效益最顯著，但這不代表電商以外的站點就該忽略結構化資料。對於內容站，Article + BreadcrumbList 的組合是最低成本、最穩定的基礎配置，不管頁面有沒有觸發特殊 rich result，至少確保搜尋引擎對頁面類型和層級結構的理解是準確的。
已廢棄或限制的 Schema 類型（2022-2025 清單）
Google 對 Schema 支援類型的調整比多數人意識到的更頻繁。使用已廢棄類型不會直接受到懲罰，但 Google 會靜默忽略這些標記，產生「設定了但沒有效果」的無效工作。以下是近幾年的主要廢棄節點：
- FAQ rich results 限制（2023 年 8 月）：每頁最多顯示 2 個問答，且只在特定網站（政府、醫療）完整支援。內容站的 FAQ schema 仍然有效，但在傳統 SERP 中的展示空間大幅縮減。
- HowTo rich results 限制（2023 年 9 月）：桌面版停止顯示 HowTo rich results，僅保留行動版。對大多數台灣 B2B 網站來說，這意味著 HowTo schema 在主要流量來源（桌面）上已無直接效益。
- SitelinksSearchbox 廢棄（2024 年 12 月）：Google 停止支援 SitelinksSearchbox schema，改為自動觸發站内搜尋功能。舊有標記應清除，避免 Search Console 出現無效警告。
- Data Highlighter 廢棄（2023 年）：Google Search Console 中的 Data Highlighter 工具已下線，使用它設定的 schema 標記失效，需改用手動 JSON-LD。
廢棄類型的清理優先順序：先處理 Search Console 標記為「錯誤」的類型，再處理靜默忽略的類型。HowTo 桌面廢棄後留在程式碼中不會造成問題，但清理後 Search Console 的豐富搜尋結果報告會更清晰。
實作流程：從手動到工具到 CMS Plugin
結構化資料的實作有三條路線，按技術能力和資源分配選擇。關鍵判斷不在於「哪個最好」，而在於「哪個對你的團隊最可持續」：一個被維護的簡單 schema，比一個複雜但被遺棄的 schema 更有價值。
路線一：手動撰寫 JSON-LD（技術路線）
- 確認目標 Schema 類型：根據頁面內容查閱 Google 搜尋中心的支援類型清單，確認目標 rich result 類型（不是 Schema.org 支援，而是 Google 支援）。
- 撰寫 JSON-LD：按 Google 的欄位要求填寫必填屬性（required）和建議屬性（recommended）。只填必填欄位可以通過驗證，但建議屬性影響 rich result 的觸發機率。
- 用 Rich Results Test 驗證：將頁面 URL 或 HTML 程式碼貼入 Google Rich Results Test，確認「此頁面可以顯示複合式搜尋結果」。注意：這個工具只測試 Google 支援的 rich result 類型，不是全部 Schema.org 類型。
- 部署並在 Search Console 確認：部署後 2-4 週，在 Google Search Console 的「豐富搜尋結果」報告中確認頁面出現，無錯誤。
路線二：工具輔助（中階路線）
Merkle Schema Markup Generator 是最完整的免費工具，支援 20+ 種 Schema 類型，輸出乾淨的 JSON-LD。操作流程是選擇類型、填入表單欄位、複製輸出程式碼，然後貼入頁面的 <head> 或 <body> 末端。Google 的 Structured Data Markup Helper 同樣免費，但功能更簡單，適合初次接觸的用戶。
AI 輔助生成 JSON-LD 在 2025-2026 年已相當普及。用 ChatGPT 或 Claude 生成 JSON-LD 的正確做法是：提供具體頁面內容 + 目標 Schema 類型 + Google 支援欄位清單，然後把 AI 輸出的結果一定要先過 Rich Results Test 驗證，不能直接上線。AI 生成的常見錯誤包括：使用 Schema.org 有但 Google 不支援的類型，以及 @type 混淆（例如把 NewsArticle 用在明顯不符合新聞格式的內容上）。
路線三：CMS Plugin（WordPress + 其他）
| Plugin | 自動生成範圍 | 手動覆蓋支援 | 類型數量 | 適合對象 |
|---|---|---|---|---|
| Yoast SEO（免費版） | Article、BreadcrumbList、WebSite | 有限 | ~8 種 | 部落格、內容站 |
| Rank Math | Article、FAQ、Product、LocalBusiness 等 | 強（Schema Builder） | ~20 種 | 多類型網站 |
| Schema Pro（付費） | 全類型自動映射 | 完整 | ~35 種 | 進階電商、服務業 |
CMS Plugin 的常見陷阱是「自動生成 + 手動設定衝突」：Plugin 已自動輸出 Article schema，而開發者再手動加入一個 Article schema，頁面上出現兩個相同類型但內容不同的標記。Google 遇到衝突時行為不確定，有時取第一個，有時兩個都忽略。解決方式是確認 Plugin 設定頁面，關閉自動輸出的類型，再手動管理。
結構化資料在 AI 搜尋時代的新角色
這是目前市場上討論最不足的角度。AI 搜尋平台（包括 Google AI Overviews、Perplexity、ChatGPT Search）在選擇引用來源時，結構化資料的角色比傳統 SERP 更為關鍵，原因在於語意分類效率。AI 系統在處理大規模文件時，需要快速判斷頁面類型和內容結構，Schema 標記提供了這個判斷所需的元資料，無需解析全文。
從 GEO 生成式引擎優化的引用策略角度來看，結構化資料是 AI 引用機制的技術底層之一。GEO 的核心邏輯是讓內容成為 AI 可以快速理解和引用的格式，而 Schema 的 @type 宣告正是這個「快速理解」的起點。一個標記了 Article + author + datePublished 的頁面，在 AI 的文件分類中，其 E-E-A-T 信號的可讀性遠高於同等品質但無標記的頁面。
關於 AI 搜尋如何理解網頁內容的技術機制，有一點值得關注：AI 系統不是僅依賴 schema，但 schema 降低了 AI 對頁面「猜測」的依賴，提高了被正確分類、進而被引用的機率。這個邏輯在數據上有間接支撐：SE Ranking 的研究顯示，Google AI Overviews 引用的頁面中，具備清晰語意結構的頁面比例高於平均，而結構化資料是「清晰語意結構」的一個可量化指標。
Schema FAQ 在 AI Overview 問答框的觸發機制
FAQ schema 在傳統搜尋的功能是觸發 PAA（People Also Ask）顯示，在 AI Overviews 中則有另一個用途：它明確告訴 AI 系統「這個頁面已將問題和答案結構化」，使頁面成為問答型查詢的優先候選來源。這個機制與 GEO 中的 Fraggle 邏輯高度重疊，FAQ schema 本質上是在宣告「每個 Q&A 是可獨立引用的語意片段」。
2023 年 Google 限制 FAQ rich results 展示後，部分 SEO 從業者認為 FAQ schema 已無效益。這個判斷只在傳統 SERP 的維度成立。在 AI Overviews 的語境下，FAQ schema 仍然是問答型查詢的語意分類信號，廢棄 FAQ schema 等於主動降低在 AI 搜尋環境中的可引用性。
結構化資料作為 AI 可理解性信號
Article schema 中的 author、datePublished、publisher 欄位，在 AI 搜尋中的作用是 E-E-A-T 信號的機器可讀版本。AI 系統在評估資訊可信度時，這些欄位提供了快速判斷的依據：有署名作者、有明確發布日期的文章，在 AI 的信任評分上優於匿名、無時效標記的頁面。台灣媒體和部落格常見的問題是「文章有作者，但沒有 schema 標記」，這等於把信任信號隱藏在 HTML 文字中，而不是以 AI 可直接讀取的格式宣告。
Google 為何忽略你已設定的 Schema？疑難排解邏輯
「工具測試通過但就是沒有 rich results」是最常見的 schema 投訴。理解這個問題需要區分兩個層次：技術層（schema 語法是否正確）和信任層（Google 是否相信這個標記）。技術層可以用工具驗證，內容一致性則是信任層的核心，也是工具無法自動檢查的面向。
五大原因導致 Schema 被 Google 忽略
- 標記內容與頁面可見內容不一致：這是最常見原因，也是 Google 最嚴格的判斷標準。如果 Product schema 標記的價格是 NT$1,000，但頁面上顯示的是 NT$1,500，Google 視為 spam 信號。Review schema 中的評分必須是頁面上可見的真實用戶評論，不能是「標記層宣告 4.8 星，但頁面上沒有評論區」的情況。
- 頁面整體品質不足：結構化資料不能提升品質差的頁面。Google 的 rich results 觸發是「品質門檻 + 技術正確」的雙重條件，缺少後者等於 schema 白設。
- Schema 類型不在 Google 支援清單中：Schema.org 支援的類型遠多於 Google 選擇在 SERP 中渲染的類型。
SoftwareApplication、Course、ClaimReview等類型 Google 支援，但觸發率低且區域差異大。設定這些類型不會有負面影響，但期待值要降低。 - JavaScript 延遲渲染導致空 DOM：如上文提及，SPA 架構或依賴 JS 框架的動態注入，可能讓 Googlebot 讀到空頁面。解決方法是 SSR 或直接在 HTML 原始碼嵌入。
- 已廢棄類型仍在使用：Google 對廢棄類型採取「靜默忽略」策略，不報錯、不懲罰，只是不處理。這會讓 Search Console 的豐富搜尋結果報告出現「未偵測到」的空白狀態，讓維護者誤以為 schema 正常運作。
診斷工作流程（六步驟）
- Rich Results Test：確認語法正確性和 Google 支援的 rich result 類型資格。這一步只排除技術問題，不代表一定會出現 rich result。
- Schema Markup Validator（schema.org/validator）：這個工具與 Rich Results Test 不同，它驗證的是 schema.org 規範而非 Google 支援清單，適合檢查嵌套結構和屬性語意是否正確。
- Google Search Console → 豐富搜尋結果報告：確認頁面是否出現在報告中，錯誤類型是「不符合資格」（品質問題）還是「無效的標記」（語法問題）。這兩種錯誤的修正方向完全不同。Google Search Console 豐富搜尋結果報告的官方文件說明了各錯誤類型的意義。
- 內容一致性審查：對照 schema 標記內容和頁面可見內容，逐欄確認。特別注意價格、評分、日期、作者名稱四個最常出現差異的欄位。
- 頁面品質評估：如果語法無誤、內容一致，但仍無 rich result，問題可能在頁面整體 E-E-A-T 評分。這個問題不是 schema 層面能解決的，需要回到內容品質本身。
- 設定監控警報：在 Search Console 設定豐富搜尋結果的「覆蓋率下降」通知，以及在 GA4 設定相關 rich result 的 CTR 追蹤。Schema 狀態會隨 Google 演算法更新而變化，不是一次設定就永久有效。
常見問題
結構化資料標記一定要加嗎？不加有什麼影響？
不是必須，但代價明確。不加結構化資料的頁面仍然可以被索引和排名，但無法觸發 rich results，意味著在 SERP 中的展示空間固定為標準格式，不能顯示評分星級、FAQ 問答框、麵包屑路徑等附加資訊。在競爭頁面都有 rich results 的情況下，沒有 schema 的頁面在視覺上處於劣勢。對 AI 搜尋而言，缺少語意宣告意味著 AI 必須自行推斷頁面類型，引用準確性降低。
JSON-LD 和 Microdata 哪個比較好？Google 有偏好嗎？
Google 官方明確偏好 JSON-LD，原因是維護成本最低、與 HTML 結構解耦、CMS 整合最容易。Microdata 需要將屬性嵌入 HTML 標籤，頁面結構一旦調整，schema 也需要同步更新，維護成本顯著高於 JSON-LD。RDFa 同理。新站一律選 JSON-LD。舊站有 Microdata 遺留也不需要強制轉換，但長期應規劃遷移。
FAQ 結構化資料還有效嗎？2023 年的限制是什麼？
有效，但使用情境改變了。2023 年 8 月，Google 限制 FAQ rich results 每頁最多顯示 2 個問答，並將完整支援限縮至政府和醫療類網站。傳統 SERP 中 FAQ 的展示空間確實縮減，但 FAQ schema 在 AI Overviews 的引用邏輯中仍然重要：它向 AI 宣告頁面包含結構化問答內容，提高被引用為問答型查詢來源的機率。廢棄 FAQ schema 等於在 AI 搜尋環境中主動降低可引用性，不建議這麼做。
網站已有 Yoast SEO，還需要手動加 Schema 嗎？
Yoast SEO 免費版自動輸出 Article、BreadcrumbList、WebSite 三種基本 schema，對內容站已有基礎覆蓋。但如果頁面需要 FAQ、Product、LocalBusiness 等類型，Yoast 免費版覆蓋不足。此時選項是升級至 Yoast Premium、改用 Rank Math，或手動補充特定類型的 JSON-LD。手動補充時要確認 Plugin 輸出的 schema 和手動 schema 沒有衝突同類型的問題。
結構化資料會直接影響搜尋排名嗎？
Google 官方說法是「不直接影響排名」，結構化資料的作用是觸發 rich results，間接透過 CTR 提升影響排名表現。這個說法在技術層面是正確的，但在實務上有微妙之處：Article schema 的 author 和 datePublished 欄位是 E-E-A-T 的機器可讀版本，Google 雖未明確說這是排名因素，但在 YMYL 領域（健康、金融），Author schema 的有無對排名的影響有觀察到的相關性。直接宣稱 schema 能提升排名是過度解讀，但說完全無關也不精確。
如何確認我的 Schema 設定是否正確？用哪個工具？
用兩個工具做不同層次的驗證：Google Rich Results Test（測試 Google 是否支援且技術正確）和 Google Search Console 豐富搜尋結果報告（監控實際上線後的狀態）。Schema Markup Validator（validator.schema.org）則是獨立的語意正確性驗證，不依賴 Google 的支援清單，適合在部署前做全面語法檢查。三個工具合用，覆蓋技術正確性、Google 相容性、上線後狀態三個維度。
頁面上可以同時使用多個 Schema 類型嗎？
可以，且大多數情況下應該這樣做。Article + BreadcrumbList + FAQPage 在同一頁面完全合法，Google 會分別處理每個類型。注意事項是：同一類型不要出現多次（例如兩個 Article schema 描述同一篇文章），這會導致衝突。如果 CMS Plugin 已自動輸出某類型，確認關閉後再手動補充，避免重複。
Google 不顯示我的複合式搜尋結果，但工具測試顯示正確，怎麼辦？
工具測試正確只代表語法沒問題，不代表 Google 一定會觸發 rich result。最常見的原因是頁面品質不符合 rich result 門檻（E-E-A-T 不足）、查詢意圖不匹配（Google 認為這個 query 不需要 rich result），或標記內容與頁面可見內容有細微不一致。建議步驟：先確認 Search Console 有沒有錯誤，再做內容一致性審查，最後評估頁面整體品質。如果三項都沒問題，可能只是 Google 選擇不對該 query 顯示，這部分無法強制觸發。
結構化資料和 AI Overviews 有關係嗎？
有直接關係，但這個連結在台灣市場討論不多。Schema 的 @type 宣告是 AI 系統對頁面進行語意分類的元資料，FAQ schema 在 AI Overviews 的問答框觸發中有重要角色，Article schema 的 author + datePublished 組合則是 E-E-A-T 信號的 AI 可讀版本。不具備結構化資料的頁面仍然可以出現在 AI Overviews 中，但 AI 系統理解頁面類型需要更多推斷步驟，被正確分類和引用的概率相對低於有完整 schema 的頁面。
如何追蹤結構化資料對 CTR 的實際影響？
在 Google Search Console 中，進入「豐富搜尋結果」報告，可以看到哪些頁面觸發了 rich results 及對應的點擊數和曝光數。與「搜尋結果」報告中同頁面的 CTR 對比，可以測量 rich result 觸發前後的差異。更精確的方式是在 GA4 中建立 Segment，比較「有 rich result 頁面」和「無 rich result 頁面」在相同排名位置的 CTR 差異。Schema 部署後至少等 4-8 週才能得到有統計意義的數據，不要在部署後 2 週內就下結論。
關於 entity 識別在搜尋語意中的角色，本站另有完整的 Entity SEO 知識圖譜 解析，涵蓋 EAV 結構與台灣品牌實體建立路線。