什麼是關鍵字蠶食？GSC 的數據定義
關鍵字蠶食（Keyword Cannibalization）指的是你網站上的兩個或更多頁面，同時針對同一個搜尋查詢（Query）在 Google 搜尋結果中獲得曝光。在 Google Search Console（GSC）的「查詢效能」報表中，這具體表現為單一的「查詢」對應到多個不同的「網址」。當這種情況發生時，會分散使用者的點擊、混淆演算法對「代表文件」的判斷，最終可能導致整體的排名與點擊率（CTR）下滑，削弱你頁面的搜尋能見度。
從 GSC 的數據結構來看，報表提供了查詢、網址、曝光、點擊、CTR 和平均排名等欄位。當你篩選某個查詢時，如果看到多個網址出現在結果中，這就是潛在蠶食的信號。理解這個定義，是建立「Query-Page 蠶食矩陣」、進行後續診斷的基礎。
步驟一：建立 Query-Page 蠶食矩陣
要識別潛在的關鍵字蠶食，你可以透過 GSC 建立一個「Query-Page 蠶食矩陣」。首先，進入 GSC 的「查詢」效能報表，將日期範圍設定為足夠長的時間區間（例如涵蓋多個完整週期，以確保樣本穩定，實際長度可依網站流量調整），並參考 Google Search Console 說明文件 確認「查詢」與「網址」欄位的定義。接著，新增篩選器，讓「查詢」包含你懷疑有蠶食主題的關鍵字或詞組。完成篩選後，將結果匯出為 Google 試算表。
在試算表中，你可以使用 COUNTIF 函數來計算每個「查詢」對應的「網址」數量。例如，若某個查詢對應到兩個以上網址，它就會被列入「潛在蠶食清單」。這份清單是後續分析的起點，能幫助你快速鎖定需要深入檢查的查詢與頁面組合。下表為篩選流程的具體步驟與輸出格式：
| 步驟 | 操作 | 輸出 |
|---|---|---|
| 1 | 進入 GSC「查詢」效能報表，設定日期區間 | 原始查詢績效數據 |
| 2 | 新增篩選器：查詢包含主題詞 | 相關查詢與網址組合 |
| 3 | 匯出為試算表 | CSV / 試算表檔案 |
| 4 | 使用 COUNTIF 計算每查詢對應的網址數 | 潛在蠶食清單（查詢、網址數、總曝光） |
| 5 | 設定曝光門檻（根據實際數據分布） | 聚焦流量較大的查詢，過濾低量噪音 |
步驟二：區分「真蠶食」與「假性重疊」
並非所有在 GSC 中看到的多網址情況都是真正的內容蠶食。你需要排除技術性造成的「假性重疊」。具體來說，檢查清單包括：第一，網址參數不同（例如 ?page=2 分頁），這些是同一頁面的不同版本；第二，帶有追蹤參數（如 utm_source）的網址，這些屬於行銷追蹤，不影響內容判定；第三，已正確設定 canonical 標籤，且該標籤明確指向主要頁面，相關技術細節可參考 Google 搜尋中心關於重複內容的說明；第四，不同語言或地區版本的頁面（例如 example.com/tw 與 example.com/hk），這些是針對不同受眾的獨立設定。
完成這些排除後，剩下的查詢與網址組合才是需要進一步診斷的「真蠶食」候選者。這一步驟能避免你浪費時間在無害的技術重複上，確保分析聚焦於真正的內容策略問題。
步驟三：辨識「代表文件切換」跡象
辨識 Google 是否在進行「代表文件切換」，是確認關鍵字蠶食的關鍵。你可以觀察 GSC 中「平均排名」的時間序列數據（建議以週或月為單位）。具體操作是，針對每一個「真蠶食」候選的查詢，查看其關聯頁面的排名走勢。如果出現以下模式：頁面 A 的排名在某個時間點下降時，頁面 B 的排名同步上升，且兩者的曝光量呈現此消彼長的關係，這強烈暗示 Google 正在該查詢上測試不同的「代表文件」。下圖以表格形式呈現一個典型的時間序列範例：
| 週次 | 頁面 A 平均排名 | 頁面 B 平均排名 | 曝光變化 |
|---|---|---|---|
| W1 | 5 | 8 | A 穩定 |
| W2 | 6 | 7 | A 微降，B 微升 |
| W3 | 8 | 4 | A 明顯掉落，B 明顯上升 |
| W4 | 9 | 3 | 此消彼長持續 |
這種排名震盪的現象，是蠶食的明確證據。透過時間序列分析，你可以將問題從靜態的數據對比，提升到動態的行為觀察，從而更準確地診斷蠶食的嚴重程度與影響範圍。
步驟四：輔助指標——CTR 異常分析
除了排名變動，CTR（點擊率）也能提供輔助證據。計算你在「潛在蠶食清單」中每個查詢的整體 CTR（總點擊次數除以總曝光次數）。然後，將這個整體 CTR 與基準進行比較，例如該查詢下單一頁面的歷史最佳 CTR，或是同類型查詢的平均 CTR。如果整體 CTR 顯著低於基準，即使曝光量穩定，也可能表示搜尋結果中出現多個你的頁面，導致使用者注意力分散，點擊率被稀釋。
CTR 異常分析能佐證蠶食帶來的實際影響。當多個頁面競爭同一查詢時，搜尋結果頁面會呈現更多你的連結，這反而可能降低使用者點擊任一頁面的意願。將此指標納入診斷，能讓你更全面地評估問題。
診斷後行動：根據類型決定策略
完成診斷後，你需要根據蠶食類型採取相應行動。主要分為三類，可參考以下決策樹：
- 節點 1：是否為技術性重疊？（參數、canonical）
- 是 → 檢查 canonical 設定與內部連結權重分配，確保技術正確。
- 否 → 進入節點 2。
- 節點 2：是否為「完全重疊」？（內容高度雷同）
- 是 → 選定代表文件，整併內容，舊頁面設置 301 轉址或 canonical 指向代表文件。
- 否 → 進入節點 3。
- 節點 3：是否為「部分意圖重疊」？（內容有交集但側重點不同）
- 是 → 重新明確各頁角色，調整標題、H1，並強化內部連結，區隔搜尋意圖。
- 否 → 重新檢視是否遺漏其他因素，必要時回到步驟一。
完成診斷後，你需要根據蠶食類型採取相應行動。主要分為三類：第一，若為「完全重疊」，即兩個頁面內容高度雷同，應選定一個「代表文件」，將另一頁的內容整合進來，並對舊頁面設置 301 轉址或使用 canonical 標籤指向代表文件，以集中權重。第二，若為「部分意圖重疊」，即內容側重點不同但有交集，應重新審視頁面角色，透過強化內部連結、調整標題與 H1，明確每頁的搜尋意圖焦點，避免混淆。
第三，若已排除假性重疊但仍有技術性問題，則確保 canonical 設定正確，並檢查內部連結結構是否合理分配權重。這個行動框架能幫助你將診斷結果轉化為具體優化步驟，有效解決蠶食問題。
核心概念與診斷流程總覽
整個診斷流程圍繞「Query-Page 蠶食矩陣」展開，其核心概念與關係可總結如下：
- 中心節點：Query-Page Cannibalization Matrix
- 關聯節點：
- GSC Data：查詢、網址、曝光、點擊、CTR、平均排名
- 診斷流程：篩選 → 排除假性重疊 → 時序分析（代表文件切換）→ CTR 驗證
- 輸出行動：內容整併 / 角色明確化 / 技術設定
在整個診斷流程中，結合 GSC 的查詢、網址、CTR 和平均排名數據進行交叉分析，是準確識別關鍵字蠶食的核心。從建立矩陣、排除假性重疊、觀察時間序列到 CTR 驗證，每一步都建立在可查證的數據基礎上。
例如，當你透過試算表整理出潛在蠶食清單後，記得參考站內已有的 Search Console 關鍵字 基礎知識來理解數據含義。若在分析平均排名時遇到困難，可以延伸閱讀 Search Console 排名變化 的追蹤方法。而整個問題的根源，往往與 關鍵字研究 中對搜尋意圖的掌握不足有關。
什麼是關鍵字蠶食？
關鍵字蠶食是指同一網站的兩個或更多頁面，針對同一個搜尋查詢在 Google 搜尋結果中獲得曝光。在 GSC 中，這表現為單一「查詢」對應多個「網址」，會分散點擊並混淆演算法的代表文件選擇。
如何建立 Query-Page 蠶食矩陣？
你可以進入 GSC 的「查詢」效能報表，設定足夠長的日期區間，篩選特定主題的查詢，匯出為試算表後，使用 COUNTIF 函數計算每個查詢對應的網址數量，從而識別潛在蠶食組合。
為什麼要區分真蠶食與假性重疊？
因為假性重疊通常由技術因素造成，如網址參數、追蹤參數或正確的 canonical 設定，這些不屬於內容策略問題。排除後才能聚焦於真正需要解決的內容重疊蠶食。
如何從平均排名時間序列看出代表文件切換？
觀察同一查詢下多個頁面的平均排名走勢，若頁面 A 排名下降時頁面 B 排名同步上升，且曝光量此消彼長，這暗示 Google 在測試不同的代表文件，是蠶食的明確跡象。
CTR 異常如何輔助診斷關鍵字蠶食？
若潛在蠶食查詢的整體 CTR 顯著低於基準（如同查詢的歷史最佳 CTR 或同類型平均 CTR），即使曝光穩定，也可能表示搜尋結果中多個頁面導致使用者注意力分散，點擊率被稀釋。
診斷後應採取哪些行動？
根據蠶食類型行動：完全重疊時整併內容並設置 301 轉位或 canonical；部分意圖重疊時明確頁面角色並強化內部連結；技術性重疊時確保 canonical 設定正確。