服務頁 FAQ 指南：問題排序、Schema 與 15 項驗收

直接答案：服務頁 FAQ 可以提高查詢機會，但不是因為加幾條問題就會「催成交」。有效 FAQ 要在讀者作決定前，直接處理適合度、範圍、流程、收費方式、時間、所需資料、風險、責任及下一步；答案必須與實際服務、Proposal、合約和銷售說法一致。先按真實售前問題排序，再把答案放在相應阻力附近，最後用 CTA、表單、合資格 Lead 與 CRM 結果驗證。FAQ、Schema 或 AI 摘要都不保證排名、Rich Result、查詢或成交。

文章目錄

服務頁 FAQ 在購買旅程中有甚麼角色？

讀者要完成的決定	應回答的問題	應放位置	下一步
判斷是否相關	適合／不適合哪些公司、情境及目標？	首屏答案及服務概覽之後	查看範圍或自我篩選
理解交付	包括甚麼、不包括甚麼、由誰負責？	Deliverables／流程旁	下載 Brief 或查詢
估算投入	如何報價、有哪些成本變數、要準備甚麼？	收費或方案區附近	提交最低報價資料
降低風險	時間、修改、延誤、權限、數據及終止安排？	流程、條款或表單之前	預約評估或索取 Proposal
核對證據	聲稱如何驗證、案例是否相似、結果有甚麼限制？	證據／案例之後	查看方法或證據來源
採取行動	下一步、回覆流程、所需欄位及資料用途？	CTA／表單旁	完成可預期的聯絡流程

FAQ 是服務頁的一層，不應取代核心內容。頁面仍要先清楚交代服務、對象、結果邊界、交付、證據及 CTA；完整骨架可參考Landing Page 發布清單及網站 CTA、表單、電話與 WhatsApp 指南。

FAQ 何時有用，何時只是掩飾頁面問題？

情況	判斷	優先處理
客服及 Sales 重複回答同一問題	有真實需求	核對答案後加入相應區塊
頁面沒有範圍、流程或價格資訊	不是 FAQ 問題	先補核心頁面內容
讀者在表單前大量離開	可能有未解阻力	研究訪談及表單數據，再提出假設
只因 SEO 工具建議「加 FAQ」	證據不足	不要製造沒人問的問題
答案與 Proposal 或 Sales 說法不同	高風險	先建立唯一事實來源與 owner
想靠 FAQPage Schema 取得大版位	目標錯置	保留可見答案；不要把 Rich Result 當 KPI

如網站已有流量但無查詢，應先用七層轉化診斷分清量度、意圖、訊息、信任、CTA、表單及跟進；FAQ 不能修正錯誤流量、壞表單或無人處理的 Lead。

應從哪裏收集真實售前問題？

不要由腦內「估」十條問題。建立 Question Evidence Log，每條問題記錄原句、來源、日期、對象、旅程階段、出現次數、商業影響及獲批答案。資料來源包括：

Sales discovery call、Proposal meeting、失標與延遲原因；
客服 Email、電話、WhatsApp、Chat 及售後問題；
網站搜尋、Search Console 查詢、Google Ads Search terms；
表單自由文字、CRM lost／disqualified reason；
客戶 onboarding、交收、修改及退款爭議；
法務、私隱、資訊保安、財務與營運審批問題；
可核實的競爭替代與採購問題，而不是抄競爭者答案。

Search query 只代表有人搜尋，不代表一定是客戶、適合放在服務頁，或答案應由 Marketing 決定。把搜尋訊號與 Sales／CRM 證據交叉核對，才可分辨高頻問題與高風險問題。

如何為問題排序？

維度	要問甚麼	建議證據
決策阻力	不回答會否令合適買家停步？	Call／Email／表單／頁面訪談
頻率	在同一受眾與服務中是否重複出現？	Question Log 標準化分類
風險	錯答會否造成合規、期望或交付爭議？	法務／營運／私隱審閱
自我篩選	答案能否幫不適合客戶及早退出？	Qualified／Disqualified reason
可回答性	能否用已批准事實清楚回答？	服務規格、報價規則、SLA、政策
維護成本	平台、價錢或政策變更後誰更新？	Owner、review date、change log

