關鍵字蠶食診斷與修復：從型態判斷到對症下藥

同一個查詢對應到站內多個網址時，先不要急著刪除或合併。需要確認各頁是否服務不同任務、Google 實際呈現哪個網址，以及點擊與轉換是否受影響；修改後排名變化也不能單獨證明原本存在關鍵字蠶食。

這個現象常被稱為關鍵字蠶食（Keyword Cannibalization）：多個頁面瞄準高度重疊的搜尋意圖，造成錯誤網址排名、排名頁頻繁切換，或內外部訊號分散。同一查詢出現多個網址不一定有害，因此這篇會先教你診斷，再選擇合併、分化或技術處理。

先講結論：重複字詞或相近意圖不足以證明排名受損。先核對頁面任務、搜尋表現與技術訊號，再決定保留、合併、轉址或調整 canonical；不必為每個意圖強制只留一個網址。

關鍵字蠶食是什麼？一個被嚴重低估的「自我損耗」

可以把這個問題想成網站導覽：若兩份內容幾乎相同，讀者可能不清楚差別，編輯也要重複維護。但兩個頁面若分別處理不同條件或任務，並存可以有價值，不能僅因主題相近就判定互相損耗。

Google 可能依查詢與情境呈現不同頁面。排名網址輪替值得調查，但沒有依據能說同一意圖的兩頁一定卡在第二頁或無法進入前三；先比較各頁內容、索引與查詢資料。

更實際的風險是，外部與內部連結可能指向不同頁面，網站導覽也沒有清楚主次。不能用「十條連結集中就一定上首頁」推算排名，點擊率與停留時間也不該直接列成固定排名訊號；真正要檢查的是 canonical、轉址、內部連結與排名網址是否一致。

流量停滯與點擊波動有多種原因。新增內容前可核對現有頁面是否已回答相同任務，避免沒有增益的重複維護；也應排查需求、排名及技術變化，不能直接診斷為蠶食。可搭配常見 SEO 錯誤自查整理排查方向。

蠶食的三種面貌：別只盯著「重複關鍵字」看

以下把可能的問題分成內容高度重疊、任務相近及技術性重複三類，方便安排檢查。這是本文的整理方式，不是 Google 公布的蠶食分類；是否需要修正仍以實際頁面與資料為準。

型態一：完全蠶食，兩頁正面廝殺

這是最經典、也最好發現的一種。你的網站上有兩個（甚至更多）頁面，標題、H1、主要關鍵字幾乎一模一樣，內容主題高度重疊。例如你寫了一篇「WordPress SEO 教學」，過了半年又寫了一篇「WordPress SEO 設定指南」，兩篇都在講外掛安裝、永續連結設定、標題優化。對 Google 來說，這兩頁就是同一道菜上了兩次。

這種類型通常來自一個善意但危險的習慣：以為「越多頁越好」。網站經營一段時間後，主題會自然重複累積，如果沒有一個統一的內容地圖，就會長出這種互相競爭的頁面。

型態二：語意蠶食，搜尋意圖偷偷重疊

兩組查詢用字不同，仍可能對應相近任務。可以比對搜尋結果與頁面內容判斷重疊範圍，但不能據此宣稱 Google 會把這些查詢的排名結果合併處理。

舉個例子。你可能有一篇鎖定「SEO 是什麼」，另一篇鎖定「搜尋引擎優化教學」。從關鍵字工具看，這是兩組不同的詞。但對 Google 而言，搜尋這兩組詞的人想得到的答案幾乎一樣：一個基礎的 SEO 入門說明。於是兩篇開始互相搶同一群讀者。關於這個「字不同、意圖相同」的判定邏輯，可以參考我寫的搜尋意圖完整拆解，它是判斷語意蠶食的核心。

語意蠶食的難點在於：你的關鍵字研究表格看起來乾乾淨淨，每個詞都有專屬頁面，沒有重複。但只要你沒有從「使用者想知道什麼」的角度去檢視，這種重疊就會藏在表格底下。回過頭，我只看關鍵字清單永遠不夠，一定要回到搜尋結果頁面實際看 Google 把哪些頁面排在一起。

型態三：結構性蠶食，系統自己產生的分身

第三種跟內容創作者無關，是網站技術結構自己長出來的。最常見的來源是 URL 參數、分頁機制、篩選器、以及標籤頁（tag archive）。例如一個電商網站，同一款商品可能透過「顏色篩選」「尺寸篩選」「排序方式」產生出幾十個不同網址，每個網址的內容卻大同小異。又或者你的部落格分類頁和標籤頁，把同一篇文章用不同的 URL 路徑各收錄一次。

