FAQPage 結構化資料：常見問答的標記與現況

Q: FAQPage 和 QAPage 有什麼不同？

FAQPage 用在由網站自己撰寫的常見問答，一個問題只有一個官方答案。QAPage 用在使用者互相問答的頁面，例如：論壇串，一個問題可能有多個答案並帶有投票數。兩者不能互換。

FAQPage 用來標記頁面上的 常見問答，明確告訴搜尋引擎「這一頁回答了哪些問題」。

json

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "問題的文字",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "答案的文字。"
      }
    }
  ]
}

顯示現況要先講清楚

一般網站已經看不到 FAQ 複合式結果

Google 已把 FAQ 複合式結果（搜尋結果下方那個折疊式問答區塊）的顯示範圍 收斂到政府與醫療衛生類的權威網站。一般網站標了也不會顯示。

這件事常讓人以為「那就別標了」，但那是誤判。

仍然值得標記的兩個理由：

理由	說明
描述頁面涵蓋的問題	標記明確列出這一頁回答了什麼，有助於搜尋引擎理解內容
成本極低	頁面上已經有問答，標記只是把它們結構化

這是一個通則

結構化資料的價值不只在複合式結果。即使某個型別已停止顯示（HowTo 也是這種情況），它提供的語意仍然有意義。

但也不要因此高估它，這是「順手做」的加分項，不是優先項目。

結構

mainEntity 是一個 Question 陣列，每個 Question 有一個 acceptedAnswer：

json

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "答案一定要在頁面上看得到嗎？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "一定要，這是硬性規定。標記的問答必須是使用者在頁面上找得到的內容。"
      }
    },
    {
      "@type": "Question",
      "name": "一頁可以標幾組問答？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "沒有硬性上限，但頁面上有幾組就標幾組，不要為了數量硬湊。"
      }
    }
  ]
}

欄位	必要性	說明
`mainEntity`	必填	`Question` 的陣列
`Question.name`	必填	問題的完整文字
`acceptedAnswer`	必填	答案物件
`Answer.text`	必填	答案的完整文字

name 要寫完整的問句

json

// 錯誤：只寫關鍵字
"name": "答案可見性"

// 正確：完整的問句
"name": "答案一定要在頁面上看得到嗎？"

硬性規定：答案必須可見

標記的問答必須是使用者找得到的內容

這是 FAQPage 唯一會招致問題的部分。

做法	合規嗎
答案直接顯示在頁面上	合規
答案放在可展開的收合區塊	合規
答案放在分頁式介面的其他分頁	合規
答案用 `display: none` 藏起來且無法展開	違規
標記了頁面上完全沒有的問答	違規

收合區塊完全沒問題

這個站的「常見問題」就是用收合區塊寫的，使用者點一下就看得到，屬於正常的介面設計。細節見無障礙與 SEO 的交集。

頁面與標記要一一對應

實務上最好的做法是 同一份內容產生兩種輸出：

markdown

## 常見問題

::: details 答案一定要在頁面上看得到嗎？
一定要，這是硬性規定。標記的問答必須是使用者在頁面上找得到的內容。放在可展開的收合區塊裡完全合規。
:::

json

{
  "@type": "Question",
  "name": "答案一定要在頁面上看得到嗎？",
  "acceptedAnswer": {
    "@type": "Answer",
    "text": "一定要，這是硬性規定。標記的問答必須是使用者在頁面上找得到的內容。放在可展開的收合區塊裡完全合規。"
  }
}

兩邊的問題數量與文字都要對得上

最常見的維護問題是「改了頁面上的答案卻忘了改標記」。長期下來兩邊會愈差愈遠。

可行的檢查方式是建置後比對兩邊的問題數量：

// 抽出頁面上收合區塊的標題與 ld+json 的 Question，比對數量
const details = [...html.matchAll(/<summary>([^<]+)<\/summary>/g)];
const questions = faqSchema.mainEntity.map((q) => q.name);

if (details.length !== questions.length) {
  throw new Error('頁面問答數與標記不一致');
}

答案裡的連結

Answer.text 可以放少量的超連結，但要用 HTML 標籤：

json

"text": "詳見 <a href=\"https://example.com/meta\">檔頭標籤</a> 的說明。"

Markdown 語法無效

json

// 錯誤：會被當成純文字
"text": "詳見 [檔頭標籤](/seo/meta) 的說明。"

更簡單的做法是標記寫純文字

這個站的做法是：頁面上的答案保留 Markdown 連結，ld+json 裡寫 移除連結語法 的純文字版本，兩者的文字內容保持一致。

這樣既避免了轉義的麻煩（JSON 裡的雙引號必須寫成 \"），也不必擔心 HTML 標籤讓標記變得難維護。

FAQPage 還是 QAPage

	`FAQPage`	`QAPage`
問答來源	網站自己撰寫	使用者互相問答
一個問題的答案數	一個（官方答案）	可能多個
有投票或最佳答案	否	是
典型頁面	商品的常見問題、文章的 FAQ 區	論壇串、問答社群

兩者不能互換

論壇串標成 FAQPage 會不符實際情況。反過來，自己寫的 FAQ 標成 QAPage 也不對，QAPage 的結構包含 suggestedAnswer 與 upvoteCount 這些欄位，自己寫的問答沒有那些東西。

QAPage 的結構長這樣：

json

{
  "@context": "https://schema.org",
  "@type": "QAPage",
  "mainEntity": {
    "@type": "Question",
    "name": "問題",
    "answerCount": 2,
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "被採用的答案",
      "upvoteCount": 15
    },
    "suggestedAnswer": [
      { "@type": "Answer", "text": "其他答案", "upvoteCount": 3 }
    ]
  }
}

注意 QAPage 的 mainEntity 是單一 Question（一頁一個問題），與 FAQPage 的陣列不同。

幾組問答比較合適

五到八組是舒服的規模

沒有硬性上限，但原則是 頁面上有幾組就標幾組，不要為了數量硬湊。

問答太多會讓頁面顯得雜亂，也稀釋了每一個問題的針對性。這個站的每篇文章固定五組，剛好對應讀者最可能有的疑問。

好的 FAQ 問題有兩個特徵：

特徵	說明
用讀者會問的說法	「為什麼我的圖片載入很慢」而不是「圖片效能最佳化概述」
答案是內文沒完整講到的	補充而非重複，否則失去存在意義

檢查清單

項目	標準
頁面上真的有這些問答	必備
答案使用者找得到（可展開也算）	必備
標記的文字與頁面上一致	必備
`name` 是完整的問句	必備
問答數量與頁面一致	建議
用 `FAQPage` 而非 `QAPage`（自撰問答）	必備
沒有為了數量硬湊	建議
通過複合式搜尋結果測試	建議