高頻但低影響的問題可以留在 Help Centre；低頻但高風險的責任、數據、牌照或付款問題，可能要在服務頁顯眼位置直接說明。

一條高質 FAQ 應怎樣寫？

用客戶語言提問：保留真實意圖，但合併只差一兩個字的近義問題。
首句直接回答：先寫「可以／不可以／視乎甚麼／我們不知道甚麼」，不要先講品牌歷史。
列明條件：服務類型、地區、方案、平台、資料完整度及批准速度會否改變答案。
交代範圍：包括、不包括、客戶責任、第三方責任及例外。
提供證據：連到服務範圍、政策、案例方法、官方文件或可核實資料。
標示限制：不要把估算、平台歸因或過往結果寫成保證。
給相稱下一步：查看方案、填 Brief、預約評估或閱讀詳頁；不要每題都硬塞「立即購買」。

可先用 40–80 字完成核心判斷，再按需要展開條件、例外與證據。這是編輯起點，不是搜尋引擎規則；複雜 B2B、法律、醫療或技術服務需要更完整說明。

收費、時間與成效問題應怎樣回答？

服務幾錢？

如有固定價、起步價或可核實區間，應說明幣別、單位、包含項目、稅項、第三方費用及有效日期。如必須客製報價，就列出影響價格的變數及所需資料，不要只答「歡迎查詢」。完整方法見服務頁價錢展示指南。

幾耐完成？

分開「預計工作期」、「由哪個事件開始計」及「會令時間改變的依賴」。素材、權限、審批、第三方平台及修改輪次未確定時，不應承諾固定完成日。

保證有幾多查詢或收入？

不要作無證據保證。說明可控制的交付、驗收、量度與改善流程，以及不可控制的市場、預算、競爭、平台、網站、銷售及資料限制。香港海關列明虛假服務描述及誤導遺漏屬不公平營商手法；所有聲稱應先核實。

FAQ 應放在頁尾、區塊旁，還是獨立頁？

版位	適合內容	優點	風險
相關區塊旁	收費、流程、證據、範圍疑問	在阻力出現時回答	頁面可能變長，要避免重複
頁尾 FAQ	跨區塊、次要及最後確認問題	集中掃讀	重要資訊可能埋得太深
獨立 Help／Policy 頁	長條款、技術、私隱、售後與大量問題	可維護及深入連結	離開服務頁後未必回來
文章／指南	需要完整教學、比較或診斷的問題	支援研究階段與內鏈	不應取代服務頁短答案

最穩妥是「短答案就地出現，複雜答案連到詳頁」。核心適合度、收費方式及資料用途不應只藏在收合元件、PDF 或客服對話內。

Accordion FAQ 如何兼顧手機與無障礙？

Accordion 可以減少捲動，但不是必須。若使用收合介面，應用原生 button 或正確 button role；鍵盤 Enter／Space 可開關，焦點順序正常，狀態以 aria-expanded 表示，並以 aria-controls 關聯答案。問題仍應是符合頁面層級的標題，答案在開啟後可選取、可複製、可縮放及可由輔助技術取得。

不要用沒有鍵盤行為的 div 假裝按鈕；
焦點樣式要可見，文字與圖示不要只靠顏色表達；
JavaScript 失敗時，重要答案仍應可讀；
不要一次建立太多 landmark region；
測試手機、鍵盤、螢幕閱讀器及 200% zoom；
避免打開答案時大幅移動 CTA 或造成版面跳動。

FAQPage、QAPage 與 Article Schema 應如何選？

類型	適合情況	不適合情況
FAQPage	網站自行提供多條固定問題及單一正式答案	問題或答案沒有在頁面可見
QAPage	一個問題，使用者可提交多個答案	公司自寫、沒有社群回答的服務 FAQ
Article／BlogPosting	以指南、分析或教學為主，FAQ 只是其中一節	把整頁錯標成產品或評論
Service	頁面主體是真實可提供的服務	一般教育文章只因提到服務便加上

