AHHA › 部落格 › FAQ Schema 怎麼做？ChatGPT 引用你網站問答的關鍵技術

FAQ Schema 怎麼做？ChatGPT 引用你網站問答的關鍵技術

2026年5月14日SEO 與 AI 搜尋· Howshin Wang

TL;DR

FAQ Schema（FAQPage）是少數能直接影響搜尋結果視覺呈現的結構化資料——Google 可能直接在搜尋結果該筆下方展開問答；ChatGPT、Perplexity 在引用時也優先擷取結構化的 FAQ。
頁面上必須有真實可見的 FAQ 內容，不能只在 JSON-LD 裡造假 FAQ 灌關鍵字。Google 對「Schema 欺騙」的處罰非常明確：rich result 消失、整頁降權。
產品頁、服務頁、定價頁、長篇部落格、活動頁都適合放 FAQ Schema，每頁建議放 3–8 條真實常見問題。
題目從客服信箱、Search Console 查詢報告、社群留言中挖，不要憑空想像 SEO 關鍵字組合。

一、FAQ Schema 是什麼？跟一般 FAQ 區塊有什麼不同？

核心觀點： 一般 FAQ 區塊只是「頁面上的問答列表」，給人類讀；FAQ Schema 是在頁面 head 加上一份 JSON-LD 標記，告訴搜尋引擎與 AI「這幾段是結構化的問答資料」。兩者的內容相同，差別在於有沒有給機器看的那層語意標記。

FAQ Schema 在 Schema.org 中的正式名稱是 FAQPage，是 WebPage 的子類型，專門用來標記「頁面上有問答區塊」。實作方式是在網頁 <head> 加上一段 <script type="application/ld+json">，內容是符合 FAQPage 結構的 JSON 物件。

關鍵在於「結構化」三個字。頁面上的 FAQ 區塊可能用 <details> 標籤、可能用 <dl> 列表、可能用 React Component 的 accordion——對搜尋引擎來說，這些都只是視覺呈現，它需要逆向推測「這段是不是問答」。但 FAQ Schema 讓網站直接告訴搜尋引擎：「下面這 5 對是 Question 與 Answer，沒有歧義」。

對 SEO 而言，這層標記可能換到搜尋結果頁的 rich result（問答直接展開）。對 GEO 而言，這層標記讓 AI 搜尋引擎在引用網頁問答時更精準——它不必猜「哪段是問題、哪段是答案」，直接從結構化資料讀取。

如果你還不熟 Schema.org 整體生態，可以先讀 Schema.org 是什麼？商家網站最該做的 5 種結構化資料，FAQPage 是其中 5 種優先實作類型之一。

二、為什麼 AI 搜尋引擎特別偏好 FAQ 結構化資料？

核心觀點： AI 搜尋引擎的核心任務是「給使用者一個答案」，而 FAQ Schema 本質上就是把網頁內容拆成「問題 → 答案」的結構。這個格式與 LLM 的使用情境完美對應，是所有 Schema 類型中對 GEO 最直接友善的一種。

當使用者向 ChatGPT 或 Perplexity 提問時，AI 引擎在背後做的事情是：找到網路上能回答這個問題的內容，擷取最相關的段落，組合成一個答案。整個流程裡，「找到能對應問題的段落」是最容易出錯的步驟——一篇純文字的部落格文章可能有 3000 字，AI 要從中判斷哪幾句是答案，需要消耗大量計算資源，且常常引用錯位。

FAQ Schema 直接解決這個問題。標好的 FAQ 內容已經是「問題 + 答案」配對好的資料結構，AI 不必拆解、不必判斷，可以直接引用。這也是為什麼 Anthropic、OpenAI 等公司在公開文件中都建議內容創作者「重要問答用 FAQ Schema 標記」。

對品牌而言，這層標記的價值不只在 rich result。它直接影響「在 ChatGPT 答案中是否被提及」、「被提及時引用準確度高不高」、「AI 是否標註來源」這三個 GEO 核心指標。FAQ Schema 是少數能同時推動三項指標的工具，這也是它在 GEO 策略中地位特殊的原因。

三、哪些頁面該放 FAQ Schema？怎麼挑出真正有效的問題？

核心觀點： 任何「使用者可能有具體疑問」的頁面都適合放 FAQ Schema：產品頁、服務頁、定價頁、長篇部落格、活動頁、教學文件。每頁建議放 3–8 條真實常見問題，挑題目時從客服信箱、Search Console 查詢報告、社群留言中挖，不要憑空想像關鍵字組合。

不適合放 FAQ Schema 的頁面類型也要先界定：首頁通常不適合（內容太雜，問答難聚焦）、純列表頁不適合（部落格分類頁、商品列表）、單純的視覺型 landing page 也不適合。

選題目的方法分三層。

第一層：客服與業務真實收到的問題。 這是品質最高的 FAQ 來源——使用者已經願意花時間問，代表這問題在購買決策中真的重要。把過去 3–6 個月客服信箱、官方 LINE、社群私訊裡重複出現的問題整理出來，去掉個人化細節，就是一份高品質的 FAQ 清單。

