Schema結構化數據怎麼生成？完整指南

Schema 結構化數據，是用統一格式説明網頁事實的一段代碼。它會把頁面中的標題、作者、日期、價格、地址等資訊，整理成搜尋系統更容易讀取的字段。

很多人第一次製作 Schema 時，會直接打開生成器、選擇模板、填寫內容，然後複製代碼。這樣雖然能得到一段代碼，卻沒有解決三個更重要的問題：

1. 當前頁面應該使用哪一種 Schema 類型？
2. 代碼中的字段是否與頁面實際展示的內容一致？
3. 代碼發佈以後，搜尋系統能否從線上頁面正常讀取？

只要其中一項沒有處理好，即使代碼通過語法檢查，也可能無法正常發揮作用。

先給出一套簡單的選擇方法：

• 只有少量固定頁面，可以使用在線生成器。
• 文章頁、產品頁、門店頁等同類頁面會持續增加，可以使用 CMS（網站內容管理系統）插件或頁面模板自動生成。
• 需要處理電商、知識庫、門店庫或多語言網站中的大量頁面，可以使用代碼批量生成。
• 無論採用哪種方式，都要依次完成 Schema 語法、目標搜尋功能和正式線上頁面三次校驗。

生成工具可以幫助你整理字段並輸出代碼，但不能替你核對頁面事實、選擇合適的類型，也不能保證頁面獲得富結果、排名提升或被人工智能生成的答案引用。

這裏所説的“富結果”，是搜尋結果中帶有圖片、價格、評分等附加資訊的增強展示。

Schema到底是什麼？

普通網頁主要負責把內容展示給讀者，結構化數據則負責把同一批事實重新整理，供搜尋系統等機器讀取。

例如，一篇文章可能包含標題、作者、發佈日期、更新時間、頭圖和正文。結構化數據可以把這些資訊整理成一個 Article，也就是“文章”類型。

不同頁面通常會使用不同類型：

• 企業主頁可以使用 Organization，表示企業或組織。
• 本地門店頁面可以使用 LocalBusiness，表示本地經營場所。
• 產品詳情頁可以使用 Product，表示具體產品。
• 文章頁面可以使用 Article，表示文章內容。

這些類型和字段來自 Schema.org。Schema.org 是用於查詢 Schema 類型、屬性及其定義的網站。

需要特別注意：Schema.org 收錄的類型和屬性很多，但搜尋引擎只會為其中一部分提供富結果。Schema.org 中存在某個類型，並不代表搜尋引擎一定支持相應的增強展示。

生成器實際做了什麼？

一款 Schema 生成器通常完成三件事：

1. 選擇要描述的頁面類型。
2. 把頁面資訊填入相應字段。
3. 輸出 JSON-LD、Microdata 或 RDFa 格式的代碼。

JSON-LD 是一種常用的結構化數據代碼格式，通常集中放在網頁的一段獨立腳本中。

Microdata 和 RDFa 是另外兩種結構化數據格式，它們會把相關屬性直接寫進 HTML 標籤。HTML 是用於組織網頁內容和結構的標記代碼。

三種格式都可以表達結構化數據。區別主要在於代碼寫在哪裏，以及後續如何維護。

為什麼多數網站會優先選擇JSON-LD？

JSON-LD 通常放在下面這樣的 HTML 腳本區塊中：

<script type="application/ld+json">
</script>

它不需要把結構化屬性逐項寫進正文標籤，因此頁面內容和結構化數據可以分別維護。一個頁面中存在多個描述主體時，JSON-LD 也更方便表達它們之間的關係。

Google 搜尋支持 JSON-LD、Microdata 和 RDFa。在網站條件允許的情況下，Google 官方通常建議使用更容易實施和維護的 JSON-LD。它便於統一生成，也較少因為頁面模板調整而出現手工修改錯誤。

但這並不意味着 Microdata 和 RDFa 不合格。只要代碼有效，並且符合對應搜尋功能的要求，兩種格式同樣可以使用。

選擇格式時，應考慮網站的實際情況：

• 新網站的頁面模板統一，開發人員也能維護字段對應關係，可以優先使用 JSON-LD。
• 舊網站已經穩定使用 Microdata 或 RDFa，而且沒有事實錯誤和功能缺失，就沒有必要只為更換格式而重做全站。

格式只是資訊的表達方式。真正需要長期維護的，是頁面內容與結構化數據之間的同步關係。

生成代碼前，先整理頁面事實

