Product、FAQPage、HowTo怎麼正確使用

拿到 Product、FAQPage、HowTo 三段代碼模板，先別急着全部複製進網站。

Product（產品資訊）、FAQPage（常見問題頁面）和 HowTo（操作教程），都是 Schema.org 定義的結構化數據類型。所謂結構化數據，就是用一組標準字段告訴搜尋引擎：這個頁面介紹的是什麼，頁面中哪些內容屬於產品名稱、價格、問答或操作步驟。

JSON-LD 是編寫結構化數據的一種常用格式。它通常以一段代碼的形式放進網頁源代碼，但只能標記頁面已經提供的資訊，不能代替頁面正文。

如果頁面沒有展示價格、庫存、評價、問答、操作步驟或耗時，就不能只在 JSON-LD 中補寫這些內容。模板包含多少字段並不重要，真正決定該用哪類結構化數據的，是當前頁面寫了什麼。

這三類結構化數據的用途和 Google 目前的支持情況也不相同：

類型	適合什麼頁面	主要標記什麼	Google 目前的支持情況
Product	單個商品或產品詳情頁	名稱、圖片、型號、價格、庫存等真實資訊	仍支持商品相關搜尋功能
FAQPage	展示多組站方固定問答的頁面	頁面上完整可見的問題和答案	FAQ 富結果通常只向權威政府和健康網站展示
HowTo	有明確操作順序的教程	步驟、工具、材料和耗時	HowTo 富結果已經停用

這裏所説的“富結果”，是指搜尋結果中可能額外出現的商品價格、庫存、問答等擴展資訊。

正確的使用順序是：先檢查頁面內容，再選擇結構化數據類型，最後填寫字段並完成驗證。

寫代碼前，先確認這5件事

1. 只標記頁面上真實可見的內容

商品價格、庫存、FAQ 答案和操作步驟，都不能只存在於 JSON-LD 中。用戶在頁面上能看到什麼，結構化數據才能標記什麼。

FAQ 可以使用摺疊組件展示，但用戶展開後必須能夠看到完整的問題和答案。

2. 不存在或無法確認的字段，直接刪除

模板中的示例價格、網址、評分、庫存和日期，上線前都必須替換。

如果頁面沒有對應資訊，就刪除相關字段。不要保留示例值，也不要為了讓驗證工具少報一條警告而編造數據。

3. 使用正確的 JSON-LD 格式

JSON-LD 應放在下面這組 HTML 標籤中。HTML 指網頁源代碼使用的標記語言。

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

Google 通常推薦使用 JSON-LD。但格式和放置位置正確，只能説明代碼寫法沒有明顯問題，不能證明代碼中的價格、庫存、評價等內容真實。

4. 分清 Schema.org 規範與 Google 搜尋功能

Schema.org 負責定義可以使用哪些結構化數據類型和字段，Google 則決定哪些類型能夠觸發搜尋結果中的擴展展示。

因此，代碼符合 Schema.org 規範，不等於 Google 一定會展示富結果。

FAQPage 和 HowTo 仍是有效的 Schema.org 類型，但 Google 對相應富結果的支持已經發生變化。判斷是否部署時，不能只看這個類型是否存在，還要看網站的使用目的和維護能力。

5. 驗證代碼後，還要檢查實際抓取結果

先檢查代碼語法，再用對應工具驗證。頁面上線後，還要查看網頁源代碼和 Google 的網址抓取結果，確認：

• 網站模板沒有轉義或破壞 JSON-LD；
• 頁面輸出的是新版本代碼；
• 緩存沒有繼續提供舊數據；
• Google 實際抓取到的內容與當前頁面一致。

驗證工具顯示“有效”，只説明代碼通過了對應規則，不代表 Google 一定會展示富結果。

Product：用於明確的商品或產品詳情頁

如果頁面介紹的是一個可以明確識別的商品，可以從下面這份簡化模板開始。

