搜尋觀點
Google HCU 已經完結？網站流量下跌時，實用內容應該怎樣檢查？
網站流量下跌後，團隊很容易把原因濃縮成一句：『是不是中了 HCU？』這個說法現在會令診斷走錯方向。Google 已把原本稱為 Helpful Content Update 的系統納入核心排名系統；今天沒有一個獨立 HCU 開關、懲罰通知或公開分數，可以告訴你是哪一段文字拖低整個網站。
更有用的問題是：跌幅是否與已公佈的核心更新重疊？哪些查詢和頁面真正失去曝光？這些頁面是否仍然完成讀者來訪時的任務？還是抓取、canonical、改版、需求變化或競爭頁改善造成了相似現象？只有把這些問題分開，『改善內容』才會成為可驗收工作，而不是一次沒有邊界的全站重寫。
HCU 不是仍在單獨運作的更新名稱
Google 在 2022 年公佈 helpful content system，目的是讓原創、對人有用的內容較容易出現，而不是主要為搜尋流量製作的內容。到 2024 年 3 月，Google 表示內容實用性的判斷已演變並成為核心排名系統的一部分，會使用多種信號和系統，而不是一個單一分類器。
所以，把每次下跌都稱為『HCU hit』並不精確。核心排名系統主要在頁面層面工作，也會使用全站信號與分類器；全站有一些弱內容，不代表每一頁都必然排名差，反過來亦一樣。Search Console 不會提供『HCU 受影響』欄位，第三方工具聲稱的 HCU、authority 或 quality score 也不是 Google 公開的內部信號。
先分清四種看起來相似的跌幅
| 現象 | 先看甚麼 | 不要立即做甚麼 |
|---|---|---|
| 全站在核心更新附近持續下跌 | 同口徑 GSC 趨勢、受影響目錄、查詢意圖及 Google 更新時間 | 把單日波動當成懲罰，或每天改標題 |
| 只有少數頁失去曝光 | 相關查詢、排名頁變化、內容是否仍完整回答任務 | 把整個網站翻新，或增加近義頁互相競爭 |
| 改版、遷移或 URL 調整後下跌 | HTTP 狀態、robots、canonical、sitemap、內鏈與網址檢查 | 未確認技術訊號便重寫內容 |
| 曝光相若，點擊率下跌 | 搜尋結果版面、查詢意圖、title／description 與品牌需求 | 把 CTR 問題描述成全站內容品質問題 |
時間重疊只能建立調查起點，不能證明因果。Google 的核心更新是廣泛調整，不是針對某一網站或頁面；季節、品牌活動、新聞、競爭者更新和搜尋結果功能變化，都可能同時影響數據。
用 GSC 找出受影響的頁與查詢，不要尋找 HCU 報告
選擇更新前後兩個長度相同、資料完整的日期窗口，先比較 clicks、impressions、CTR 和 average position。然後按 page 和 query 拆分，找出變化集中在哪一個目錄、內容類型、國家、裝置或搜尋意圖。Search Analytics 會保留較主要的資料列，也可能因私隱和資料限制不顯示所有查詢；沒有查詢列不等於沒有任何搜尋。
- 先看規模與持續時間。 一兩天的波動不足以判斷；確認跌幅是否持續，是否只涉及某個頁羣。
- 把頁面和查詢配對。 找出原本由哪個 URL 承接查詢，現在是否換成站內另一頁或外部結果。
- 把索引證據分開。 用網址檢查核對 Google 所見的索引版本、最後抓取、使用者與 Google canonical；它不是即時網頁測試。
- 保留商業後果。 文章曝光下降、品牌查詢下降和服務詢盤下降不是同一件事，應分別記錄。
若只看一個第三方 visibility 曲線，很容易把估算的關鍵字集合當成完整站點表現。第三方資料可協助發現方向，但最終仍要回到網站自己的 Search Console、分析和查詢紀錄。
Who、How、Why 要落到頁面證據
Google 建議用 Who、How、Why 檢查內容。這不是在作者名稱旁加三個欄位便完成，而是讓讀者可以判斷資料由誰負責、如何得出，以及為何值得存在。
- Who：署名是否連到真實作者資料？作者的角色是否適合評論這個題目？服務承諾又由哪個團隊負責？
- How：比較、測試、案例或數據如何產生？若使用自動化或 AI，哪些部分由人核實，哪些限制需要披露？
- Why：頁面是否令既有或目標讀者完成一個任務，還是隻因某個詞有流量便批量生產？
E-E-A-T 不是一個可單獨優化的排名分數。Google 說明它使用多種信號識別經驗、專業、權威和信任的相關特徵，而信任尤其重要。頁面應把來源、作者、限制、更新責任和下一步說清楚，而不是重複寫『由專家審核』卻沒有可核對資料。
哪些內容值得重寫、合併、保留或刪除？
不要用字數、發布年份或目前流量作唯一準則。Google 明確表示，為了讓網站看起來『更新』而大量新增或刪除舊內容，並不會帶來預期好處；刪除應是最後手段。較合理的做法，是按內容能否被挽救及是否仍有讀者任務來決定。
| 決定 | 適用情況 | 最低驗收 |
|---|---|---|
| 重寫或重整 | 主題仍重要，但答案過時、缺乏來源、責任或可執行下一步 | 保留原 URL 角色，補充實質價值並記錄修改日期 |
| 合併 | 多條 URL 回答同一意圖，沒有各自需要保留的受眾或證據 | 先選主頁，再處理內容、內鏈、redirect、canonical 與 sitemap |
| 保留 | 內容仍準確、有獨立用途，只是短期沒有流量 | 確認可被發現、責任清楚，不為刷新日期而改動 |
| 刪除或停止索引 | 內容無法挽救、誤導、無人維護，或本來只為搜尋引擎批量製作 | 先評估使用者、外鏈、redirect／410 與合規影響 |
URL 合併是內容與技術共同決定，不應只因兩個標題相似就執行。若原頁仍承接不同市場、語言或決策階段，強行合併可能令讀者失去更合適的入口。
AI 內容的問題不是用了 AI，而是沒有責任鏈
Google 對生成式 AI 內容的要求仍回到準確、品質、相關性與反垃圾政策。AI 可協助整理訪談、分羣 GSC 查詢或提出待核實問題；但若自動化主要用來操控排名，大量建立沒有新增價值的頁面，可能涉及 scaled content abuse。
發布前應能回答：原始資料在哪裡、誰核實事實、哪些說法屬於分析、圖片和結構資料是否準確、誰批准商業承諾、錯誤出現後如何修正。單純加一句『本文由 AI 協助』不能替代這條責任鏈；是否披露及披露到甚麼程度，要按讀者合理會否想知道內容如何產生。
一個可驗收的 28 日復原節奏
- D0：保存基準。 記錄受影響頁、查詢、技術狀態、版本與改動原因，不同時推出多批無法分辨效果的修改。
- D7：確認 Google 是否看見改動。 抽查抓取、canonical、sitemap 與內鏈；新內容未有查詢列屬正常，不以此判定失敗。
- D14：看早期方向。 以相同口徑比較頁面與查詢；數據不足時選擇 DEFER，不追加近義頁。
- D28 及之後：判斷是否持續。 把搜尋表現、頁面行為和可跟進詢盤分開看，決定 CONTINUE、DEFER 或 STOP。
Google 提醒，實質改善可能在數日內出現，也可能需要數月讓系統重新學習和確認；沒有任何修改能保證排名回升。這正是要控制變更範圍、保留基準和等待完整窗口的原因。
香港網站應由哪一頁開始？
先選一條對生意或讀者最重要、而且有足夠證據的 URL。若問題是全站搜尋入口與頁面角色，可回到 Google SEO 香港主指南；若需要由團隊檢查技術、內容與商業承接的分工，可閲讀 Google SEO 首 90 日優先次序。只有在範圍、責任和驗收方法清楚後，才應考慮 SEO 服務 或進一步聯絡。