不要等到打開生成器以後，才臨時從頁面上尋找內容。更穩妥的做法，是先建立字段清單，確認每個值是什麼、來自哪裏、由誰維護。

字段清單至少應包含：

• 頁面 URL，也就是網頁地址
• 頁面類型
• 頁面主要描述主體的名稱
• 標題
• 作者或發佈主體
• 發佈日期與更新時間
• 圖片
• 描述
• 規範 URL，也就是希望搜尋系統認定為主要版本的頁面地址
• 當前類型特有的價格、地址、營業時間或常見問題等字段

每個字段都要標明來源。字段值應來自頁面當前可以看到的內容，或者來自能夠與頁面同步更新的內容系統字段。

如果某個字段只在生成器中手工填寫，頁面更新後，結構化數據很可能仍然保留舊標題、舊價格、舊日期或舊圖片。此時代碼語法可能沒有任何問題，但它描述的已經不是當前頁面。

結構化數據必須與頁面主要內容一致。頁面沒有展示的事實、已經過期的價格、虛構的評價或容易造成誤解的字段，即使通過語法校驗，也不合格。

還要説明不同對象之間的關係

一個頁面可能同時出現文章、作者、發佈企業和網頁本身。一個網站也可能在首頁、文章頁、產品頁和門店頁中反覆提到同一家企業。

如果每個頁面都創建一個名稱相同、彼此卻沒有關聯的企業對象，搜尋系統就更難確認這些資訊是否指向同一個主體。

這時可以使用穩定的 @id。@id 可以理解為某個對象固定使用的識別地址。同一家企業出現在不同頁面時，應儘量使用一致的 @id。

文章作者、發佈組織、產品品牌和頁面本身也應分別描述，再通過相應屬性建立關係。不要把不同主體混成一個對象，也不要在每個頁面反覆創建互不關聯的重複對象。

頁面少：使用在線Schema生成器

如果只有幾張固定頁面，可以使用在線生成器。基本流程是選擇類型、填寫頁面事實、導出 JSON-LD，再交給開發人員或通過網站後台插入頁面。

在線工具使用成本較低，適合瞭解字段設置，也適合製作一兩個樣板頁面。選擇工具時，重點檢查三項能力：

• 能否導出完整的原始代碼。
• 是否覆蓋網站實際需要的 Schema 類型。
• 是否允許修改全部必要字段。

只能預覽結果、不能導出代碼的工具，不適合正式使用。

在線生成器的主要問題不在代碼輸出，而在版本管理和內容同步。頁面標題、價格、日期或圖片發生變化後，手工生成的代碼不會自動更新。

當頁面超過十幾張，或者同一種頁面模板反覆出現時，繼續逐頁複製粘貼，很容易造成字段遺漏和內容不一致。這時應及時改用自動讀取頁面字段的生成方式。

同類頁面持續增加：使用CMS插件或模板模塊

文章頁、產品頁、門店頁等重複頁面，更適合通過 CMS 插件或模板模塊生成。

這類工具可以讀取頁面標題、作者、日期、主圖和自定義字段，再按照統一模板輸出 JSON-LD。頁面內容更新時，結構化數據也可以跟隨相應字段更新。

選擇插件或模板模塊時，不要只看它宣稱支持多少種 Schema，還要檢查以下問題：

• 頁面字段能否準確對應到結構化數據字段。
• 模板能否覆蓋網站現有的頁面結構。
• 單個頁面出現特殊情況時，能否單獨調整。
• 生成的代碼能否導出和檢查。
• 插件或模板更新後，能否重新執行校驗。

自動填充不代表內容一定正確。預設作者、預設圖片、空字段和過期數據，仍然需要人工抽查。

還要檢查重複輸出。同一個頁面可能同時由網站主題、CMS 插件和自定義代碼生成結構化數據。如果三處代碼描述的是同一個對象，卻使用了不同的價格、圖片或規範 URL，就會產生衝突。

所以上線前不能只確認“網頁源代碼裏已經有 Schema”，還要檢查是否存在重複對象和不一致字段。

頁面多：使用代碼批量生成

電商、知識庫、門店庫或多語言網站通常需要通過代碼生成結構化數據。

開發人員可以從集中存放頁面資訊的數據庫或數據接口讀取字段，再根據不同頁面類型輸出 JSON-LD，並把校驗加入網站的構建或發佈流程。

一套能夠用於正式發佈的批量生成方案，至少要具備四項能力：