模板使用 offers 標記商品報價資訊，沒有加入評價字段，適合沒有真實評分數據的商品頁面。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/products/model-a#product",
  "name": "示例產品A",
  "image": [
    "https://example.com/images/model-a.jpg"
  ],
  "description": "用一句與頁面一致的話説明產品用途和關鍵規格。",
  "sku": "MODEL-A-001",
  "brand": {
    "@type": "Brand",
    "name": "示例品牌"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/model-a",
    "priceCurrency": "CNY",
    "price": "999.00",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>

上線前，至少要逐項檢查並替換以下內容：

字段	含義
@id	當前產品對象的唯一標識
url	產品頁面的網址
name	產品名稱
image	產品圖片地址
description	與頁面一致的產品説明
sku	SKU，即用於識別具體商品的庫存單位編號
brand	品牌名稱
priceCurrency	價格使用的幣種，CNY 表示人民幣
price	頁面實際展示的價格
availability	當前庫存狀態
itemCondition	商品狀態，例如模板中的 NewCondition 表示新品

Google 的 Product snippet，也就是商品摘要搜尋展示，要求提供 name，同時要求 review、aggregateRating、offers 至少有一項。上面的模板選擇了 offers。

如果頁面屬於可以直接購買的商品頁，還應對照 Merchant listing，也就是商家商品列表展示的相關文檔，判斷是否需要補充其他字段。

只有頁面真實展示、來源可以核驗的評價或彙總評分，才能加入 review 或 aggregateRating。沒有真實評價就刪除這些字段，不要編造評分。

價格、幣種和庫存狀態也必須與頁面可見內容一致。

沒有價格的 B2B 產品頁怎麼辦

B2B 指企業面向其他企業開展的業務。

沒有價格的 B2B 產品頁，仍然可以使用 Schema.org 的 Product 類型描述產品。但它是否滿足 Google 某類商品富結果的要求，需要根據 Product snippet 或 Merchant listing 的具體規則判斷。

頁面沒有真實價格時，不要用虛構價格填充 offers。

FAQPage：用於頁面上的站方固定問答

FAQ 是“常見問題”的英文縮寫。FAQPage 適合標記由網站提供的多組固定問答，每個問題和答案都要完整展示在頁面上，不能只寫進結構化數據。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "產品A支持哪些使用場景？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "產品A適用於場景一和場景二，具體限制以頁面規格表為準。"
      }
    },
    {
      "@type": "Question",
      "name": "產品A如何申請售後？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "請在訂單頁提交售後申請，並上傳訂單號和問題説明。"
      }
    }
  ]
}
</script>

Question.name 要對應頁面上的完整問題，acceptedAnswer.text 要對應頁面上的完整答案。頁面可以使用摺疊組件，但用戶必須能夠查看全部內容。

如果一個頁面只圍繞一個問題展開，並允許用戶提交多個答案，就不屬於這裏所説的站方固定問答。這類頁面應另行查看 QAPage，也就是多人問答頁面結構化數據的相關規則。

還要注意，Google 從2023年起，通常只向權威政府和健康網站展示 FAQ 富結果。

普通企業網站仍然可以保留與頁面一致、維護成本較低的 FAQPage 標記，但不能把它當作穩定的搜尋展示入口，更不能承諾添加代碼後一定出現問答富結果。

HowTo：用於有明確順序的操作教程

HowTo 適合具有明確操作順序的教程。步驟、工具、材料和耗時，都要與頁面正文一一對應。

下面的模板以30分鐘、兩項材料、一件工具和三個步驟為例。頁面正文必須同步展示這些資訊。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "如何安裝示例產品A",
  "description": "完成安裝前檢查、固定和通電測試。",
  "totalTime": "PT30M",
  "supply": [
    {"@type": "HowToSupply", "name": "安裝螺絲"},
    {"@type": "HowToSupply", "name": "絕緣膠帶"}
  ],
  "tool": [
    {"@type": "HowToTool", "name": "十字螺絲刀"}
  ],
  "step": [
    {
      "@type": "HowToStep",
      "name": "檢查配件",
      "text": "核對主機、螺絲和説明書是否齊全。",
      "url": "https://example.com/guides/install-model-a#step1"
    },
    {
      "@type": "HowToStep",
      "name": "固定設備",
      "text": "按説明書標註的位置固定設備並檢查鬆動。",
      "url": "https://example.com/guides/install-model-a#step2"
    },
    {
      "@type": "HowToStep",
      "name": "完成測試",
      "text": "通電後按頁面檢查表完成首次運行測試。",
      "url": "https://example.com/guides/install-model-a#step3"
    }
  ]
}
</script>

totalTime 使用 ISO 8601 時長格式。這是一套通用的日期和時間表示標準，其中30分鐘寫作 PT30M。

步驟名稱、步驟説明和錨點網址，都要與頁面內容對應。錨點網址是可以直接跳轉到頁面中某個具體步驟的連結。

頁面沒有材料或工具時，應刪除 supply 或 tool 等相應字段。

Google 已經停止展示 HowTo 富結果，Rich Results Test（富結果測試工具）也不再支持這項搜尋功能。因此，部署 HowTo 的理由不應是等待 Google 展示步驟卡片，而應是讓仍然識別 Schema.org 規則的系統更清楚地理解教程內容及其組成部分。

如果網站沒有持續維護 HowTo 數據的能力，只保留結構清楚的網頁步驟也可以。

三類結構化數據能不能放在同一頁

可以，但頁面必須確實同時提供這三類內容。

例如，一個產品詳情頁同時展示了具體商品、多組站方 FAQ 和完整安裝教程，就可以使用 @graph 把多個數據對象組織在同一段 JSON-LD 中，也可以把不同類型拆成多個 JSON-LD 代碼塊。

無論採用哪種寫法，都要滿足三個條件：