結構化資料要代表可見主內容，不能加入頁面沒有的價格、評分、問題或聲稱。Google 已把 FAQ Rich Result 大幅限制在知名、權威政府及健康網站；一般商業網站即使標記正確，通常也不會顯示 FAQ Rich Result。Schema 可以保留語義，但不是曝光捷徑，Google 亦不保證任何 Rich Result。

服務頁 FAQ 如何支援 SEO、AIO 與 GEO？

FAQ 的價值是把真實決策問題、清晰答案、實體、條件、來源及下一步放進可索引文字。它可以支援搜尋與答案系統理解，但不應為每個 query 變體建立一條薄問題或一個新頁。Google 的 AI 搜尋指引亦提醒，不要為每個可能的 query fan-out 大量製造近義內容。

每條答案應連回唯一事實來源，標示服務地區、適用對象、資料日期及責任；內容治理可參考ITOB Group 編輯團隊及AI 搜尋內容改寫指南。這些做法不保證 AI 抓取、引用或推薦。

表單、私隱與 FAQ 要如何接合？

FAQ 若引導聯絡，就要把「會收甚麼、為何收、是否必填、誰處理、下一步及回覆流程」放在表單附近。不要要求讀者在自由文字欄輸入不必要的敏感資料。香港私隱專員公署的示例表單列出提供資料屬自願、資料用途、查閱／改正權及可能轉交對象；企業應按自身流程準備個人資料收集聲明，並由合適負責人審閱。

表單技術與成功訊號可參考表單提交追蹤指南；身份、流程、團隊、案例與私隱證據則見高價服務網站信任指南。

如何量度 FAQ 是否幫到決策？

不要只看 Accordion Click。先建立假設，例如「回答報價所需資料後，合適訪客較容易開始表單，而且無效報價查詢下降」。至少分開：

層級	指標	判讀限制
曝光	FAQ／問題進入視窗、頁面深度	看到不等於閱讀或認同
互動	展開、內鏈、複製、CTA click	Click 可能代表答案不清楚
表單	form_start、error、submit、成功頁	自動事件須驗證，不能假設準確
Lead	Valid、Qualified、Disqualified reason	要有一致定義與人工 QA
商業	Opportunity、Won、Lost、Cycle time	FAQ 只是多個影響因素之一
服務	重複問題、錯誤期望、爭議、客服工時	需分服務與時段比較

GA4 可用事件參數辨認哪條問題或 CTA 被操作，並用 Funnel exploration 查看頁面、表單開始與提交之間的流失；事件必須先經端對端驗證。完整月度分析見網站 Analytics 改善指南。

FAQ A/B Test 應怎樣做？

先選一個高價值頁面及一個可否證假設。
固定主要流量、Offer、表單與銷售定義；記錄同期改動。
只測關鍵答案、位置、可見／收合或 CTA 接合，不要一次全面改版。
事前定義主要指標、guardrail、最短觀察期及停止條件。
同時看 Valid／Qualified／Opportunity，不以展開率單獨決勝。
低流量頁配合訪談、客服問題及分批發布，清楚標示因果限制。

測試設計與決策規則可參考Landing Page A/B Test 指南。未做受控實驗時，只能說「改版後同時觀察到」，不能把全部轉變歸因於 FAQ。

30 日服務頁 FAQ 落地流程

第 1–3 日：選高價值服務頁，定義受眾、服務、主要 CTA 與 source of truth。
第 4–7 日：整理 Sales、客服、Search、表單、CRM 及爭議問題。
第 8–10 日：按阻力、頻率、風險、自我篩選、可回答性及維護成本排序。
第 11–14 日：由服務 owner、Sales、營運、私隱／法務按需要批准答案。
第 15–17 日：短答案放回相關區塊，複雜內容連至詳頁，刪除近義問題。
第 18–20 日：完成 Accordion 鍵盤、焦點、ARIA、手機及版面測試。
第 21–23 日：核對 Schema 與可見文字一致，不以 FAQPage 代替主體。
第 24–26 日：驗證 GA4、表單、電話／WhatsApp、CRM 及資料用途。
第 27–30 日：分批發布，建立 dashboard、owner、review date 及 change log。