1. 必要字段缺失時阻止發佈。
2. 穩定生成 @id 和頁面 URL。
3. 區分測試環境地址與正式網站地址。
4. 模板發生變化後，重新檢查所有相關頁面。

每次生成的結果還應保留版本記錄，以便追溯某個頁面在某次發佈時具體輸出了什麼。

使用代碼生成，並不意味着可以自行創造 Schema 類型和屬性。類型與屬性仍應來自 Schema.org；如果希望頁面獲得某種搜尋功能，還要以目標搜尋引擎的官方文檔為準。

工具負責批量處理並保持格式一致，人工仍要負責核對頁面事實、選擇類型，並判斷內容是否符合搜尋功能政策。

批量模板上線前，還要處理以下常見情況：

• 特殊字符是否經過正確處理，避免破壞代碼格式
• 空字段是否被正確刪除或阻止發佈
• 同一字段包含多個值時，是否按列表形式正確輸出
• 多語言內容是否使用了對應語言的字段值
• 規範 URL 是否正確
• 圖片 URL 是否可以正常訪問
• 測試域名是否已經替換為正式域名

任何一項沒有處理好，都可能讓一批頁面同時出現錯誤。

一段JSON-LD代碼包含什麼？

下面是一段簡化的文章頁示例，只用於説明代碼結構，不能直接複製到所有頁面：

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "頁面上實際顯示的標題",
  "datePublished": "2026-08-11",
  "dateModified": "2026-08-11",
  "author": {
    "@type": "Person",
    "name": "頁面上實際顯示的作者"
  },
  "mainEntityOfPage": "https://www.example.com/article"
}

其中：

• @context 表示這段代碼使用 Schema.org 的詞表。
• @type 表示當前描述的對象類型，這裏是文章。
• headline 表示文章標題。
• datePublished 表示發佈日期。
• dateModified 表示最後更新時間。
• author 表示文章作者。
• mainEntityOfPage 指向這篇文章所屬的主要頁面。

正式使用時，需要根據頁面實際內容和目標搜尋功能的官方文檔，補充必填字段與推薦字段。

示例中的標題、日期、作者和 URL 都不能原樣保留。如果需要加入圖片，也必須使用當前頁面實際採用的圖片地址。代碼應由頁面字段生成，不能把示例文字固定在模板中。

代碼生成後，必須完成三次校驗

生成代碼只是第一步。要確認結構化數據能夠正式使用，需要依次完成三類檢查。

第一次：檢查Schema語法

可以使用 Schema.org Markup Validator，也就是 Schema.org 提供的標記校驗工具，檢查以下內容：

• 代碼中的括號、引號和逗號是否完整。
• 屬性名稱是否存在。
• 字段值的類型是否正確。
• 多個對象之間的關係是否已經連接。

這次校驗要回答的是：這段代碼是不是有效的 Schema.org 標記？

第二次：檢查目標搜尋功能

使用目標搜尋引擎提供的測試工具，檢查當前類型是否受到支持、必填字段是否齊全，以及頁面是否符合對應功能政策。

以 Google 搜尋為例，Rich Results Test 是 Google 的富結果測試工具，用於檢查頁面是否滿足其支持的富結果類型和字段要求。

測試通過，只代表頁面具備獲得相應展示的資格，不代表搜尋結果一定會採用這種展示。

這次校驗要回答的是：這個頁面是否具備對應增強展示的資格？

第三次：檢查正式上線頁面

頁面發佈後，還要使用搜尋引擎提供的 URL 檢查工具，查看搜尋系統實際獲取到的頁面版本。

需要確認：

• JSON-LD 確實出現在搜尋系統獲取到的頁面中。
• 結構化字段與頁面可見內容一致。
• 代碼沒有被頁面模板、緩存或發佈流程遺漏。
• 頁面沒有受到錯誤的抓取或索引設置阻擋。

“抓取”是搜尋系統讀取網頁內容的過程，“索引”是搜尋系統把頁面資訊收錄到可檢索資料中的過程。

這次校驗要回答的是：正式上線的頁面能不能被搜尋系統正常讀取？

三次校驗不能互相替代：

• Schema 語法有效，不代表它屬於搜尋引擎支持的富結果類型。
• 富結果測試通過，不代表代碼已經成功部署到正式頁面。
• 正式頁面可以讀取，也不代表頁面一定會獲得增強展示。

六類工具分別解決什麼問題？