參數、篩選與其他功能可能產生許多重複網址，增加抓取與管理負擔。先從 Search Console 的網址範例和站內爬取資料確認來源；索引數高於手動建立的頁數只是線索，不能單憑總數判定問題。大型網站可再參考爬取預算管理。

把三種類型列成一張表，方便你先自我分類：

為什麼 Google 不會自動幫你「選出最強的那一頁」

Google 會自行選擇重複內容的代表網址，通常不必為每個正常重複版本手動介入。當選出的網址不符合網站需求，或各種訊號互相矛盾時，再檢查 canonical、轉址與內部連結。

Google 會選擇 canonical 版本，並可能把重複網址的部分訊號整合到所選版本，但網站不能假設 Google 一定選中你偏好的頁面。應讓轉址、rel="canonical"、sitemap 與內部連結一致，降低系統判斷衝突。重複內容本身也不是所謂的「處罰」。

這裡有一個很關鍵的現實數字。Backlinko（Brian Dean）分析超過 400 萬筆 Google 搜尋結果的研究發現，自然搜尋的點擊高度集中在前幾個結果，第二頁之後點擊明顯變少，而且不同排名區間的落差不完全一致（見 2025 年 4 月的 Google CTR Stats 研究）。

排名與點擊率的研究可提供觀察背景，但無法保證合併會提升位置或帶來數倍流量。應先確認內容確實重複或任務衝突，再比較修改前後的查詢、網址、點擊與轉換；指標背景可參考CTR 點擊率的判讀方法。

Google 的 canonicalization 可以整合重複網址的部分訊號，包括指向各版本的連結。站方可透過一致的設定表達偏好，但不能說 Google 完全不會自動合併訊號，也不能把修正換算成固定排名增益。

這裡還有一個更嚴峻的背景。Ahrefs 針對約 140 億頁內容的研究指出，將近 96.55% 的網頁從 Google 拿不到任何自然搜尋流量（2023 年 12 月的 Ahrefs 搜尋流量研究）。在一個「絕大多數內容根本分不到流量」的環境裡，你還主動把僅有的權重拆成好幾份去內耗，這是最不划算的事。

第三方點擊率與流量研究只能描述樣本中的分布，不能推導蠶食一定把頁面卡在第 15 名，也不能保證合併後流量上升。修正的價值在於讓正確頁面承接查詢、減少維護重複與技術訊號衝突，成效則要用修正前後的排名網址、曝光、點擊與轉換驗證。

診斷實戰：用 Search Console 把蠶食攤在陽光下

講完為什麼要修，接下來是怎麼找。你不需要買昂貴的工具，Google Search Console（簡稱 GSC）就能讓大部分的蠶食現形。如果你還沒把 GSC 裝起來、搞懂它的回報邏輯，先花十分鐘把Search Console 完整教學走一遍，下面的步驟才接得上。

診斷的核心動作只有一個：找出「同一組查詢，被多個網址搶走曝光」的情況。GSC 的「搜尋結果」報表可以讓你做這件事。我習慣的操作流程是這樣的：

1. 打開「搜尋結果」報表，把時間範圍拉到最近 3 個月。時間太短會被單週波動誤導，太長又會把已經修過的舊問題算進來。
2. 切換到「查詢」維度，依點擊數排序。找出為你帶來最多流量的前 20 到 30 組查詢，這些是你最該保護的資產。
3. 點進某一組查詢，切到「網頁」維度。同一查詢有多個網址很常見，先看它們是否解決不同意圖。若頁面目的高度重疊、排名網址反覆切換，或非預期頁面持續承接曝光，才是需要處理的訊號。
4. 反過來操作：切到「網頁」維度，找一個主力頁面，再切回「查詢」。看看這個頁面實際上是靠哪些查詢拿到流量的。然後挑其中一組查詢，回去比對有沒有別的網址也在搶它。
5. 把可疑的網址配對記下來。一張清單，左邊寫查詢，右邊寫互相競爭的網址，這就是你的修復工作清單。

這個流程能列出需要複查的查詢與網址配對。多網址交集是調查起點，不是蠶食確診；還要確認各頁的用途、時間變化與技術狀態。

以假設案例說明：同一查詢下，A、B 兩頁都獲得曝光，平均位置也相近。這時應先比較它們的任務與網址是否輪替，再依裝置、國家和日期拆解數據；不能從平均位置就推定兩頁互相阻擋。

並不是兩個網址出現在同一查詢就一定是蠶食。排名位置接近也只是診斷線索，不能證明 Google「猶豫不決」。應拉長日期範圍，查看網址是否輪替、各自意圖、裝置與國家差異，再比對 canonical、內部連結與 SERP。

