多數人以為 Google 在 2026 年 5 月收掉 FAQ 複合式搜尋結果之後，FAQPage 標記就沒必要做了；但這裡容易搞混一件事——Google 收掉的是搜尋結果頁面上那張展開式問答卡片，不是 schema.org 這套詞彙定義本身，FAQPage 依然是有效的 schema 類型，就算沒有觸發任何視覺呈現，也不會因此讓頁面被扣分。FAQ Schema 設定這件事，並沒有因為版面消失就跟著失去意義。
這波變動其實分兩個階段。第一階段在 2023 年 8 月，Google 先把 FAQ 複合式搜尋結果限縮到「知名且具權威性的政府與衛生機構網站」，一般網站就算標記寫得完全正確，搜尋結果上也不太會再出現那個展開式問答卡片；第二階段到了 2026 年 5 月，Google 乾脆把 FAQ 複合式搜尋結果這項功能整個從搜尋結果拿掉，隔月的 Rich Results Test 也跟著撤掉對應的預覽卡片。但這幾次調整動的都是「Google 搜尋結果怎麼呈現」，不是 schema.org 這套詞彙本身的定義。
FAQ 標記值不值得做，前面已經講清楚了，接下來要面對的是更實際的問題：語法怎麼寫對、放在哪種頁面才合規、常見錯誤有哪些、寫完怎麼驗證，還有實際加到頁面上的兩條路。先從最基本的容器結構講起，搞懂 FAQPage、Question、Answer 三層怎麼疊在一起，後面的範例跟除錯才看得懂。
FAQPage、Question、Answer 怎麼組成一組問答？
把 FAQPage 想成一個裝著整頁問答的箱子，箱子裡再一層一層往下疊，這是理解整套語法最快的方式。最外層是 FAQPage 這個型別，代表這整個頁面屬於「常見問題」性質；箱子裡用 mainEntity 屬性放進去的是一份問題清單，而且即使頁面上只有一題，也要用中括號把它包成陣列。這個小地方很多人第一次手刻就漏掉，後面「常見錯誤」那節還會再提一次。清單裡的每一題是一個 Question 物件，Question 底下再用 acceptedAnswer 屬性，巢狀嵌進去一個 Answer 物件，裝著這一題的答案。
疊起來看，順序就是 FAQPage、mainEntity 陣列、Question、acceptedAnswer、Answer，一層包一層。先把這個順序記住，等一下看到完整的程式碼範例、大括號跟中括號疊了好幾層，才不會被繞得頭暈。
三個型別各自都要標對 @type：整頁是 FAQPage、清單裡每一題是 Question、答案是 Answer，標錯型別，系統就讀不出正確的結構。每個物件開頭也都要有 @context，值固定寫 https://schema.org，用來告訴讀取端這些詞彙是照 schema.org 那套定義走的。還有一條容易忽略的規則：一個頁面只能有一組 FAQPage 類型定義，不能在同一頁疊兩個 FAQPage 區塊。如果頁面上真的有好幾組問答，通通放進同一個 mainEntity 陣列裡就好，不需要另外再開一組。
搞懂骨架之後，接下來要處理的是每一層裡面實際要填什麼，這正是最多人卡關、卻其實最簡單的地方。
Question 與 Answer，哪些欄位一定要填？
好消息是，FAQPage 這組類型本身並沒有想像中複雜。把所有欄位拆開來看，真正「不填就不成立」的其實只有兩個，其他都是加分用的選填欄位：
| 欄位 | 對應屬性 | 必填／選填 | 說明 |
|---|---|---|---|
| 問題文字 | Question.name | 必填 | 問題的完整文字，不能只放關鍵字 |
| 答案文字 | Answer.text(透過 acceptedAnswer 掛在 Question 底下) | 必填 | 答案的完整文字，不能只放摘要 |
| 回答者 | author | 選填 | 這則問答由誰回答 |
| 發布日期 | datePublished | 選填 | 這則問答第一次公開的時間 |
| 修改日期 | dateModified | 選填 | 最近一次更新的時間 |
| 錨點連結 | url | 選填 | 這則問答在頁面上對應的位置 |
核心就只有 Question.name 跟 acceptedAnswer.text 這兩個，比很多人想像的複雜語法簡單得多。
必填欄位：Question.name 與 Answer.text
Question.name 裝的是問題的完整文字，不是幾個關鍵字堆起來的標籤，要寫成一句完整的問句，讓機器讀得懂這是在問什麼。Answer.text 透過 acceptedAnswer 掛在 Question 底下，裝的是答案的完整文字。這兩個欄位都要求「完整全文」，不能只放摘要或半句話，這點跟後面「內容一致」的鐵則是同一個道理，標記裡寫的字，終究得跟頁面上使用者實際看到的字對得上。語法面先做到「寫完整」，後面才不用回頭改。
FAQ Schema 選填欄位能補上什麼語意？
author 指的是這則問答由誰回答，通常填品牌或組織名稱；datePublished、dateModified 則跟內容新鮮度有關，AI 在整理摘要、排序引用來源時，會把「這個答案是不是最近更新過」當成一個訊號，值得順手補上，不必為此在正文另闢一段說明；url 則是這則問答在頁面上對應的錨點連結，方便使用者或搜尋結果直接跳到那一題。這幾個欄位都是加分不加負擔，沒填也不影響標記能不能被讀懂，但補了語意會更完整。
欄位規則都懂了，直接看一段完整的程式碼，會比逐條對照定義更快抓到手感。
一段可以直接套用的 FAQPage JSON-LD 範例
前面兩節把骨架跟欄位都拆開講過，這裡直接給一段完整、複製修改就能用的 JSON-LD，一次示範三組問答。情境挑一個型錄印刷服務頁常見會被問到的問題，是去識別化的通則情境，不對應任何特定網站：
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "型錄印刷從送稿到交件通常要多久？",
"acceptedAnswer": {
"@type": "Answer",
"text": "型錄印刷的製作期通常抓五到十個工作天，實際天數會依頁數、裝訂方式與印量而不同。若還需要打樣確認顏色，建議另外預留一到兩天核色時間。"
}
},
{
"@type": "Question",
"name": "型錄印刷可以少量印製嗎？",
"acceptedAnswer": {
"@type": "Answer",
"text": "可以。傳統平版印刷通常在印量較高時單價才划算，但改用數位印刷可以接受幾十本起印，適合先試印確認內容沒問題，再決定要不要加印。"
}
},
{
"@type": "Question",
"name": "型錄印刷送印檔案要用什麼格式？",
"acceptedAnswer": {
"@type": "Answer",
"text": "多數印刷廠會要求送印高解析度的 PDF 檔，字體需先轉外框、圖片解析度建議在三百 dpi 以上，並在檔案裡標出出血與裁切線，避免完稿邊緣被誤裁。"
}
}
]
}Code language: JSON / JSON with Comments (json)這段程式碼要包在 <script> 標籤裡才會生效，type 屬性寫 application/ld+json，放進頁面的 <head> 或 <body> 結尾都可以，不影響原本頁面上的 HTML 內容，只是多加一段給搜尋引擎跟 AI 讀取的結構化說明。
順便留意 mainEntity 那個中括號，陣列語法讓日後要拿掉某一題變得很直覺，只要刪掉陣列裡對應的那個物件就好，不用動到其他題目的結構。
這段標記得對應頁面上使用者實際看得到的文字，JSON-LD 裡的三個問題跟三段答案，理論上使用者在頁面上捲一捲也要能親眼看到同樣的字句。這條「內容要對得起來」的規則，接下來這節會展開講清楚為什麼重要。
哪種頁面適合掛 FAQPage？
這節的核心是一條鐵則，JSON-LD 裡的每一題問答，文字必須跟頁面上使用者真的看得到的文字一致，不能是寫好塞進標記、頁面上卻找不到對應內容的暗樁，也不能反過來把畫面上原本就有的問答用 CSS 藏起來，只留標記給機器讀。
守住這條鐵則之後，適合掛 FAQPage 的頁面類型就很清楚，內容本來就在解答具體問題的頁面，例如教學文章逐段拆解常見疑問、比較文列出讀者常猶豫的取捨點、規格說明頁附帶技術問答，或者服務頁本來就設計了常見問題區塊，這些頁面的 FAQ 標記，等於把畫面上原本就有的文字，多描述一份給搜尋引擎跟 AI 讀。不適合硬塞的則是純故事型的品牌敘事頁，或者為了塞關鍵字臨時湊出幾題跟頁面主題八竿子打不著的行銷問答，這種標記就算語法完全正確，也不符合結構化資料要求的關聯性，等於白做工。
這裡順便釐清一個常被搞混的型別：FAQPage 是網站自己撰寫、答案固定的問答，QAPage 則是使用者可以自行提交答案、多方觀點並陳的討論串型頁面，像社群問答區那種形式，兩者不要混用。常見的誤用情境是，把讀者可以留言、答案眾說紛紜的討論串頁面掛成 FAQPage；或者反過來，把網站自己統一撰寫的常見問題頁硬套用 QAPage，兩種都對不上各自的定義。
語法跟頁面規則都確定之後，剩下的就是動手的問題，而這一步通常比想像中省力。
FAQ Schema 實際上怎麼加到頁面上？
實際要把 FAQ Schema 加到頁面上有兩條路可以走，而且對多數人來說，根本不需要自己手刻程式碼。現在主流的 SEO 外掛與內容管理系統大多內建 FAQ 區塊，填好問題跟答案，系統就會在背景自動組出合規的 JSON-LD；如果想完全掌控輸出格式，或手上的系統沒有這類功能，也還有手動貼一段程式碼的路。兩條路沒有優劣之分，差別只在維護方式。
SEO 外掛的 FAQ 區塊怎麼設定？
主流 SEO 外掛的操作邏輯大同小異：在編輯器裡搜尋「FAQ」，就能找到對應的 FAQ 區塊，逐題填入問題與答案，系統會自動在頁面輸出對應的 JSON-LD，不需要碰任何程式碼。要留意的是，這類 FAQ 區塊多半是新版區塊編輯器才有的功能，比較舊的編輯器介面不一定支援。
有個順序上的鐵則值得強調：先把正文裡本來就該有的問答寫清楚、寫完整，再用外掛把這些「已經存在」的問答描述進 FAQ 區塊，不是反過來為了湊 Schema 才硬掰幾題問答出來填。這正好呼應前面「內容一致」那條規則，標記裡的文字終究要跟頁面上讀者看到的文字對得上。
手刻 JSON-LD，怎麼貼進頁面？
如果手上的系統沒有內建 FAQ 功能，也沒打算另外裝 SEO 外掛，可以把前面「完整範例」那段程式碼，包進 <script> 標籤裡(type 寫 application/ld+json)，貼進頁面的 <head> 或內文結尾都可以，不需要更動原本的 HTML 內容，也不會影響頁面顯示。常見的貼法包括版型或佈景主題提供的自訂 HTML／程式碼區塊，或是系統留給你的自訂 head 內容欄位。
手刻的好處是可以完全客製欄位，也方便跟其他結構化資料一起維護；缺點是每次更新內容，都要記得同步改 JSON-LD 裡對應的文字，不像外掛區塊會跟著內容自動更新。
不管走哪條路，寫錯的地方其實高度重複，先看一輪最常見的坑，動手時能少繞不少路。
FAQ Schema 最常見的錯誤有哪些？
前面幾節埋下的伏筆，這裡收攏成一份清單，把最容易在動手時踩到的坑，拆成語法錯誤跟內容政策錯誤兩類，一類決定「能不能解析」，一類決定「符不符合規範」，是兩個不同層次的問題。
語法類錯誤，肉眼比較容易漏看：
mainEntity忘記包中括號：就算頁面只有一題，也要用陣列語法把它包起來，少了中括號會直接解析失敗。這是最常見的手殘失誤，因為視覺上「只有一題」讓人直覺以為不需要陣列。- JSON-LD 語法本身的小疏漏：少一個逗號、多一個全形引號、巢狀的大括號少一層，整段標記就會直接解析失敗。這種錯誤肉眼很難抓出來，要靠下一節的驗證工具找出來。
內容政策類錯誤，語法可能完全正確，但不符合規範：
- 標記內容跟頁面看得到的文字對不上：JSON-LD 裡寫了五題，頁面上卻只看得到三題，或者答案文字被改寫得比頁面上呈現的更長更完整，這是內容一致鐵則最常被忽略的地方，通常是編輯改了頁面內容，卻忘了同步改標記。
- 把 FAQ 藏起來，只給機器看：用 CSS 或 JS 把問答區塊在畫面上藏掉，只留 JSON-LD 給搜尋引擎讀，這違反內容政策。如果真的擔心版面太長，正確做法是用原生可展開收合的元件，例如 HTML 的
<details>搭配<summary>，讓內容在原始碼裡完整存在，只是預設收起、使用者點了才展開。 Question.name寫成關鍵字標籤，不是完整問句：例如只寫「售後服務」而不是「購買後多久內可以申請退換貨？」，機器沒辦法把幾個字當成一個完整的問題來處理。- 硬塞跟頁面主題無關的問答湊題數：為了塞關鍵字或衝題數硬掰幾題，答案空泛又跟頁面內容脫節，這種標記語法正確，也可能被判定為不具關聯性。
- 把 FAQPage 和 QAPage 搞混：網站自己寫的固定問答用 FAQPage；使用者可以自行提交答案的討論串型頁面才用 QAPage，兩者用錯了，結構化資料的定位就不對。
把這些坑記下來之後，寫完的標記對不對，還是得靠工具驗證，不能只靠肉眼確認。
怎麼驗證 FAQ Schema 有沒有寫對？
先講清楚一個現況變化，免得帶著過時的期待去用工具。Google 的複合式搜尋結果測試（Rich Results Test）已經在 2026 年 6 月拿掉 FAQ 的預覽卡片功能，不會再顯示「常見問題標記有效」這種綠色提示；但工具本身還在，依然可以拿它檢查 JSON-LD 語法有沒有解析錯誤，只是不會再產生 FAQ 的視覺預覽。
真正要驗證「符不符合 schema.org 規範」，該用的是 schema.org 官方自己的 Schema Markup Validator，這個工具不受 Google 拿掉 FAQ 顯示功能影響，專門檢查語法跟詞彙有沒有用對，跟 Rich Results Test 剛好是兩個不同的檢查層次，一個測的是 Google 產品願不願意採用，一個測的是 schema.org 這套詞彙本身有沒有寫對。
上線之後，還可以回頭看 Search Console 的「無法剖析的結構化資料」報表，確認 Google 讀取頁面時有沒有遇到解析錯誤。這份報表列出的是網站上因為嚴重語法錯誤而整段被跳過、讀不到的結構化資料，跟前面兩個工具比，它抓的是 Google 實際爬到網站時發生了什麼，比較晚才看得到結果，但也最貼近真實狀況。
把這三個工具串成一套簡單的流程：先用 Schema Markup Validator 檢查語法對不對，部署上線之後用 Rich Results Test 確認 JSON-LD 能被正確解析，再定期回頭翻一次 Search Console 的報表，看有沒有新出現的解析錯誤。
FAQ 複合式搜尋結果的版面消失了，但 FAQPage 標記本身沒有過期。與其糾結這個標記還值不值得做，不如先把語法寫對、放對頁面、避開前面列的幾個坑。而且這件事其實是一次性投入，語法固定，欄位就那幾個，設定一次之後，往後每次更新內容，只要記得同步改 JSON-LD 裡對應的文字就好，不需要每次都重新研究一遍該怎麼寫。