1. 每個數據對象對應的主體明確；
2. @id 和頁面網址對應正確；
3. 結構化數據與頁面可見內容一致。

關鍵不在於代碼塊有幾個，而在於每個對象是否真實、對象之間的關係是否清楚。不能因為手裏有三份模板，就把三類結構化數據直接放進全站所有頁面。

檢查項	Product	FAQPage	HowTo
對應主體	一個具體商品	多組站方問答	一個完整操作過程
頁面必須展示	名稱、價格、庫存等實際填寫的資訊	每個問題和答案	步驟、工具、材料、耗時等實際填寫的資訊
最容易出現的虛假字段	評分、評價、價格	頁面不存在的答案	不存在的步驟和耗時
Google 目前的支持情況	仍支持商品相關功能	富結果通常限權威政府和健康網站	富結果已經停用

上線前，按這個順序驗證

第一步：檢查 JSON 語法

先用 JSON 解析器檢查括號、逗號、引號等語法問題，確保代碼能夠正常讀取。JSON 解析器就是檢查這類文本代碼能否被程序正確識別的工具。

第二步：檢查 Schema.org 規範

使用 Schema.org Validator（Schema.org 驗證器）檢查類型、字段和嵌套關係是否符合 Schema.org 規範。嵌套關係指一個數據對象被放在另一個對象內部時，兩者的從屬關係是否正確。

第三步：檢查 Google 支持的搜尋功能

Product 可以使用 Rich Results Test，並根據 Product snippet 或 Merchant listing 的具體使用場景處理錯誤。

FAQPage 是否顯示富結果，要考慮 Google 目前的展示限制。HowTo 已不再屬於 Rich Results Test 支持的搜尋功能。

第四步：檢查 Google 實際抓取的版本

頁面上線後，使用 URL Inspection（網址檢查工具）查看 Google 抓取到的內容，確認它讀取的是新版本，而不是被網站模板破壞的代碼或緩存中的舊數據。

需要再次説明：驗證通過，不等於 Google 一定展示富結果。實際展示還會受到頁面質量、展示資格、抓取狀態、用戶搜尋內容和對應搜尋功能狀態的影響。

同樣，HowTo 不再出現在 Google 富結果測試的支持項目中，也不代表 Schema.org 刪除了 HowTo 類型。Schema.org 是否保留某個類型，與 Google 是否支持相應富結果，是兩個不同的問題。

5個容易誤判的問題

1. Product 必須同時填寫 offers、review 和 aggregateRating 嗎

不必須。

Product snippet 要求提供 name，並要求 offers、review、aggregateRating 至少有一項。頁面上有什麼真實資訊就寫什麼，沒有真實評價就不要補寫。

2. 普通企業網站還要不要使用 FAQPage

可以保留與頁面一致、維護成本較低的 FAQPage。

但 Google 的 FAQ 富結果通常只向權威政府和健康網站展示，普通企業網站不能把它視為穩定的富結果入口。

3. HowTo 富結果停用後，HowTo 還有沒有用

Google 的 HowTo 富結果已經停用，但 Schema.org 仍然保留 HowTo 類型。

是否繼續部署，應根據其他使用方和網站的維護能力判斷，不應再把 Google 步驟富結果作為主要理由。

4. 三種結構化數據能不能寫進同一個 JSON-LD

可以使用 @graph 把多個對象放在同一個 JSON-LD 代碼塊中，也可以拆成多個代碼塊。

真正需要檢查的是對象關係、@id、網址，以及每項數據能否在頁面內容中找到對應資訊。

5. 為什麼驗證通過後仍然沒有富結果

因為驗證通過只説明當前代碼符合對應工具的規則，不代表 Google 必須展示。

頁面質量、展示資格、抓取狀態、用戶搜尋內容和對應搜尋功能的當前狀態，都可能影響最終結果。

最後只看三個判斷標準

Product、FAQPage 和 HowTo 不是三份複製後就能直接使用的通用代碼。每個頁面是否需要部署、應該填寫哪些字段，都要回到頁面本身判斷。

上線前只問三件事：

1. 頁面是否真的提供了這些內容？
2. 結構化數據是否與用戶看到的內容一致？
3. 網站是否有能力持續維護這些字段？

三項都能確認，再部署對應的結構化數據。缺少真實內容時，刪除字段或暫不使用，都比把示例數據直接上線更合適。

公開資料入口

• Google Product structured data：https://developers.google.com/search/docs/appearance/structured-data/product
• Google Product snippet：https://developers.google.com/search/docs/appearance/structured-data/product-snippet
• Google FAQ 與 HowTo 變更説明：https://developers.google.com/search/blog/2023/08/howto-faq-changes
• Schema.org Product：https://schema.org/Product
• Schema.org FAQPage：https://schema.org/FAQPage
• Schema.org HowTo：https://schema.org/HowTo