修復決策：先判型態與頁面去留，再選處理方式

確認蠶食存在之後，不要急著從工具箱裡挑一個順手的手段直接上場。修復比較像看診：同樣是「多個網址搶同一組查詢」，背後的病根可能完全不同，處理方式用錯，輕則白做工，重則把原本健康的頁面弄壞。這一節先把選擇的邏輯攤開，再往下拆每一條路徑的執行細節與地雷。

挑處理方式之前，先回答兩個問題。第一個問題：這是哪一種型態的重疊？完全蠶食、語意蠶食、結構性蠶食的成因不同，對症的方式也不同，前面「三種面貌」那一節就是為了這一步做的鋪墊。第二個問題：被牽涉的網址能不能收攏或移除？內容文章通常可以合併或轉址，但電商篩選頁、分頁這類功能型網址非留不可，處理邏輯完全是另一套。把這兩個答案放上座標，去對照這張表格，常見情況的首選與備案就會直接浮出來。

先判斷內容是否重複、網址是否需要保留，以及是否有合適替代頁，再選擇處理方式。這張表是排查提示，不取代個別網址的用途、索引與轉址驗證。

這張表給的是方向，每一條路徑各自藏著執行細節與地雷。接下來按處境展開：內容可以收攏時，合併與轉址怎麼分工；網址非留不可時，canonical 怎麼設才不會誤傷；兩頁各有價值時，搜尋意圖怎麼拆；以及無論走哪條路，最後都要做的內部連結收尾。

內容可以收攏時：合併與轉址的分工

當兩頁任務高度重疊、內容又各自都不完整時，合併通常是最務實的答案。最典型的狀況是兩篇各寫了 1500 字的教學，合起來其實是一篇 3000 字的完整指南，但拆成兩篇誰都不夠看。

做法是挑出兩頁裡表現較好、外部連結較多、URL 較乾淨的那一頁當作「合併目標」，把另一頁的精華內容（獨特的段落、表格、範例、被引用過的段落）搬過來，整合成一篇更完整、更有深度的頁面。被搬空的那一頁，不要直接刪除讓它變成 404，而是用 301 轉址指向合併後的那一頁，這樣舊連結的權重才會跟著過來。

合併有一個很多人輕忽的關鍵：合併不是剪貼，是重新組織。如果你只是把兩篇文章拼起來，內容會出現重複段落、邏輯斷層，讀起來像兩篇文章硬接在一起。Google 對這種「拼接品」評價很低。正確的做法是把它當成一篇全新文章來重寫，重新安排章節順序、消除重複、補上兩篇都缺的觀點。這也是把資訊增益（Information Gain）做出來的機會，一篇真正合併得好的頁面，價值會遠大於兩篇各寫一半的文章。這個概念我在資訊增益那篇有深入討論。

合併處理的是「兩頁內容都該留」的情況。另一種情況是勝負早已分明，弱的那頁不需要搶救，直接讓出位置把存在感收攏給主力頁，這時要考慮的是轉址，以及轉址前該確認的例外。

若 B 頁已決定永久移至 A 頁，且 A 能承接原有內容與使用者任務，可以採永久轉址。反向連結較少或排名較低，本身不足以決定刪除 B；先檢查是否仍有獨特資訊或需求。

301 轉址表示 B 頁已永久移到 A 頁，讓使用者與搜尋引擎前往新位置，搜尋系統也可在重新處理後整合部分訊號。這不是「所有權重轉交」指令，也不保證 A 頁排名提升；A、B 內容與意圖應高度相關。

永久搬移用 301 或 308，暫時調度才用 302 或 307；選擇依搬移意圖，不是因為 302 一律不傳遞訊號。完整差異可對照301 與 302 轉址教學。轉址後要持續追蹤抓取、索引與流量，重新處理時間沒有固定兩到四週保證。

還有一種收攏是連替代頁都不需要。頁面內容薄弱、沒有外部連結、也沒有真實使用者任務在支撐時，與其硬把它轉址到一個不相關的頁面，誠實地讓它以 404 或 410 退場，對網站整體的品質訊號反而更健康。判斷的標準很直接：這一頁如果消失，有沒有任何人會覺得可惜？如果答案是否定的，它就不值得繼續占用索引，把這類頁面列進下一次內容盤點的清除清單，處理起來最不糾結。

網址必須保留時：用 Canonical 指定主版本

結構性重疊走的是另一條路，因為這裡有最關鍵的約束：有些重複網址你無法也不該刪掉。例如電商網站的篩選頁面，從使用者體驗角度它必須存在，你不能把「紅色款」的篩選網址直接 301 掉，否則使用者點選篩選器會壞掉。又或者分頁機制產生的第 2 頁、第 3 頁，它們承載著真實的內容。

