搜尋觀點
FAQ 結構化資料更新：FAQPage 仍應怎樣支援 SEO？
Google 對 FAQ rich results 的展示一直有調整，很多網站已經不能再把 FAQPage 當成穩定的搜尋結果版位。但 FAQ 本身沒有失去價值，真正要改的是使用方式。
FAQ 不等於排名捷徑
FAQPage 結構化資料只能描述頁面可見的問答內容，不能代替內容質量。若頁面只是堆一堆問題、沒有服務背景和清楚答案，就算加了 Schema，也未必帶來搜尋收益。
FAQ 對香港服務頁仍然有用
- 回答客戶最常問的價格、時間、流程和適合情況。
- 把長尾搜尋意圖自然放進頁面，而不是硬塞關鍵字。
- 用內鏈引導到 SEO、GEO、本地商家或工具頁。
- 減少 WhatsApp 和電話中重複解釋的成本。
結構化資料要和可見內容一致
如果頁面有 FAQ 區塊，可以用 FAQPage 或 Service 相關 Schema 輔助搜尋理解；但所有問答都應在頁面上可見，不能只寫在 JSON-LD 裏。
建議的 FAQ 寫法
每條 FAQ 先回答客戶決策問題，再補充限制條件。例如「SEO 多久見效？」不應承諾固定排名，而應說明取決於網站現況、競爭度、內容量和技術基礎。
下一步可以怎樣做？
如果你想把這篇內容套用到自己網站，可以先看 SEO 服務、GEO 服務，或用 SEO 工具中心 做初步檢查。需要人工判斷時，可以把網站 URL 發給 YUSIHK 做 SEO / GEO 技術診斷。
參考資料
先把「搜尋功能」與「頁面資訊架構」分開
FAQPage 結構化資料是否帶來豐富結果，與頁面上的問答是否值得保留，是兩件不同的事。Google 已限制 FAQ rich result 的顯示資格，絕大多數商業網站不應為了追求搜尋結果展開而大量加入 FAQPage 標記；但客人在服務比較、購買前準備或技術排錯時仍會有具體問題。答案應先為讀者而寫，schema 只是在符合條件時如實描述已可見的內容。
判斷一條 FAQ 是否應留在主頁面
適合放在服務頁的 FAQ，通常能幫讀者做下一步判斷，例如服務包括甚麼、不包括甚麼、需要準備哪些資料、回覆怎樣安排、跨語言或跨境情況怎樣處理。若問題其實需要長篇流程、不同角色的決策或獨立案例，應改寫成文章或子頁並由 FAQ 連過去。把每個關鍵字都偽裝成問題，只會令主頁越來越長且難以閲讀。
答案必須與客服、合約和表單流程一致
FAQ 最危險的不是語法錯，而是公開答案與實際服務不一致。更新前應由負責交付或客服的人確認：時程是否仍準確、服務範圍是否有例外、聯絡方式是否有效、價格是否可公開、是否涉及法律或平台規則。對「保證排名」、「一定被 AI 引用」這類不能兑現的說法，應改為說明可做的檢查、限制與衡量方式。
正確實作前，先檢查可見 HTML
若使用結構化資料，問題與答案要在使用者可見的 HTML 中完整呈現，不能只放進 JSON-LD。每頁只標記真正屬於該頁的問答，避免把同一組 FAQ 複製到數十個地區或服務頁。發布後以 Rich Results Test、頁面原始碼和 Search Console 驗證語法與索引狀態；即使沒有顯示豐富結果，清楚的可見問答仍可改善理解與內鏈路徑。
建立 FAQ 的季度維護節奏
將 FAQ 連同服務頁的事實表一起列入季度檢查：刪除已不適用答案、合併重複問題、把常被客服追問而頁面未回答的內容補進去，再檢查結構化資料是否反映可見文字。需要審視 canonical、頁面內容與 markup 的一致性，可使用 Schema 結構資料檢測 初步抽查；整體網站架構則可由 SEO 服務 規劃。