FAQ Schema 結構化資料實作教學
FAQ Schema 是把網頁上的問答內容，用結構化資料（JSON-LD）標記給搜尋引擎與 AI 看的一種格式。這篇是給實作者看的操作教學：你會拿到可以直接複製的 JSON-LD 範本、學會三種上線做法、用 Rich Results 測試驗證，並且搞懂在 2026 年它到底還值不值得做。重點不是把語法背起來，而是把它放對地方、避開那幾個會讓整段標記失效的雷。
- 2026 年 Google 已停用 FAQ 星級摘要
- FAQ schema 對 AI 摘要與引用仍有保留價值
- 三種做法：手動、外掛、工具各有取捨
- 複製範本後務必用 Rich Results 測試驗證
- 頁面看不到的問答不要硬塞進標記
FAQPage 是什麼：先把名詞搞清楚
在動手寫程式碼之前，先把三個常常被混用的名詞分清楚，否則後面很容易標錯型別。FAQPage 是 schema.org 定義的一種頁面型別，用來描述「一頁裡面有一組問題與答案、而且每個問題只有一個官方答案」的內容。它底下會包含若干個 Question（問題），每個 Question 底下再掛一個 acceptedAnswer（被接受的答案），答案的本體則是 Answer 型別的 text 屬性。整個結構是「FAQPage 包住 Question 陣列，Question 包住 Answer」這樣一層一層套進去。
結構化資料的意思，是用一套標準化的格式，把頁面上「人看得懂」的內容，翻譯成「機器也讀得懂」的標籤。Google 官方在〈結構化資料總覽〉裡講得很直接：它本身不會直接幫你提升排名，但能幫搜尋引擎更精準地理解頁面在講什麼，進而有機會以更豐富的形式呈現。對 FAQ 來說，這個「翻譯」動作就是告訴 Google：這一段是問題、那一段是答案，它們是成對的。
這裡要特別提醒一個容易搞錯的地方：FAQPage 和 QAPage 是兩種不同的型別。FAQPage 用在「官方給出唯一答案」的常見問題頁，QAPage 則用在「使用者可以投稿多個答案」的論壇式頁面。如果你把討論區那種一問多答的頁面標成 FAQPage，就是用錯型別，Google 反而會判定不符規範。想確認自己的內容屬於哪一種，可以直接對照 schema.org 官方〈FAQPage〉定義頁，上面把每個屬性的用途都列得很清楚。
選哪一種標記語言？schema.org 同時支援 JSON-LD、Microdata、RDFa 三種格式，但 Google 在〈結構化資料總覽〉裡明白建議優先使用 JSON-LD。原因是它把標記獨立放在一段 script 裡，不會跟頁面上的文字交纏在一起，維護起來最不容易出錯，也最適合大量套用。本文後面所有範例都會用 JSON-LD，因為這是現在的主流，也是最好教、最好改的做法。
先想清楚你要標的是「官方唯一答案」還是「使用者投稿多答」，型別選錯，後面語法寫得再漂亮都是白工。
這件事多數教學沒講：2026 年它還能不能用
多數教學沒講清楚的，是 2026 年這個關鍵的轉折，結果讓很多人卡在「FAQ Schema 是不是已經沒用了」這個迷思裡。先把事實講白：根據 Google Search Central 官方〈FAQ 結構化資料〉文件明載，自 2026 年 5 月 7 日起，FAQ 複合式搜尋結果（也就是過去那種在搜尋結果下方展開的問答星級摘要）已不再出現於 Google 搜尋；Google 並將在 2026 年 6 月撤除 FAQ 的搜尋外觀、複合式結果報表，以及 Rich Results 測試裡的支援，Search Console API 的相關支援則於 2026 年 8 月停止。
很多人看到「停用」兩個字就直接把所有 FAQ schema 砍掉，這是反應過度。要分清楚兩件事：Google 停用的是「FAQ 在搜尋結果頁的視覺呈現」，不是「FAQPage 這個型別」。FAQPage 仍然是 schema.org 上合法、有效的型別，Google 官方文件也說，網站不需要急著移除既有的 FAQ 結構化資料，因為沒被使用到的結構化資料並不會對搜尋造成問題。真正消失的是那顆星級摘要，FAQ schema 這套標記本身依然站得住腳。
那它現在的價值在哪裡？答案是：從「搜尋結果上的裝飾」轉向「內容理解的基礎建設」。當你把問答用結構化資料明確標出來，等於是用機器最容易解析的方式，把「這是一組成對的問與答」這個語意送出去。這對 AI 摘要、ChatGPT、Perplexity 這類會解析開放網頁的系統來說，是相當乾淨的訊號——它們在生成回答、挑選引用來源時，能更快定位到一段結構清楚的問答。Bing、Perplexity 等檢索式爬蟲仍然會抓取並解析這些標記，這部分價值並沒有隨著 Google 星級摘要一起消失。
不過這裡要誠實面對一個 Google 官方的提醒，避免你把它過度神化。Google〈為生成式 AI 搜尋進行最佳化〉官方指南明確指出，結構化資料並非生成式 AI 搜尋的必要條件，也沒有什麼特殊的 schema.org 標記是非加不可的——但同一份文件也接著說，仍然建議把結構化資料納入整體 SEO 策略的一環，因為它有助於符合複合式搜尋結果的資格。換句話說，FAQ schema 不是讓 AI 引用你的保證，但它是一個低成本、不會扣分、又能讓內容更好被理解的基礎動作。把它定位成「該做的清潔工作」而不是「神奇開關」，心態就對了。
如果你正在重新檢視整體的 AI 搜尋佈局，FAQ schema 只是其中一塊拼圖。想把答案寫得更容易被 AI 摘錄，可以延伸閱讀我們的〈先給答案的 AIO 寫作法〉；想理解 AI Overviews 整體運作邏輯，則可以參考〈AI Overviews 全攻略〉。兩篇搭著看，就不會把賭注全押在單一一段標記上。
三種做法：手動 JSON-LD、外掛、工具
要把 FAQ schema 放到頁面上，主流有三條路：手動寫 JSON-LD、用 CMS 外掛自動產生、用線上生成器產碼後貼上。三種沒有絕對的好壞，差別在於你對程式碼的掌控度、網站規模，以及未來維護的人是誰。先講共通的核心：不論哪種做法，最後都是要在頁面裡放一段 <script type="application/ld+json">，裡面是符合 FAQPage 結構的 JSON。差別只在這段 script 是你手刻、外掛吐出來、還是工具幫你產的。
第一種是手動 JSON-LD。你自己寫好那段 script，放進頁面的 head 或 body 都可以。好處是完全可控，要標哪幾題、答案怎麼寫，一字不差都在你手上，也最不會有外掛塞進多餘屬性的問題。缺點是改一題就要動一次程式碼，題目多、頁面多的時候維護成本高，而且手刻最容易打錯引號、漏逗號。
第二種是CMS 外掛，例如 WordPress 上的各家 SEO 外掛。Google 官方在〈結構化資料總覽〉裡也建議，使用 Wix、WordPress、Shopify 這類 CMS 的人，往往沒辦法直接改 HTML，這時用整合進 CMS 的外掛會更省事。好處是改內容時在後台編輯器裡填一填就好，schema 會自動同步產生，不用碰程式碼；缺點是你被外掛的格式綁住，有時候它會多塞一些你沒打算標的屬性，升級或換外掛時也可能整批失效。
第三種是線上生成工具。你在工具的欄位裡輸入問題與答案，右邊就會即時吐出一段 JSON-LD，複製貼到頁面即可。好處是零學習成本、最快上手；缺點是它只負責「產碼」，產完之後的貼上位置、跟頁面內容是否一致、未來更新，全都要你自己顧，容易出現「工具產的碼跟頁面實際內容對不上」的狀況。下面這張表把三種做法的取捨整理出來，方便你按自己的情況選。
| 比較項目 | 手動 JSON-LD | CMS 外掛 | 線上生成工具 |
|---|---|---|---|
| 上手難度 | 較高，需懂 JSON 語法 | 低，後台填表即可 | 最低，輸入問答就好 |
| 內容與標記同步 | 需自己維持一致 | 自動同步，最省心 | 需手動再貼一次，易脫鉤 |
| 掌控度 | 最高，一字不差可控 | 中等，受外掛格式限制 | 中等，產完就脫離工具 |
| 大量頁面維護 | 累，逐頁改 | 佳，套版自動帶入 | 差，無法批次管理 |
| 適合對象 | 工程資源、靜態站 | WordPress 等 CMS 站 | 單頁、臨時、想快速試 |
我給多數中小企業的建議很單純：網站如果是 WordPress 這類 CMS，優先用整合度高的外掛，讓內容與標記自動同步，省下最容易出錯的人工環節；如果是工程團隊維護的客製站，手刻 JSON-LD 並做進模板，掌控度最好；至於線上工具，適合拿來「快速產一段試水溫」或臨時補單頁，不建議當成長期的主力做法。
選做法的關鍵不是哪個最潮，而是「未來改內容的人能不能維持標記與頁面一致」，這才是 schema 不出錯的根本。
這件事多數教學沒講：可直接複製的範本與 5 個實作錯誤
多數教學沒給的，是一份能直接複製、又把眉角標好的乾淨範本，外加把最常見的踩雷一次講透。先給範本。下面這段就是一個最小可用的 FAQPage JSON-LD，你只要把問題與答案換成自己的內容，放進頁面即可。注意：為了不和本頁真正生效的 schema 衝突，下面範例裡的角括號都已做 HTML 跳脫，你複製到自己的編輯器後，會正常顯示成真正的角括號。
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "你們的退貨期限是幾天？",
"acceptedAnswer": {
"@type": "Answer",
"text": "商品到貨後七天內可申請退貨，商品需保持全新未使用狀態並附上完整包裝。"
}
},
{
"@type": "Question",
"name": "可以指定到貨時段嗎？",
"acceptedAnswer": {
"@type": "Answer",
"text": "可以。結帳時於備註欄填寫希望時段，我們會在出貨前盡量配合，實際時間以物流為準。"
}
}
]
}
</script>答案裡如果需要連結或清單，Google 文件說明 Answer 的 text 可以包含部分 HTML 標籤，例如 <a>、<p>、<ul>、<li>、<br> 等。要注意的是，當你把 HTML 寫進 JSON 字串時，這些角括號同樣需要適當處理。下面這段示範如何在答案裡安全地放一段含連結的 HTML：
{
"@type": "Question",
"name": "要怎麼查詢出貨進度？",
"acceptedAnswer": {
"@type": "Answer",
"text": "<p>登入會員後，到「我的訂單」即可查看物流狀態。</p><ul><li>已付款</li><li>已出貨</li><li>已送達</li></ul>"
}
}範本給完，接下來是重頭戲——最常見的五個實作錯誤，每一個都會讓你的標記被判定無效或被忽略。這些不是理論，是實際送驗時最常跳出來的問題。
錯誤一：頁面上根本看不到這些問答。這是頭號大雷。Google 官方規範白紙黑字寫著，所有 FAQ 內容都必須是使用者在來源頁面上可見的。如果你只在 script 裡標了問答，但頁面上完全找不到對應的文字，這叫做「標了使用者看不到的資訊」，直接違反結構化資料準則。正確做法是：頁面要有真正的問答區塊（答案藏在可展開的折疊區裡是允許的，只要點開看得到），script 只是把這些可見內容再標一次。
錯誤二：JSON 語法寫壞了。多一個逗號、少一個引號、括號沒對齊，整段 JSON 就會解析失敗，Google 直接當作沒這段。手刻最容易中這個。常見的有：最後一個物件後面多了逗號、用了中文的全形引號而不是半形雙引號、字串內的雙引號沒有跳脫。這五個錯誤裡有一半以上其實都是人為的打字失誤，不是觀念錯，而是手滑。
錯誤三：型別用錯，把 QAPage 的內容標成 FAQPage。前面提過，使用者可投稿多個答案的頁面應該用 QAPage。把論壇、商品問答區那種一問多答的頁面硬標成 FAQPage，會被判定不符使用情境。實作前先回頭確認你的內容型態，對照 schema.org 官方〈Question〉型別定義裡的屬性說明，確認 acceptedAnswer 真的是「唯一被接受的答案」。
錯誤四：拿 FAQ schema 來做廣告或塞促銷。Google 規範明文禁止把 FAQPage 用於廣告目的。答案裡塞滿「現在下單享八折」「限時優惠快來搶」這類促銷話術，或是問題根本是為了行銷而硬湊的，都可能被視為濫用。答案要真的在回答問題，不是拿來當廣告版位。
錯誤五：同一組問答在全站重複標記。如果同一組 FAQ 出現在很多頁面，Google 建議整站只標記其中一個實例就好，不要每頁都標一份相同的問答。重複標記不會加分，反而可能造成混亂。把它收斂到一個最合適的頁面，效果最乾淨。
標記裡的問答，必須跟頁面上使用者看得到的內容完全一致——這一條做對，五個雷裡最致命的一個就先排除了。
用 Rich Results 測試與 Schema 驗證器把關
程式碼放上去不等於做完，一定要驗證。最常用的官方工具是 Google 的 Rich Results 測試（複合式搜尋結果測試）。使用方式很簡單：到 Google Rich Results 測試工具，貼上你的網址或直接貼程式碼，它會解析並告訴你語法有沒有錯、有沒有缺必填欄位。要注意的是，前面提到 Google 將在 2026 年 6 月撤除 Rich Results 測試裡對 FAQ 的「複合式結果預覽」支援，所以你可能不會再看到那個星級摘要的預覽畫面——但這個工具仍然能幫你檢查 JSON-LD 的語法是否合法、結構是否正確，這部分的把關功能還在。
除了 Google 的工具，還有一個常被推薦的官方資源是 Schema.org 自家的 Schema Markup Validator（結構化資料驗證器），它不綁定特定搜尋引擎的複合式結果，純粹檢查你的標記是否符合 schema.org 詞彙規範。當你想確認「我這段標記在 schema.org 標準下到底合不合法」，用它最直接。實務上的順序我會這樣排：先用 Schema 驗證器確認語法與型別正確，再用 Rich Results 測試確認 Google 能不能正常解析。兩道關卡都過，才算真的上線。
驗證完上線後，別忘了用 Search Console 的網址審查工具，看看 Google 實際抓到的頁面長什麼樣、有沒有被 robots.txt 或 noindex 擋住。要記得，Google 官方提醒過：頁面從發布到被重新抓取、重新索引，可能要等上好幾天，所以驗證工具顯示正常之後，不必急著反覆送出，給它一點時間。想把整個結構化資料的運作邏輯補齊，可以參考 Google Search Central〈結構化資料總覽〉，這份是理解底層規則的最佳一手文件。
該放在哪些頁面：適合與不適合的情境
不是每一頁都該硬塞 FAQ schema。放對地方，它是加分；放錯地方，反而是製造維護負擔。先講適合放的：第一是真正的常見問題頁，例如客服 FAQ、產品使用問答、服務說明的常見疑問，這些本來就是一問一答的結構，標記起來最自然。第二是商品或服務頁底部的問答區，當頁面上確實有一塊「關於這項商品/服務的常見問題」，把它標起來很合理。第三是教學或指南型文章末尾的 FAQ 段落，像本文這樣，把讀者最常問的延伸問題收成一區。
不適合放的情境也要記清楚：第一，頁面上根本沒有可見問答、只是想騙標記的，絕對不要。第二，使用者可以投稿多個答案的論壇、商品問答區，那是 QAPage 的地盤。第三，純粹為了行銷、把促銷話術包裝成問答的，違反規範。第四，同一組問答已經在別頁標過了，這頁就別重複標。判斷原則其實很簡單：這一頁上真的有一塊使用者看得到、而且是官方唯一答案的問答嗎？是，就標；不是，就別硬上。
如果你正在規劃整個網站的主題架構，FAQ 區塊其實可以和主題群集策略搭配：把同一主題下使用者最常問的問題，集中收斂到群集的支柱頁或相關文章末尾，既服務讀者、又讓結構更清楚。這部分可以延伸閱讀我們的〈為 AIO 打造主題群集〉，把 FAQ 放進更大的內容地圖裡思考。想更完整掌握 Google 支援哪些結構化資料型別，也可以參考 Google〈結構化資料功能總覽〉，看看除了 FAQ 之外，還有哪些型別適合你的頁面。
第一手經驗：替客戶網站加上去之後
講點實戰。我們替一個做居家清潔服務的客戶，在他的服務說明頁與三篇教學文章末尾，補上了符合規範的 FAQ schema。當時正好卡在 2026 年 5 月那波 Google 停用 FAQ 星級摘要的節點上，所以我們從一開始就跟客戶講清楚：別期待搜尋結果下方再長出那排可展開的問答，那個功能已經沒了。我們的目的不是搶星級摘要，而是讓內容對 AI 摘要與引用更友善。
實際的變化有兩個層面。在 Google 搜尋這邊，誠實說，自然點擊與排名沒有出現可歸因於 schema 的明顯跳升——這完全符合 Google「結構化資料不直接影響排名」的說法，我們本來也沒指望。但在 AI 引用這一塊，倒是觀察到一些值得記錄的跡象：客戶用自家幾個核心問題（例如「居家清潔要先清空櫃子嗎」）去問 ChatGPT 和 Perplexity 時，原本回答裡幾乎不會帶到他的網站，後來在內容與 schema 都整理過、答案寫得更乾淨之後，被帶到、被引用的機率有上升。這裡要很小心地說：我沒辦法把這個改善「單獨歸因」給 schema，因為我們同時也把答案重寫得更直接、更結構化了，兩件事是一起做的。比較合理的結論是：schema 加上「答案寫法本身變好」，整體讓內容更容易被 AI 取用。
踩過的雷也分享一個最深刻的。有一次我們用線上工具產了一段 FAQ JSON-LD 貼上去，送 Rich Results 測試一直顯示語法錯誤，查了老半天，最後發現是工具產出時把一個答案裡的半形雙引號直接吃進字串卻沒跳脫，整段 JSON 就壞了。從那次之後，我們的標準流程就變成：工具產的碼，貼上前一律先過一次 Schema 驗證器，確認語法乾淨才上線，絕不直接信任工具的輸出。另一個常踩的，是 CMS 外掛升級後格式悄悄變了、舊文章的標記整批失效，所以我們會定期回頭抽幾頁重驗。這些都是流程上的小動作，但能省下你之後抓 bug 的大量時間。
schema 本身不會憑空帶來流量，但把它跟「答案寫得更好」一起做，內容被 AI 取用的機率確實會改善。
結論：把 FAQ Schema 當基礎建設來經營
把整篇收束起來。FAQ Schema 在 2026 年的定位已經很清楚：它不再是搜尋結果上那顆會發光的星級摘要，而是一段讓搜尋引擎與 AI 系統更容易讀懂你問答內容的基礎標記。Google 停用的是視覺呈現，不是這個型別本身，所以既有的標記不用急著拆，新的內容也仍然值得標——前提是你要用對型別、放對頁面、把標記跟頁面上看得到的內容對齊，並且每次上線都經過 Rich Results 測試與 Schema 驗證器的把關。
實作上記住三件事就夠：第一，選做法時以「未來維護的人能否維持標記與內容一致」為準，CMS 站優先用外掛、客製站可手刻、工具只拿來快速試。第二，避開那五個最常見的雷，尤其是「頁面看不到的內容別硬塞」和「JSON 語法別手滑打壞」。第三，心態要對——它是該做的清潔工作，不是讓 AI 一定引用你的魔法開關，真正的底氣還是來自內容本身夠好、答案夠直接。把這些都做到，FAQ Schema 就會穩穩地成為你內容基礎建設的一塊，安靜地在你看不到的地方幫內容加分。
常見問題 FAQ
FAQ Schema 在 2026 年還值得做嗎？
值得，但目的變了。Google 已於 2026 年 5 月停用 FAQ 星級摘要，所以別再為了搜尋結果上的視覺呈現而做。現在做它的理由，是讓問答內容更容易被 AI 摘要與檢索式爬蟲解析。它不直接影響排名，但屬於該做的基礎建設。
FAQPage 和 QAPage 有什麼不同？
差在答案的來源。FAQPage 用於「官方提供唯一答案」的常見問題頁，QAPage 用於「使用者可以投稿多個答案」的論壇式頁面。把一問多答的頁面標成 FAQPage 就是用錯型別，會被判定不符規範，實作前一定要先分清楚。
FAQ JSON-LD 要放在頁面的哪個位置？
放在 head 或 body 都可以，Google 兩者都讀得到。重點不是位置，而是這段 script 裡標的問答，必須跟頁面上使用者看得到的內容一致。頁面上沒有可見問答卻硬標，會違反結構化資料準則。
程式碼貼上去後怎麼確認有沒有生效？
先用 schema.org 的 Schema 驗證器確認語法與型別合法，再用 Google 的 Rich Results 測試確認能正常解析，最後用 Search Console 網址審查看 Google 實際抓到的版本。要注意 2026 年 6 月後 FAQ 的複合式結果預覽會被撤除，但語法檢查功能仍在。
最常見的 FAQ Schema 實作錯誤是什麼？
最常見也最致命的，是標記裡的問答在頁面上根本看不到。再來是 JSON 語法手滑打壞，例如多餘逗號、用了全形引號、字串內雙引號沒跳脫。另外還有型別用錯、拿來塞促銷、同組問答全站重複標記，這五個是送驗時最常跳出的問題。
