Google 釐清搜尋沒有單一的「頁面體驗排名分數」，Core Web Vitals 只是整體體驗其中一部分。香港 SME 應同時檢查手機顯示、HTTPS、廣告干擾、彈窗、首屏內容與表單互動；先改善真實客戶使用路徑，再用 Search Console、CrUX 和 PageSpeed Insights 量度，不能把滿分當成 AI 展示或排名保證。
Google 所說的頁面體驗不是一個總分
Core Web Vitals 只是其中一組訊號
Google 列出多項檢查：Core Web Vitals、HTTPS、手機顯示、廣告、干擾性插頁及主要內容辨識。Google 明確表示沒有單一的 page experience signal。良好的 Core Web Vitals 報告結果也不保證頁面排在搜尋前列，因為相關性和內容品質仍然重要。
不要把「100 分」當成 GEO 技巧
對生成式 AI 搜尋而言，企業需要一個能被人和系統理解、使用及核對的網站。只追逐實驗室分數，卻讓手機訪客找不到服務範圍、聯絡方法或表單，未必是合理優先次序。技術改善應服務真實任務，不是取得漂亮分數。
香港 SME 應先檢查哪條客戶路徑？
由手機首屏到聯絡完成
先用手機打開主要服務頁，記錄訪客看到首個重要內容所需時間，是否要關閉彈窗，是否能看清標題、價錢或服務範圍，以及 WhatsApp、電話和表單是否容易操作。檢查頁面在窄螢幕有沒有橫向溢出、按鈕是否被遮蓋、送出表單後是否有清楚回應。這些問題直接影響客戶下一步，也較容易排定優先次序。
HTTPS 與內容可辨識性同樣重要
網站應以 HTTPS 提供頁面，讓主要文字不被廣告、浮層或插頁遮住。Google 也要求訪客能分辨主要內容與其他元素。若服務資料只在大圖或載入後出現，或被 Cookie 視窗阻擋，應先處理可用性，不是只壓縮圖片。
按企業任務選擇優先頁面
SME 不一定要一次重做全站。可先選一個帶來合資格查詢的服務頁、一個案例頁及聯絡頁，檢查手機速度、互動和內容可讀性，再把有效做法推廣至其他範本。若有多個地區或服務版本，應分清重要頁面，避免被大量低價值 URL 分散資源。
如何正確理解 LCP、INP 與 CLS？
三個指標回答三種問題
Google 的 Web Vitals 文件把 LCP 用於 loading、INP 用於 interactivity、CLS 用於 visual stability。建議門檻是 LCP 2.5 秒內、INP 200 毫秒或以下、CLS 0.1 或以下。它們可把「網站很慢」拆成問題，但不能替代客戶測試或內容審核。
實地資料與實驗室測試不是同一回事
CrUX 使用匿名真實使用者資料，Search Console 和 PageSpeed Insights 可協助查看現場表現；Lighthouse 則較適合在開發階段找出可能的回歸。Web.dev 特別指出，沒有真實使用者互動時，Lighthouse 不能直接量度 INP，實驗室的 Total Blocking Time 只能作為診斷參考。一次測試不代表所有香港訪客。
管理層應如何安排改善而非追逐分數？
先處理阻礙業務的問題
若表單在手機無法送出、主要圖片推遲服務說明、彈窗遮住聯絡按鈕，應先於細微的分數優化。記錄頁面、日期、問題、改善方式及表單或詢問變化。這樣才能判斷技術工作是否真的改善客戶旅程，而不是只顯示報表顏色改變。
把技術體驗與內容一起驗證
速度良好但內容空泛，仍未能回答問題；內容完整但手機難用，也會削弱使用。GEO 的穩健做法是同時檢查可抓取的 HTML、清楚的服務資訊、手機可用性、HTTPS 和互動流程，再以 Search Console、網站分析及合資格查詢作整體觀察。任何改善都不代表 Google 或其他 AI 平台必然展示、引用或提高排名。