高度重複、仍需保留的網址可使用Canonical 標籤指出偏好版本。它是強訊號而非強制命令，Google 仍可能依內容、轉址、sitemap 與內部連結選擇其他 canonical。分頁通常應各自 self-canonical，不能把第 2、3 頁一律 canonical 到第 1 頁，否則可能讓後續內容難以被發現。

Canonical 是處理結構性重複最優雅的工具，但它也最容易設錯。常見的錯誤包括：把 canonical 指向一個自己都不是主版本的網址、全站每一頁的 canonical 都指向首頁（這是災難）、或者 canonical 跟 301 混用造成矛盾訊號。還有一種隱形錯誤，是你的參數頁 canonical 指向主版本，但主版本本身又是另一個參數頁，形成一條「canonical 鏈」，Google 很可能直接忽略整條鏈。Canonical 的判定邏輯、自薦 canonical 與跨網域 canonical 的差異，我在Canonical URL 完全指南裡有完整的說明，動手設定前務必先看過。

noindex 與 canonical 目的不同。高度重複內容需要指出偏好版本時可用 canonical；頁面不應出現在搜尋結果時用 noindex。篩選頁要依是否具獨立搜尋價值、爬取規模與技術架構判斷，沒有「要 Google 看見就用 canonical」這種單一準則。noindex 也不是用來整合訊號的工具。

兩頁各有價值時：重新定位搜尋意圖

語意重疊但兩頁內容各有價值時，合併與刪除都會白白損失一篇能打的內容，這時該做的是讓兩頁分頭服務不同的搜尋意圖。這條路最需要腦力，但做成之後的成效也最漂亮。

做法的核心是強迫兩個頁面服務不同的搜尋意圖。回到前面「SEO 是什麼」和「搜尋引擎優化教學」的例子，你不能讓兩篇都在做入門介紹。你要重新定義每一頁的職責：也許 A 頁專門回答「這是什麼」的定義型意圖，給完全的新手看，篇幅短、觀念清楚、少術語；B 頁則升級成「怎麼做」的實作型意圖，給已經懂概念、想動手做的人看，充滿步驟、工具、設定細節。

重新定位時，標題、內容與內部連結都應如實說明每頁能處理的任務。這能幫助讀者導航，也提供搜尋系統線索；不同頁面仍可能出現在同一查詢，不能保證調整後完全不重疊。

判斷「兩個意圖到底能不能拆開」有一個簡單的檢驗：去 Google 搜尋那組關鍵字，看看第一頁的結果是清一色同一種格式（例如全都是「十大清單」），還是混雜了不同類型（有定義、有教學、有比較）。如果第一頁是混雜的，代表 Google 認為這個查詢背後有多種意圖，你就有空間把兩頁分別對應到不同意圖。如果第一頁清一色是同一種，代表意圖很單一，這時候合併會比重新定位更實在。

例如「SEO 工具推薦」與「SEO 工具比較」，可能分別需要精選結論與詳細規格，也可能由一篇內容就能完成任務。應先觀察讀者需求與現有頁面，再決定分開或整合；這是假設規劃例子，不是已證實成功消除蠶食的案例。

無論走哪條路：用內部連結收尾

無論前面選了合併、轉址、canonical 還是重新定位，最後都要用內部連結收尾，這一步常被當成可有可無的附屬動作。很多人修完蠶食就以為結束了，卻忘了內部連結是 Google 理解「這個網站覺得哪一頁最重要」的重要線索。如果你網站的導覽列、側邊欄、文章內文，還是把錨點文字平均分散在兩個互相競爭的頁面上，Google 收到的訊號還是混亂的。

可以為重要主題規劃清楚的入口，再依上下文連到相關教學、比較或操作頁。錨點文字應描述目標內容，不必把所有含同一主題詞的連結都集中到一個支柱頁。

例如導覽中兩個近似名稱連向不同頁面，可先確認讀者是否能看懂差別。若內容重複就評估整合；若用途不同，使用更具體的連結文字即可，不應直接宣稱兩個連結一定讓搜尋訊號打折。

網站架構應讓重要頁面容易發現，相關內容之間有合適連結。主題叢集是一種規劃方式，扁平架構本身不等於一定發生蠶食；可依內容規模與讀者路徑選擇，詳見網站架構 SEO 規劃。

修完之後：把蠶食擋在門外的長期機制

