實用結構化資料指南
JSON-LD Schema 標記實用 SEO 指南
JSON-LD 幫助搜尋引擎理解頁面內容、發布者、在網站中的位置及可用於支援搜尋功能的重要資訊。
有用的目標不是加入所有可找到的 schema 類型,而是準確的結構化資料,與可見頁面相符、驗證無誤且隨內容變更同步更新。
有用的簡短版本
當您能以真實且可見的事實描述頁面時使用 JSON-LD:標題、描述、作者、發布日期、麵包屑、產品細節、影片資料或清楚的問答內容。勿為承諾 Google 不再顯示的功能或標記使用者看不到的內容而加入 schema。
目錄
JSON-LD 的實際作用
JSON-LD 是機器可讀的結構化資料區塊,通常放在頁面 head 或 body 的 script 標籤中,使用 schema.org 詞彙描述實體,搜尋引擎將其視為可見內容的清晰層。
解析器清晰度
意義
它將頁面事實轉換為命名實體與屬性,如 Article、author、datePublished、BreadcrumbList 或 SoftwareApplication。
搜尋功能
資格條件
它能讓頁面符合豐富結果資格,但 Google 仍依品質、政策、查詢及功能可用性決定顯示內容。
網站圖譜
一致性
它為您的 CMS 或 Blazor 應用提供一個結構化位置,重複使用相同的正規 URL、語言、標題、日期、圖片及出版者資料。
非捷徑
限制
它無法修正內容薄弱、假評論、隱藏 FAQ 答案、過期日期或與結構化資料不符的頁面。
依頁面功能選擇 schema
避免垃圾或重複結構化資料的最簡單方法是問頁面目標,並加入最小且準確描述該目標的 schema 集合。
內容
Article / BlogPosting
- 適用於
- 指南、教學、評論、新聞類文章及長篇說明。
- 新增時機
- 頁面有明確標題、作者或出版者、發布日期、修改日期、正規 URL 及圖片。
- 避免時機
- 頁面多為工具介面、產品列表、分類頁或內容薄弱的著陸頁。
導覽
BreadcrumbList
- 適用於
- 幾乎所有首頁以下的頁面。
- 新增時機
- 使用者能理解頁面在網站階層中的位置。
- 避免時機
- 麵包屑路徑與內部連結、正規 URL 或可見導覽不符。
網站身份
WebPage / WebSite / Organization
- 適用於
- 首頁、樞紐頁、關於頁及出版者身份重要的頁面。
- 新增時機
- 您需要一個穩定的實體圖譜,連結頁面、網站、出版者與語言。
- 避免時機
- 您僅為追求舊版網站連結搜尋框顯示而加入 WebSite 標記。
產品或應用程式
Product / SoftwareApplication
- 適用於
- 工具、應用程式、SaaS 頁面、擴充功能、可下載軟體或真實產品頁。
- 新增時機
- 標記時,頁面可見內容應包含名稱、描述、作業系統或分類、價格、優惠及評分。
- 避免時機
- 評分、價格、庫存或評論未在頁面上對使用者可見。
問題
FAQPage
- 適用於
- 可見且真正幫助使用者理解主題的問答區塊。
- 新增時機
- 問答內容對頁面有用,即使 Google 不顯示 FAQ 豐富結果。
- 避免時機
- 您僅為佔用搜尋空間或在多頁重複相同答案而加入通用問答。
媒體
VideoObject / ImageObject
- 適用於
- 含重要嵌入影片、教學影片或可爬行圖片資產的頁面。
- 新增時機
- 媒體為頁面核心,具備標題、描述、縮圖、上傳日期及穩定 URL。
- 避免時機
- 媒體為裝飾性、隱藏、封鎖或與頁面主要目的無關。
防止大多數錯誤的實作清單
優質 JSON-LD 最佳特質是平凡:一致、由可信欄位產生、易於驗證,且頁面變更時不易遺漏。
選擇一個主要頁面實體
判斷頁面主要為文章、產品、應用程式、影片、FAQ、集合或一般網頁,次要 schema 應支援主要實體。
與可見內容相符
所有標記的資訊應在頁面上可見或明確推論:標題、作者、日期、價格、評分、問答、麵包屑及圖片。
使用穩定的 @id 值
為重要實體指定穩定 ID,如正規 URL 加上 #article、#webpage、#organization 或 #faq,有助解析器連結圖形片段。
從共用元資料產生
重複使用產生標題標籤、描述、正規 URL、Open Graph 圖片、語言標籤及最後修改日期的相同來源欄位。
保持日期真實
僅在頁面內容實質變更時更新 dateModified,勿為了看起來較新而自動刷新日期。
讓圖片可被爬蟲抓取
使用絕對圖片 URL、適當尺寸,且不被 robots、驗證或僅延遲載入封鎖的檔案。
提前渲染
在 Blazor 及其他 JavaScript 應用中,建議使用預渲染或伺服器渲染的 JSON-LD,讓爬蟲能在初始 HTML 回應中讀取。
驗證與監控
發布前執行豐富結果測試,檢查 Schema 標記驗證器語法,並在索引後監控 Search Console。
Blazor 頁面的乾淨 JSON-LD 範例
Blazor 最安全的做法是在初始化或預渲染時從頁面元資料建立 schema,序列化一次,並在初始 HTML 中渲染 application/ld+json 腳本供爬蟲讀取。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/en/json-ld-schema-guide/#article",
"headline": "JSON-LD Schema Markup Guide for Practical SEO",
"description": "A practical guide to choosing, generating, and validating structured data.",
"image": "https://example.com/images/json-ld-guide.png",
"datePublished": "2026-03-28T10:00:00+00:00",
"dateModified": "2026-05-31T10:00:00+00:00",
"author": {
"@type": "Organization",
"name": "Example Publisher"
},
"publisher": {
"@type": "Organization",
"name": "Example Publisher",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/en/json-ld-schema-guide/"
}
}
</script>private MarkupString BuildJsonLd(PageMetaData meta)
{
var pageUrl = BuildPageUrl(meta);
var schema = new Dictionary<string, object?>
{
["@context"] = "https://schema.org",
["@type"] = "Article",
["@id"] = $"{pageUrl}#article",
["headline"] = meta.Title,
["description"] = meta.Description,
["url"] = pageUrl,
["datePublished"] = meta.Published?.ToString("O"),
["dateModified"] = meta.Modified?.ToString("O"),
["inLanguage"] = CS.Culture
};
var json = JsonSerializer.Serialize(schema, new JsonSerializerOptions
{
DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
});
return new MarkupString($"<script type=\"application/ld+json\">{json}</script>");
}使用前驗證 JSON-LD
驗證有兩項任務:Schema 標記驗證器檢查詞彙與 JSON-LD 語法是否正確,Google 豐富結果測試檢查頁面是否符合豐富結果資格。
Google 資格認定
豐富結果測試
檢查 Google 是否能讀取頁面及結構化資料是否符合豐富結果資格。
開啟豐富結果測試詞彙
Schema 標記驗證器
檢查 schema.org 結構與 JSON-LD 語法,包括類型、屬性、巢狀實體及錯誤 JSON。
開啟 Schema 標記驗證器發布後
Search Console
Google 處理頁面後,使用 URL 檢查與增強報告發現爬行、索引及結構化資料問題。
閱讀 Google 結構化資料文件常見損害信任的 JSON-LD 錯誤
大多數 schema 問題非複雜技術錯誤,而是標記內容與使用者或爬蟲可驗證的頁面內容不符。
標記隱藏或缺失內容
若使用者看不到答案、評論、優惠、圖片或作者資訊,請勿放入結構化資料,這是失去信任最快的方式。
將 FAQPage 加入所有頁面
FAQ schema 可描述可見問答,但不應在每篇文章複製貼上,僅在問答提升頁面時使用。
衝突重複的腳本
多個 Article 區塊有不同標題、日期或 URL 會讓頁面難以解讀,一個清晰的圖譜勝過三個零散的。
錯誤的正規 URL 或 @id
Schema URL 應與正規頁面、語言 URL 及 hreflang 設定一致,混合語言 URL 會造成重複內容與實體混淆。
假新鮮度
不要因模板編輯、追蹤變更或僅 schema 更新而調整 dateModified,僅在內容實質變更時更新。
僅用戶端延遲渲染
若 JSON-LD 僅在延遲的用戶端渲染後出現,爬蟲可能無法抓取。重要頁面建議使用伺服器渲染或預渲染。
依頁面類型的實用 schema 配方
您很少需要龐大圖譜,這些組合涵蓋大多數小型網站、部落格、工具及評論專案實際發佈的頁面。
指南文章
Article + BreadcrumbList + WebPage
- 使用 Article 標記標題、作者、出版者、圖片、日期及章節名稱。
- 使用 BreadcrumbList 標記可見網站路徑。
- 使用 WebPage 或 @id 參考連結頁面與文章實體。
工具頁面
SoftwareApplication + WebPage + BreadcrumbList
- 僅當頁面介紹真實應用程式或工具時使用 SoftwareApplication。
- 僅在可見時包含作業系統、分類、價格或優惠細節。
- 除非頁面顯示真實評論資料,否則避免使用評論或評分標記。
評論頁面
僅在頁面支援時使用評論/產品標記
- 僅在頁面明確顯示時,標記被評論項目、作者、日期與評分。
- 保持聯盟連結與商業內容透明。
- 在 schema 與可見內容中使用相同評分。
問題頁面
FAQPage 僅用於有用且可見的問答
- 讓每個答案本身都有幫助,而非僅是關鍵字變體。
- 不要將答案隱藏在爬蟲無法存取的封鎖介面後。
- 不要將 FAQ 豐富結果視為主要 SEO 利益。
已檢查來源
本指南參考來源
上述指引基於官方 Google Search Central 與 schema.org 文件,並轉化為實用的 JSON-LD 清單。
常見問題
JSON-LD schema 標記是排名因素嗎?
JSON-LD 本身不是排名魔法開關,它協助搜尋引擎理解合格內容並支持豐富結果資格,但排名仍依內容品質、相關性、可爬行性、連結及其他訊號。
JSON-LD 應放在哪裡?
通常將 script 標籤放在 head 最易管理,但 Google 也能讀取 body 中的 JSON-LD。重點是標記必須出現在渲染後的頁面且與可見內容一致。
我還應該使用 FAQPage schema 嗎?
僅在頁面有真正有用且可見的問答時使用 FAQPage,勿依賴它增加 Google 顯示空間,因 FAQ 豐富結果已大幅減少且多數網站已淘汰。
一頁可以有多個 JSON-LD 區塊嗎?
是的,普通文章頁可包含 Article、BreadcrumbList 與 WebPage 資料。保持區塊一致,避免重複衝突實體,並使用穩定 @id 連結相關部分。
JSON-LD 比 Microdata 更好嗎?
大多數現代網站支援 JSON-LD、Microdata 與 RDFa,但 JSON-LD 較易維護,因為不需在視覺 HTML 模板中加入 schema 屬性。
我應多久驗證一次結構化資料?
每次更改模板、元資料欄位、schema 輔助工具、URL、語言路由、圖片產生、評論資料或 FAQ 區塊時皆驗證,重要頁面索引後也檢查 Search Console。