Google Search Console
能量度甚麼、不能量度甚麼？

先知道每項資料的邊界

Search Console 可量度 URL 狀態與 Google Search 表現。它不能證明 AI 推薦原因、改版成效或所有使用者所見結果；資料必須分開解讀。

對剛開始建立量度制度的團隊，最重要的不是急於找一個「AI 分數」，而是先知道每一項資料能回答甚麼、不能回答甚麼。這樣才不會把尚未處理的 URL、暫時不足的樣本，或單次觀測誤寫成內容成效。

四種資料面：各自可以回答的問題

資料欄較闊：使用觸控裝置時，請向左或右滑動表格查看完整內容。

Google 說明，AI Overviews 與 AI Mode 仍建基於一般 Google Search 的索引、摘要資格、品質與技術要求；兩項功能可使用不同技術，回應與連結亦可能不同。符合資格並不是保證被抓取、收錄、展示或引用。

Cloudflare Web Analytics 如有啟用，則是本站的彙總訪問及效能量度面；它不屬於 Search Console，也不是 AI 回答或 Google Search 生成式功能的結果。它應另行保存和閱讀，不加入上表或任何「總 AI 成績」。

Search Console 的兩個常見誤讀

1. URL Inspection 與 Live Test 回答的不是同一件事

URL Inspection 的預設資料來自 Google 已收錄的版本；Live Test 則檢查目前 URL 能否被 Google 存取和處理。兩者都值得記錄，但 Live Test 的正面結果不代表該頁已在 Google Search 顯示。

對香港 B2B 團隊，實際做法是：先查服務頁、方法頁與最新 Insights 的可見正文、canonical 和已收錄狀態；如資料尚未出現，標示 pending 或 insufficient volume，不要用零代替未知狀態。需要逐條核對 URL 與來源時，可閱讀 AI 搜尋答案的來源，香港企業如何核對？。

2. 生成式報表有自己的範圍、延遲與資料品質限制

Google 逐步向部分 property 提供 Generative AI performance report。帳戶實際可見時，才可把它作為 Google Search 生成式功能的獨立檢視；它可按頁面、國家、日期與裝置閱讀，日期採 Pacific Time，最新資料亦可能是 preliminary。

它同時屬於 Search Console Performance 的 Web search type 資料。因此一般 Web performance 與生成式專用檢視要分開閱讀，不能相加，也不能當作兩組互不重疊的使用者。匯出時，畫面上的 ~ 或 - 可變成 0；內部報告必須保留 not available、preliminary 或 export limitation，避免把資料缺口誤讀為真正零曝光。

Google 已記錄 2026-08-13 至 2026-08-17 的 Search Generative AI performance report 有 logging error，reported impressions 可能偏低。若讀取期間覆蓋這些日期，且 property 實際有該報表，應標為 data_quality_exception；不要用它計算改版前後差異或歸因內容成效。此例外只適用於該生成式報表，不能外推至一般 Web performance、Cloudflare、Gemini、ChatGPT Search 或受控 observation。

不能據此下的結論，以及下一步

Search Console 不能單獨證明某個 AI 回答為何提及品牌、某次改版造成了甚麼結果，或所有使用者看到了甚麼。Google 對生成式 Search 的公開建議仍是讓網站具備正常的技術基礎，並提供對人有用、非商品化的內容；沒有另設 AI 專用檔案、special markup 或單一做法可保證生成式功能的露出、引用、流量或收益。

因此，FAQ、schema、sitemap 等只應按其正常的內容理解、資訊品質或索引目的處理，不能包裝成 Google AI 捷徑。下一步可先閱讀 CLEARCRAFT 的證據型量度方法、證據優先的量度原則 與 服務交付物與資料邊界，建立一份可核對的週期記錄，再決定哪一項內容或技術假說值得測試。