搜尋觀點
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、分析和查詢紀錄。
用 cohort 找共同缺口，不要用全站平均代替診斷
完成 page／query 拆分後，把 URL 按可解釋特徵分組，例如主題、搜尋意圖、模板、作者、發布時期、來源方式、語言、商業模式與內鏈層級。每組記錄受影響 URL 數量、更新前後 clicks、impressions、CTR、position、索引狀態與主要 query 變化，再選一組未受影響頁作對照。這個 cohort 方法的目的不是創造另一個品質分數，而是找出能被驗證的共同失敗模式。
| cohort 現象 | 較合理的調查方向 | 可驗收證據 |
|---|---|---|
| 同一比較模板普遍下跌，操作指南穩定 | 比較頁是否缺少實際測試、選擇條件、限制與更新責任 | 受影響組與對照組的 query／page 差異、內容增量及來源紀錄 |
| 不同主題但同一作者或供應流程一同下跌 | 來源核實、審稿門檻、作者責任或自動化流程 | 抽樣核對引用、作者資料、修改紀錄與 hard fail |
| 只有某語言或地區目錄下跌 | 本地意圖、翻譯品質、hreflang、canonical 或內鏈錯配 | 同語言 landing page、索引版本、查詢地區與使用者路徑 |
| 多個主題和模板同步持續惡化 | 才把範圍擴至全站定位、內容系統與信任責任 | 跨 cohort 的共同缺口，而不是單一全站平均曲線 |
平均排名尤其容易誤導：新出現的一批低排名 query 可以拉低平均，品牌 query 消失亦會改變整體組合。決策時要回到主要 query 原本由哪個 landing page 承接、現在由誰承接，以及頁面是否仍完成同一個讀者任務。
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 協助』不能替代這條責任鏈；是否披露及披露到甚麼程度，要按讀者合理會否想知道內容如何產生。
先設 hard fail，再談內容評分
內部評估可以幫團隊保持一致，但不應包裝成 Google 分數。較嚴謹的做法，是先設定不能被平均分掩蓋的 hard fail：捏造經驗、錯誤或無法追溯的引用、title 與內容不符、無法識別負責人，以及多條近義 URL 承接同一意圖。任何 hard fail 未修正，頁面都不應因其他項目表現良好便發布。
| 審核欄位 | 最低留檔 | 通過條件 |
|---|---|---|
| 讀者任務 | 這頁幫哪類人作哪個決定 | 不依賴關鍵字也能說明存在理由 |
| 搜尋意圖 | 主要 query、次要問題、代表 landing page | 同一意圖只有一條清楚的代表 URL |
| 資訊增量 | 原始資料、流程、限制、反例或獨立分析 | 不是把搜尋結果重新摘要一次 |
| 來源與責任 | 一手來源、資料日期、作者與核對人 | 關鍵主張可追溯，責任人可識別 |
| 技術入口 | HTTP 200、indexability、canonical、sitemap、主要內鏈 | 搜尋系統可找到並選擇正確版本 |
| 回看機制 | D0 基準、修改版本、D14／D28 判斷與停止條件 | 後續結論可由相同口徑重現 |
一個可驗收的 0／30／60／90 日復原節奏
- D0：保存基準，停止不可歸因改動。 記錄受影響頁、查詢、技術狀態、版本、部署日期與改動原因；不要同時更改 title、正文、URL、模板、內鏈和 CTA。
- 首 30 日：先修 hard fail 與一個代表 cohort。 先處理抓取、canonical、政策風險、捏造或過期主張；每次只選一組可對照頁面，真正重複才評估合併。
- 第 31 至 60 日：把修正變成內容系統。 明確誰核實來源、何時披露 AI／自動化、哪些商業主張要由 Owner 批准，以及發布後如何回看 query、page 與詢盤。
- 第 61 至 90 日：只擴展有證據的做法。 用相同窗口比較修復 cohort 與對照 cohort；先看抓取、索引與 query／page 對應，之後才看 clicks、CTR 和合資格查詢。
D7 可確認 Google 是否看見改動；D14 只判斷早期方向，資料不足便 DEFER，不追加近義頁；D28 及更長窗口才適合判斷 CONTINUE、DEFER 或 STOP。Google 說明，部分改善可能數日內出現，網站整體評估亦可能需要數月，甚至等到下一次核心更新，而且沒有恢復保證。90 日是管理節奏，不是排名承諾。
八種常見「HCU 修復」動作，為甚麼會令問題更難查
- 全部文章改一次日期：沒有實質更新的日期不能創造新鮮度，反而削弱信任。
- 為每頁硬加作者框：署名只有在作者真實負責、背景可核對時才有意義。
- 按固定字數擴寫：Google 沒有偏好字數；沒有新增決策價值的長文只會增加閲讀成本。
- 批量刪除低流量頁：低流量不等於無用，小眾支援頁仍可能完成清楚任務。
- 把所有 AI 內容刪掉：應查目的、來源、原創價值與人工責任，而不是隻查工具名稱。
- 一次改完整個網站：這會失去 cohort 對照，無法知道哪項修正有效。
- 只看第三方 visibility score：工具可作線索，但不能代替 GSC、索引與業務資料。
- 只等待下一次更新：若已有品質或政策缺口，等待不會替網站補來源或重建流程。
Google HCU 常見問題
Search Console 會顯示網站是否中了 HCU 嗎？
不會。Search Console 提供流量、查詢、頁面、索引、手動處置與安全問題等證據，但沒有 HCU 命中欄位或分數。
HCU 是懲罰或 manual action 嗎？
不是同一件事。核心排名變動屬自動系統評估；manual action 是人工確認違反垃圾內容政策，會在 Search Console 顯示並有獨立處理程序。
AI 生成內容會觸發 HCU 嗎？
工具本身不是判斷核心。政策風險在於主要為操控排名而規模化產生低價值內容；來源核實、獨有分析、作者責任與發布判斷仍不可省略。
修復後多久會恢復？
沒有固定時間或保證。應用 D0、D14、D28 及更長的同口徑窗口作判斷，不應對客戶承諾某天恢復。
香港網站應由哪一頁開始？
先選一條對生意或讀者最重要、而且有足夠證據的 URL。若問題是全站搜尋入口與頁面角色，可回到 Google SEO 香港主指南；若需要由團隊檢查技術、內容與商業承接的分工，可閲讀 Google SEO 首 90 日優先次序。只有在範圍、責任和驗收方法清楚後，才應考慮 SEO 服務 或進一步聯絡。