讓 AI 直接引用你的答案：
FAQPage 結構化資料實戰，附我們自己踩過的坑

一句話結論：FAQPage 結構化資料的重點，早就不是「長出 Google 那個折疊問答框」，而是「讓機器準確讀懂你的一問一答」。而最常見、也最難察覺的失敗，是你的 schema 只存在於 JavaScript 執行後的頁面裡——非 JS 的 AI 爬蟲抓的是原始 HTML，它們看到的那份原始碼裡，你的 schema 根本不存在。

這篇不談玄學，只談你今晚就能改的東西：一段可以照抄的正確 FAQPage 寫法、四個真的會讓 AI 一個字都讀不到的錯誤，以及我們自己網站上一個 live 的 23 題 FAQPage 當對照組。其中第一個錯誤，是我們自己在做全站結構化資料稽核時親手踩到、又親手補上一道 CI 防線才根治的——所以它排第一個講。

1. 一句話答案：FAQPage 現在拚的是「被機器讀懂」

先講一個很多人不知道的事實：Google 從 2023 年 8 月起，把 FAQ rich result（搜尋結果裡那個藍色折疊問答）限縮到政府與衛生機構等權威網站。一般網站加了 FAQPage，多半不會再看到那個折疊框。但這不代表 schema 沒用了——被收掉的只是「視覺呈現」，機器可讀的問答結構仍在被索引與 AI 引擎使用。

換句話說，做 FAQPage 的動機變了。過去大家做它是為了在搜尋結果佔更多版面（那個折疊框很吸睛）；現在做它，是為了讓 Google 索引、知識圖譜，以及 ChatGPT、Perplexity、Google AI Overviews 這些會「生成答案再附上出處」的系統，能精準對上「這個問題，這個頁面給了這個答案」^[2]。它是機器理解的鷹架，不是版面裝飾。理解這個轉變，下面四個錯誤才會知道為什麼致命。

2. 最小可用的正確 FAQPage JSON-LD

FAQPage 的結構本身很單純：一個 FAQPage，底下 mainEntity 放一串 Question，每個 Question 有 name（問題）與一個 acceptedAnswer（答案）。這是官方文件定義的最小骨架^[1]：

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "我的退款要多久才會入帳？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "核准後 3 至 5 個工作天退回原付款方式。"
      }
    }
  ]
}
</script>

骨架不難，難的是「內容怎麼寫」與「放對地方」。以下四個致命錯誤，全都不是語法錯誤——它們的 JSON 都能 parse、驗證工具都會顯示綠燈，但成果卻是 AI 讀不到、或讀到了也不引用。

3. 致命錯誤一：schema 只靠 JS 注入

這個坑我們自己踩過。做全站結構化資料稽核時，我們發現有一批頁面「瀏覽器看起來 schema 都在、但用純文字工具抓原始 HTML 卻是空的」——因為那些 schema 是靠共用的前端腳本在執行期注入的。對能跑 JS 的環境沒問題，對只讀原始碼的檢索爬蟲（例如 GPTBot、ClaudeBot、PerplexityBot 這類）等於不存在。

我們的根治做法，是加一道建置期的自動檢查：掃描所有公開頁面，若一個「應該要有 schema」的高價值頁面在原始 HTML 裡缺了必要的結構化資料，就直接讓那次程式碼變更無法上線。這樣一來，「schema 退化成只靠 JS 注入」這個回歸，會在部署前就被擋下，不會靜靜地讓 AI 讀不到我們的頁面。

你不一定需要一整套 CI，但一定要記住那個測試動作：看原始碼，不要只看瀏覽器。瀏覽器會替你執行 JS、給你一個「加工後」的假象；爬蟲不會。

4. 致命錯誤二：問題不是使用者會問的句子

5. 致命錯誤三：答案不自包含、無法被整段摘走

這一點和 AI 實際怎麼讀頁面有關。2025 年一份針對 ChatGPT、Claude、Perplexity、Gemini 的受控實驗發現：這些系統直接抓頁面時，常常忽略 JSON-LD、只讀看得見的 HTML 文字^[4]。這給了我們兩個很實際的結論：第一，schema 要做（餵索引與知識圖譜這條間接路）；第二，可見的問答文字同樣重要，甚至對「直接被 AI 讀」更關鍵。所以答案要自包含，不只是為了 schema 漂亮，是因為那段可見文字本身，就是 AI 會直接摘走的東西。

6. 致命錯誤四：schema 與可見內容兜不攏

7. 真實案例：我們自己的 faq.html 23 題

與其給你抽象原則，不如給你一個可以自己打開來看的本尊。我們官網的 faq.html 有 23 個可見的問答，對應到原始 HTML 裡 FAQPage 結構化資料的 23 筆 Question 條目——一題不多、一題不少，可見文字與 schema 逐字對得上。

這正好把上面四個錯誤全部反著示範了一遍：

• schema 在原始 HTML 裡（不是 JS 注入）——你可以對 truelink-group.com/faq.html 下 curl，或 view-source，直接在純文字裡找到那段 FAQPage JSON-LD。
• 問題是真人會問的句子——像「認證需要多久？」「我的資料安全嗎？」這種，而不是關鍵字。
• 答案自包含——每題開頭先給結論，單獨摘出來也讀得懂。
• 23 個可見問答＝23 筆 schema 條目——不多塞、不藏題，可見與結構化嚴格一致。

你不需要相信我的說法，打開原始碼數一數就知道。這也是我們對「可驗證的信任」的一貫立場：講得出來的，就要能被你當場查證。

8. 收尾：三步驗證清單

這三步做完，你就同時鋪好了兩條路：schema 走「餵 Google 索引與知識圖譜」的間接路，可見問答走「被 AI 直讀摘引」的直接路。兩條都通，你的答案才真的有機會出現在別人問 AI 時得到的回覆裡。