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

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

來源：https://www.starbox.work/zh-hant/insights/geo-guide/geo106/（星盒AI 知識中心，更新於 2026-09-30）

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

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

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

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

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

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

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

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

## Schema到底是什麼？

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

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

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

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

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

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

![Schema結構化數據怎麼生成？完整指南](/static/img/insights/geo-guide/geo106-2.jpg)

## 生成器實際做了什麼？

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

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

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

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

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

![Schema結構化數據怎麼生成？完整指南](/static/img/insights/geo-guide/geo106-3.jpg)

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

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

```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代碼包含什麼？

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

```json
{
  "@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：結構化數據入門](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)
- [Google Search Central：結構化數據通用規範](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)
- [Schema.org詞表與類型](https://schema.org/docs/schemas.html)
- [Schema.org Markup Validator説明](https://schema.org/docs/validator.html)