第二層：Google Search Console 查詢報告。 過濾出「以問句開頭」的搜尋字串（「⋯怎麼選」「⋯多少錢」「⋯適合誰」「⋯跟 X 差在哪」），這些都是使用者在 Google 直接打進去的問題。挑點擊率低但曝光量高的字串——這代表使用者在搜尋這個問題，但你的頁面沒有直接回答到。

第三層：競品與行業 FAQ 比對。 看同行業競品的 FAQ 區塊，看他們回答了哪些問題、漏了哪些。漏掉的那些就是你的 FAQ 機會點。

選好題目後，答案的寫法也有講究。每條答案建議控制在 50–150 字，第一句直接回答問題，後續補充細節。太短（< 30 字）AI 會覺得資訊不足，太長（> 300 字）AI 引用時可能截斷。

四、FAQ Schema 的 JSON-LD 該怎麼寫？

核心觀點： FAQ Schema 的 JSON-LD 結構很單純：外層是 FAQPage 物件、內含 mainEntity 陣列、每個元素是 Question 物件並包一個 acceptedAnswer。整份結構不到 20 行，但欄位名稱大小寫、必填欄位、HTML 字串中的 </script> 字串都有細節要注意。

一份標準的 FAQ Schema JSON-LD 長這樣：

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

實作上有幾個常見錯誤要避開。

第一，mainEntity 的值必須是陣列（即使只有一個問題也要用陣列包），不能直接放單一物件。第二，@type 大小寫敏感，必須是 FAQPage、Question、Answer，不能寫成 Faqpage 或 question。第三，答案文字可以包含 HTML 標籤（如連結、粗體），但角括號要先做 HTML escape，否則瀏覽器解析時可能與外層的 <script> 標籤混淆，導致整段 JSON-LD 失效。

最容易踩到的坑是答案內容包含 </script> 字串時瀏覽器會誤判 script 區段結束。如果 FAQ 中真的會出現「閉合 script 標籤」這類技術內容，必須把 JSON 中的角括號做 Unicode escape 處理。多數 Schema 產生器會自動處理這個細節，自己手寫時要特別注意。

完成的 JSON-LD 放在網頁 <head> 的 <script type="application/ld+json">⋯</script> 之間就可以。一個頁面通常只放一個 FAQPage 物件，把所有 FAQ 收在 mainEntity 陣列裡。

實作上建議用 AHHA FAQ Schema 產生器，視覺化輸入問答、即時產出格式正確的 JSON-LD、瀏覽器本地運算、支援多語、最多 20 條 QA。

五、Google 對 FAQ Schema 的紅線在哪？怎麼避免被懲罰？

核心觀點： Google 對 FAQ Schema 的兩條紅線是「內容必須在頁面上真實可見」與「問題必須是真實的常見問題」。違反任一條都可能導致 rich result 消失、整頁降權，甚至整站被視為「低品質訊號來源」。

第一條紅線：JSON-LD 中的 FAQ 內容必須與頁面上實際顯示的 FAQ 完全一致。不能在 head 裡塞 10 條 FAQ，但頁面上只顯示 3 條；也不能 JSON-LD 寫一份、頁面顯示另一份。Google 在抓取頁面時會交叉比對，發現不一致就拒絕渲染 rich result。

第二條紅線：問題必須是「真實使用者會問的常見問題」，而不是為了 SEO 灌進去的關鍵字組合。Google 明確懲罰過幾類做法：問題中塞滿關鍵字（「網站設計推薦哪家 2026 最便宜中小企業」這種問句不會有人問）、答案中堆疊 link（FAQ 答案中不該有大量內部連結）、用 FAQ 問同一個問題的多種變形（明顯只是為了多塞幾條 Schema）。

Google 在 2021 年的演算法更新中，把違反這些規則的網站從 FAQ rich result 中大規模移除。2023 年後 Google 也逐步收緊 FAQ rich result 的觸發條件——目前並非所有頁面的 FAQ Schema 都會顯示展開效果，但「沒有 Schema 一定不會顯示」這個原則沒變。

實務操作上有兩個避坑準則：

準則一：頁面上一定要有 visible FAQ 區塊。 不要把 FAQ 只藏在 head 的 JSON-LD 裡，頁面上要有對應的問答顯示（可以用 accordion 摺疊，但 HTML 結構中要存在）。這是最安全的做法。

準則二：FAQ 題目至少要是 Search Console 或客服紀錄中真實存在的問題。 不要為了 SEO 想像問題。如果一個問題只是「為了塞關鍵字」存在，多半會被 Google 演算法識別為 Schema 灌水。

六、怎麼驗證 FAQ Schema 是否生效？

核心觀點： 驗證 FAQ Schema 的標準流程有三步：用 Google Rich Result Test 確認 Schema 能觸發 rich result、用 Schema.org Validator 檢查語法合規、上線後一週內回查搜尋結果頁是否實際顯示展開效果。

第一步用 Google Rich Result Test 輸入頁面 URL（或直接貼 HTML 程式碼）。如果 Schema 正確，工具會顯示「偵測到 FAQ」並列出所有問答內容預覽。如果顯示「無法解析」或「缺少必填欄位」，依錯誤訊息逐項修正——通常是 @type 寫錯、mainEntity 不是陣列、缺少 acceptedAnswer。