工具類別	適用場景	必須具備的能力	應保留的交付物
在線生成器	1—10張固定頁面	類型選擇、字段編輯、代碼導出	JSON-LD文件
CMS插件或模塊	重複頁面模板	字段對應、模板覆蓋、單頁調整	自動生成的代碼
自定義模板腳本	批量頁面或多語言網站	版本記錄、重複測試、環境區分、字段缺失時阻止發佈	批量輸出記錄
Schema.org校驗器	所有頁面	語法、詞表、對象關係檢查	校驗結果
搜尋功能測試工具	需要增強展示的頁面	支持類型、必填字段、政策檢查	功能測試結果
線上URL檢查工具	已發佈的真實頁面	抓取、頁面生成、代碼讀取狀態	線上驗收記錄

如果團隊只處理一個企業官網，可以先通過在線工具瞭解字段，再把確認後的類型和字段交給網站模板統一維護。

如果網站每週都會新增文章、產品或門店頁面，應儘早接入 CMS 字段或代碼模板。

判斷方案是否合適，不看使用了多少工具，而要看頁面更新後，結構化數據能否同步更新。

一套可以直接執行的完整流程

1. 盤點網站現有的頁面模板，為每類頁面選擇一個主要 Schema 類型。
2. 建立字段清單，確認每個值來自頁面可見內容，或來自能夠同步更新的系統字段。
3. 根據頁面數量和更新頻率，選擇在線生成器、CMS 模塊或代碼模板。
4. 生成 JSON-LD，重點檢查 @type、@id、URL、日期、圖片和不同對象之間的關係。
5. 使用 Schema.org 校驗器消除語法和詞表錯誤。
6. 使用目標搜尋引擎的功能測試工具，檢查必填字段和政策要求。
7. 正式發佈後抽查線上頁面，並保存代碼、校驗結果、版本記錄和負責人資訊。

第一次實施時，可以先選擇3—5個有代表性的頁面作為樣板。樣板完成三次校驗後，再把模板應用到其他同類頁面。

這樣可以先發現字段來源、對象關係和內容同步問題，避免同一種錯誤同時出現在全站頁面中。

常見問題

必須購買付費生成器嗎？

不必。

頁面較少時，使用能夠導出代碼的在線工具，再結合官方文檔和校驗器，就可以完成生成與檢查。

頁面較多時，主要成本來自字段維護、模板開發和發佈後的重複檢查，而不在生成按鈕本身。

一個頁面可以放多個Schema嗎？

可以。

一個頁面可以描述多個相關對象，但要明確它們之間的關係，並保證所有字段都與頁面主要內容一致。

不要為了增加代碼數量而堆疊無關類型，也要避免插件和自定義代碼重複輸出同一個對象。

JSON-LD應該放在頁面哪裏？

JSON-LD 通常放在 HTML 的 <head> 或 <body> 腳本區塊中。<head> 是存放頁面標題、説明等資訊的區域，<body> 是存放頁面主要可見內容的區域。具體插入方式由網站使用的框架和模板決定。

關鍵不在位置本身，而在於搜尋系統獲取線上頁面時能夠讀到這段代碼，並且代碼字段能夠與頁面內容同步。

為什麼生成器沒有報錯，搜尋功能測試仍然不通過？

因為兩類工具檢查的內容不同。

生成器或 Schema.org 校驗器主要檢查代碼格式、詞表和字段值類型；搜尋功能測試還會檢查搜尋引擎是否支持當前類型、必填字段是否齊全，以及內容是否符合對應功能政策。

通過語法檢查，不等於通過搜尋功能檢查。

頁面更新後，需要重新生成嗎？

需要同步更新。

只要標題、作者、日期、價格、庫存、圖片、地址等結構化字段發生變化，JSON-LD 就要隨之更新。

使用字段對應關係和模板生成時，可以自動完成同步；手工生成的頁面則需要重新核對併發布代碼。

做了Schema，就會被AI引用嗎？

不能保證。

AI 是人工智能的英文簡稱。Schema 可以讓頁面中的對象、屬性和關係表達得更明確，但人工智能生成內容的系統是否抓取、理解、選擇和引用頁面，還取決於頁面可訪問性、內容質量、來源可信度、問題匹配程度和系統自身策略。

結構化數據同樣不能保證排名或富結果。它的直接作用，是讓頁面事實更便於機器識別；是否採用這些資訊，仍由搜尋系統決定。

官方核驗入口

• Google Search Central：結構化數據入門
• Google Search Central：結構化數據通用規範
• Schema.org詞表與類型
• Schema.org Markup Validator説明