15 項發布與月度驗收

每條問題有真實來源、受眾、階段、日期及 owner。
FAQ 不取代服務、範圍、流程、證據、收費與 CTA 主內容。
首句直接回答，其後列明條件、例外、責任與限制。
價錢、時間、資格、平台及成效聲稱均可核實。
答案與 Proposal、合約、Sales、客服及政策一致。
重要資訊放在對應阻力附近，不全部埋在頁尾。
長答案連到唯一正式頁，沒有建立大量近義薄頁。
Accordion 可用 Enter／Space，焦點、aria-expanded 及 heading 正確。
答案在手機、200% zoom、輔助技術及 JavaScript 失敗時仍可取得。
FAQPage／Article／Service／QAPage 按頁面主體選擇。
Schema 問題與答案和可見文字一致，沒有隱藏聲稱。
表單附近有資料用途、必填、下一步及私隱入口。
GA4 event／parameter、成功狀態及 CRM Lead ID 已驗證。
Dashboard 分開曝光、互動、Valid、Qualified、Opportunity 及 Won。
每月更新新增／消失問題，過期答案按 owner 及 change log 修正。

常見問題

服務頁應該有幾多條 FAQ？

沒有固定數量。只保留能處理真實決策阻力、可準確回答及有人維護的問題。三條高價值答案通常比十條通用答案有用；問題太多可分流到 Help Centre 或詳細指南。

FAQ 一定要放在頁底嗎？

不一定。價格、流程、風險與責任問題應在相關區塊附近回答；頁底適合最後確認或跨區塊問題。重要資訊不要只藏在收合元件。

加 FAQPage Schema 會否有 FAQ Rich Result？

通常不會。Google 現時把 FAQ Rich Result 限制在知名、權威政府及健康網站，而且任何 structured data 都不保證顯示。標記仍須與可見內容一致。

可以把同一組 FAQ 複製到所有服務頁嗎？

只應重用真正跨服務而答案完全相同的公司政策；服務範圍、價格、時間、責任及所需資料應按頁面改寫。大量複製會降低決策價值並增加過期風險。

Accordion 會否影響 SEO？

收合本身不是問題；關鍵是答案在頁面中可取得、可由 crawler 與使用者讀到，介面可用且 structured data 與可見內容一致。不要用互動元件隱藏核心資訊。

FAQ 展開率高是否代表成功？

不一定。高展開率可能表示問題重要，也可能表示主內容不清楚。要連同表單開始、有效提交、Lead 質素、商機、重複問題及客服負擔判讀。

官方資料與延伸閱讀

搜尋與結構化資料：Google：People-first content、Google：AI features content guidance、Google：Structured data guidelines、Google：FAQ Rich Result changes、Google：QAPage及Schema.org：FAQPage。

無障礙、量度與香港資料：W3C WAI：Accordion pattern、W3C WAI：Disclosure pattern、Google Analytics：Event parameters、Google Analytics：Lead form reporting、Google Analytics：Custom funnel report、香港私隱專員公署：Enquiry form 與收集聲明示例及香港海關：Unfair trade practices。

編輯與審閱：ITOB Group 編輯團隊；由ITOB Group 數碼營銷顧問團隊審閱。最後實質更新：2026 年 10 月 7 日。

本文按 Google Search Central、Google Analytics、Schema.org、W3C WAI、香港私隱專員公署及香港海關公開資料，以及 ITOB Group 的內容、網站、CRO、分析及驗收框架整理，不代表上述機構官方意見，亦不構成法律、私隱、無障礙或特定系統建議。平台、政策、Schema、法例及介面會更新；發布前應由服務、營運、Sales、私隱、法務、網站及數據負責人按實際情況核對。本文不保證搜尋排名、Rich Result、AI 引用、展開率、查詢、Lead、成交或收入；詳見編輯政策與資料更正原則。