修復是治標，治本是建立一套讓蠶食根本長不出來的機制。我看過太多網站，修完三個月又冒出新的蠶食，因為他們只是把舊問題解掉，沒有改變「產生問題的那個習慣」。下面四件事，是把蠶食擋在門外的關鍵。

第一，建立一份活著的內容地圖。這是一份清單或表格，記錄你網站上每一個主題、每一組核心關鍵字對應到哪一個頁面。每次要產新內容之前，先查這份地圖：這組關鍵字是不是已經有頁面在服務了？如果有，你是該去補強那個頁面，還是真的有一個新的、不同的搜尋意圖需要新頁面？這份地圖不需要多複雜，但它必須存在，而且每次新增內容都要更新。沒有這份地圖，你就是在黑暗中寫內容，重複幾乎無法避免。

內容地圖的最低門檻，是一張三欄表格：主題、目標關鍵字、對應網址。欄位不用多，重點是每次動筆前都要翻它。我自己的習慣是，連寫一篇看似無關的新文章，都會先在地圖裡搜一下相關詞，因為語意重疊常常出現在你沒料到的角落。寫久了你會發現，這張表還有另一個用途：它會清楚告訴你哪些主題已經被覆蓋得很厚、哪些主題還是單薄的一篇，等於順手把你下一步該補什麼內容的優先順序也排好了。

第二，關鍵字研究時就同步做意圖檢查。不要只看搜尋量、只看難度。每一組你打算鎖定的關鍵字，都去 Google 搜一次，看第一頁的結果類型。問自己：這組詞背後的意圖，跟我現有某個頁面服務的意圖一樣嗎？這個動作花你五分鐘，卻能省下日後好幾個月的修復工。篩選關鍵字的完整方法，可以搭配關鍵字分類策略和長尾關鍵字攻略一起建立你的選詞紀律。

第三，維護清楚的網站架構。可用主題入口整理相關內容，也可依產品、任務或其他合適方式導航。每次新增頁面時確認它的用途與連結位置；主題叢集不是避免內容重疊的唯一方法，也不能保證重複永遠不再發生。

主題叢集還帶來一個意料之外的紅利：它強迫你在寫之前就先把「這篇文章在這個主題裡的位置是什麼」想清楚。一篇群集頁之所以存在，是因為它回答了支柱頁沒辦法深入講的某個子問題。如果你動筆時講不出「這篇補的是哪一塊」，那十之八九它會跟既有的某頁重疊，這就是蠶食的前兆。把這個「先定位、再動筆」的紀律建立起來，比事後任何修復工具都管用。

第四，定期回頭掃一次。蠶食會隨著網站成長慢慢累積，建議每一季用前面教的 GSC 診斷流程跑一次，把新長出來的競爭頁面抓出來。這就像定期健康檢查，越早發現越容易修，等到整個網站糾結成一團再來解，工程會大上好幾倍。如果你曾經歷過排名無預警下滑的恐慌，這份排名掉落急救指南跟定期掃描是配套的，兩個一起做能把風險降到最低。

AI Overviews 與 AI Mode 沿用 Google Search 的抓取、索引與品質系統，沒有公開資料證明關鍵字蠶食在 AI 搜尋中一定更嚴重。整理重複頁面的主要理由仍是讓使用者與搜尋引擎理解各頁任務、減少維護與技術衝突；它不保證獲得 AI 引用。延伸可看SEO 與 AI Overviews。

把排名從自己手裡救回來

關鍵字蠶食，換句話說，就是你的網站在跟自己搶同一塊餅，結果誰都吃不到完整的一塊。它沒有什麼高深的黑魔法成分，說穿了就是一個「沒有人刻意犯、卻人人都會犯」的結構性疏忽。只要你持續產內容、又沒有一套統一的內容地圖，它就會慢慢長出來。

修復邏輯是：找出任務重疊或排名網址切換的頁面，判斷型態，套用合併、轉址、canonical 或重新定位，再用內部連結收尾。完成後持續監測，不能預設排名一定回升。

給你一個今天就能動手的下一步：

1. 打開 Search Console，挑出為你帶來最多流量的前 10 組查詢。
2. 逐一點進去，切到「網頁」維度，看有沒有兩個以上的網址在同時搶曝光。
3. 把可疑的配對記下來，對照上面的修復決策對照表，判斷該合併、轉址、重新定位，還是只調整內部連結。
4. 這個月先修掉最嚴重的一組，觀察它接下來四週的排名變化。

不用一次修完所有問題。先把最痛的那一組解掉，一旦觀察到排名、曝光或點擊的改善，你就會相信這件事的價值，也會更有動力把剩下的清單慢慢走完。你的排名，不該是被自己吃掉的。