第二步用 Schema.org Validator 做語法合規檢查。Rich Result Test 只看「能不能觸發 rich result」，Schema.org Validator 看「整份 JSON-LD 是否符合官方規範」。兩者搭配能抓出 99% 的實作錯誤。

第三步是上線後的長期觀察。Google 不保證有 FAQ Schema 就一定顯示展開效果，是否觸發 rich result 取決於頁面整體品質、查詢類型、競爭強度等多項因素。建議上線一週後，用 Google Search Console 的「成效報告」過濾 FAQ rich result 類型，看實際點擊率與曝光量。如果完全沒有觸發 rich result，可能是頁面整體 SEO 訊號不夠強，需要先補基礎。

對於整站健檢，AHHA SEO + GEO + AI 爬蟲三合一檢測會掃描網站所有頁面的 Schema.org 標記、回報哪些頁面有 FAQ Schema、哪些頁面有 FAQ 區塊但漏標 Schema、哪些頁面的 Schema 有語法問題。

七、結語：FAQ Schema 是 GEO 時代投資報酬率最高的單一標記類型

在所有 Schema.org 類型中，FAQ Schema 是商家網站最容易「立刻看到效果」的一種。它的實作成本低（5–10 分鐘）、回報明確（rich result + AI 引用）、紅線清楚（內容真實一致），是任何投入 GEO 策略的網站都該優先做的一件事。

長期經營線上資產的網站，FAQ Schema 應該被視為「每個重要頁面都該有」的標配，而不是「特定頁面才加」的選項。產品頁、服務頁、定價頁、長篇部落格——只要頁面上有真實常見問題，就該加上 FAQ Schema。完整的 SEO + GEO 策略地圖可參考 SEO 與 GEO 完整指南。

實作 FAQ Schema 可以用 AHHA FAQ Schema 產生器直接產出符合規範的 JSON-LD；如果想直接使用一個內建 Schema.org @graph 自動化、FAQ Schema 從 dashboard 一鍵設定的網站平台，可以立即試用 AHHA 30 天 →。

FAQ SchemaFAQPage結構化資料GEOJSON-LD

常見問題

FAQ Schema 跟一般 FAQ 區塊不一樣嗎？

不一樣。一般 FAQ 區塊只是頁面上的問答列表，給人類讀；FAQ Schema 是在頁面 head 加上 JSON-LD 標記，明確告訴搜尋引擎與 AI 「下面這些是結構化的 Question 與 Answer」。內容相同，但有沒有 Schema 標記，決定機器能不能正確識別、能不能觸發搜尋結果的 rich result、能不能被 AI 精準引用。

FAQ Schema 一定要做才能被 ChatGPT 引用嗎？

不是必要條件，但有 FAQ Schema 的內容被 AI 精準引用的機率明顯更高。AI 引擎在背後要做的事是「從網頁內容中找出能回答使用者問題的段落」，FAQ Schema 直接把問答配對好，AI 不必拆解判斷可以直接引用。沒做 Schema 的 FAQ 區塊 AI 仍可能引用，但準確度與被標註來源的機率較低。

我應該每個頁面都放 FAQ Schema 嗎？

不需要也不應該。FAQ Schema 適合「使用者可能有具體疑問」的頁面：產品頁、服務頁、定價頁、長篇部落格、活動頁、教學文件。首頁、純列表頁、單純的視覺型 landing page 通常不適合。每個放 FAQ Schema 的頁面建議放 3–8 條真實常見問題，太少 AI 認為資訊不足、太多反而稀釋每條的重要性。

Google 對 FAQ Schema 有什麼紅線？做錯會怎樣？

兩條紅線。第一，JSON-LD 中的 FAQ 內容必須與頁面實際顯示的內容完全一致，不能 head 塞 10 條但頁面只顯示 3 條。第二，問題必須是真實使用者會問的常見問題，不能是為了 SEO 灌進去的關鍵字組合。違反任一條都可能導致 rich result 消失、整頁降權，2021 年 Google 演算法更新時已大規模處罰過違規網站。

FAQ 題目該從哪裡挖？

三個來源從高品質到低品質：1) 客服信箱、官方 LINE、社群私訊中過去 3–6 個月重複出現的問題（最高品質）；2) Google Search Console 查詢報告中以問句開頭的搜尋字串（找曝光高但點擊低的字串）；3) 同行業競品 FAQ 比對找漏掉的問題。不要憑空想像 SEO 關鍵字組合，這類問題通常會被 Google 識別為 Schema 灌水。

FAQ Schema 怎麼驗證設定正確？

三步驟。第一步用 Google Rich Result Test 輸入頁面 URL 確認 Schema 能觸發 rich result。第二步用 Schema.org Validator 檢查整份 JSON-LD 語法合規。第三步上線一週後在 Google Search Console 成效報告過濾 FAQ rich result 類型，看實際曝光與點擊。整站健檢可用 AHHA SEO + GEO + AI 爬蟲三合一檢測一次掃描所有頁面的 Schema 狀態。