2026 年如何找出並修復關鍵字蠶食：Codex 工作流程指南

這個工作流程能給你什麼

你有一個本來排在你重視的關鍵字前十名的頁面，現在掉到第 34 名。你用同一個詞搜尋，結果頁裡出現你自己網站的兩個網址。或者你的內容團隊上個月上了 40 篇新文章，而你懷疑其中有幾篇正在悄悄地互相打架。

這個工作流程會把這種懷疑變成確認的清單和修復計畫。完成時你會得到：所有兩個以上網址互相競爭的查詢、每個群集的判定（合併、正規化、差異化、刪除四選一），以及一份告訴你修復是否有效的四週驗證計畫。

• 適用對象： 網站超過幾百頁的 SEO 人員與內容團隊，以及所有快速發文的人。
• 時間： 典型中型網站第一次稽核約 90 分鐘；流程上手後只要一半時間。
• 前置條件： Google Search Console 讀取權限、一份爬蟲匯出（Screaming Frog、Sitebulb 或同等工具）、如果有訂閱排名追蹤器也準備好。
• 完成定義： 清單上每個競爭群集都恰好有上述四種判定之一、修復已套用，而且行事曆上已排定重新檢查排名與曝光的日期。

開始前先做一次現實檢查，這能避免你去修沒壞的東西：一個查詢出現多個網址是正常的。類別頁、部落格文章和商品頁可以同時為同一個詞組排名——如果它們服務不同意圖（研究中的使用者 vs. 準備購買的使用者），那是健康的搜尋結果頁，不是蠶食。這個工作流程只會標記在同一階段爭奪同一份工作的頁面。

這件事在 2026 年比五年前更重要的原因只有一個：AI 產出的內容簡報與草稿以人工審查追不上的速度製造出相似頁面，所以蠶食現在是規模化發生的。它同時打擊 Google 排名與 AI 搜尋引用。

三分鐘症狀檢查

在深入資料之前先跑一遍。以下症狀有兩項以上符合，就執行完整稽核。

開始之前：需要的資料

收集這三樣東西：

1. 至少有 6 個月歷史的 Search Console。 90 天夠做快速檢查，但更長的區間能讓你看見排名下滑是否與頁面上線時間吻合。
2. 一份含標題與 H1 的新爬蟲。 Screaming Frog 開箱即用；Sitebulb 和 Botify 也可以。如果這些都沒有，site: 搜尋加上 CMS 頁面清單可以涵蓋最明顯的案例。
3. 排名追蹤器匯出（Semrush、Ahrefs、Authority Labs）。這一步是選配——光靠 Search Console 就能找出多數案例。

開始前先從 Search Console 匯出兩份東西：查詢報表（查詢、曝光、點擊、排名），以及加入頁面維度的同一份報表（網址）。兩者都在「成效」的完整報表裡。

步驟 1：在 Search Console 找出競爭網址

這是免費、訊號最強的一步。

1. 開啟 Search Console → 成效 → 完整報表。
2. 使用查詢篩選器，輸入你的第一個優先關鍵字。
3. 看圖表下方的網址清單。記下任何你網站兩個以上頁面同時獲得曝光的查詢。

你要找兩種模式：同一期間曝光幾乎平均分攤的頁面組合，以及原本在前十名、現在卡在 20–50 名的頁面——尤其是下滑剛好從一個相似頁面上線時開始的。

先從你最重視的 10–15 個關鍵字開始。如果其中一半都出現群集，問題是站點層級的，值得把過去 6 個月曝光超過（比方說）50 次的所有查詢整個掃一遍。如果只在少數幾個出現，問題是局部性的——修掉它們，繼續往前走。

預期產出： 一份清單，每個查詢附兩個以上你自己的網址及其曝光分攤。品質檢查： 頁面必須真的在同一個查詢上共同排名。如果只是聽起來相似，它們是鄰居，不是競爭者——移除。復原路徑： 什麼都沒找到？把區間拉長到 3 個月，並納入關鍵字的長尾變體。也檢查品牌詞與非品牌詞的分佈——多版本網站（語言對、批發對零售）的這個地方常藏著重複。

步驟 2：在爬蟲資料中找出重複標題與 H1

蠶食往往是內容生產的意外：作者被要求「寫寫 X」，沒確認既有的頁面，於是做出一個標題跟已在排名的頁面一樣的頁面。

打開你的爬蟲匯出，先依標題排序、再依 H1 排序，標出重複與近似重複。「近似」也算——兩個頁面不需要標題完全相同才會競爭。「Best CRM software」和「Best CRM tools」瞄準同一批讀者，就是候選；「Best CRM for real estate」是另一個頁面，不該進清單。

看爬蟲資料的同時，檢查技術嫌疑犯：指向頁面自身以外的 canonical 標籤、新增變體時被改掉的 meta robots noindex 規則、開始或停止的 robots.txt 封鎖。如同 Search Engine Journal 在相關指南中所說：當你改變指示搜尋引擎爬取、索引和忽略的方式時，你就製造了蠶食問題。繼承舊商品 canonical 的商品變體頁就是經典例子。

預期產出： 標題與 H1 重複或競爭的頁面對，加上技術旗標。品質檢查： 每一對回答一個問題——在另一個頁面上線之前，這個頁面是否已存在且已在排名？如果是，記下來；這是真問題最強的訊號。復原路徑： 如果你的 CMS 讓匯出很痛苦，用本文末尾的 Codex 技能從爬蟲 CSV 產生清單。把它們的輸出當作候選清單，而不是判定。

步驟 3：用排名追蹤器確認

Search Console 告訴你 Google 回報了什麼；排名追蹤器告訴你你的網址在時間軸上的位置，這才是真正暴露卡住頁面的工具。

在追蹤器裡打開每個候選查詢。確認蠶食的模式：關鍵字卡在 20 幾名到 50 名之間，或持有第 X 名的網址一直在你的頁面之間換人。Semrush 會顯示過去一年你的哪些頁面曾為該詞組出現；Authority Labs 會列出每個關鍵字的每個網址。如果一年歷史裡出現兩個以上你的網址、且兩者都沒進過前十，你就確認了。

順便讀一下方向。如果你的原始頁面在新頁面發布前排名正常、現在兩者都沉在首頁之下，新來者並沒有「偷走」排名——是兩個頁面互相稀釋。這會改變修復方向：把新頁面合併進原始頁面，而不是反過來。

預期產出： 每個候選群集的確認狀態——「已確認」或「未確認，需人工審查」。品質檢查： 確認需要至少兩個獨立訊號。Search Console＋爬蟲算兩個；單靠排名追蹤器是薄弱訊號。復原路徑： 如果你的追蹤器每個關鍵字只顯示一個網址，跳過這一步。Search Console 與爬蟲兩趟就足以跑完整個流程。

稽核管線：三個偵測關卡、一個判定矩陣、一個驗證迴圈。

步驟 4：決定修復方式

對每個已確認的群集，從四種判定中剛好選一種。這張表就是全部決策：

有兩種情況不是蠶食，別動它們：教學文與轉換頁針對同一個關鍵字服務不同漏斗階段——Google 理解哪個頁面負責什麼——以及同一頁面配上 hreflang 的不同語言版本。

用一個問題檢查你的判定：這個改變之後，搜尋這個詞組的使用者會不會落在一個頁面上、就拿到另一頁提供的所有東西？會，就合併或刪除。不會，就正規化或差異化。

步驟 5：在不流失能見度的前提下套用修復

修復 A：整合內容（合併判定）。 以存活頁面為工作基準。把輸家頁面的每個獨特章節複製進去——FAQ 答案、例子、會被引用的章節、指到它的內部連結。需要的話重新排序，讓最強的內容靠近頂部。當輸家頁面有外部反向連結或自己的真實排名時，用 301 把它導向存活頁面，而不是讓它 404；兩者皆無時，直接移除即可。Search Engine Journal 的指南刻意避開 301——它偏好摺疊內容後刪除較新的頁面——只有當被移除的網址帶著自己的連結資產時，301 才成為必要。把使用輸家頁面錨點文字的內部連結改指向存活頁面。

把兩個競爭頁面合併成一個網址，50/50 的曝光瓜分會變成單一贏家。

修復 B：Canonical 化（正規化判定）。 在官方頁面放自我參照 canonical，並把變體 canonical 到它。這是為「必須存在但近乎重複」的頁面準備的工具：商品變體、參數化網址、活動頁。它不是整合的替代品。如果兩個頁面都帶有意義的內容，光靠 canonical 會讓兩者都留在爬取範圍內、也分裂你的編輯焦點——先做內容工作，再指 canonical。

修復 C：程式化封鎖索引（刪除的鄰近判定）。 當重複是結構性的——參數頁、篩選組合、不需要索引的區域變體——在資料夾或範本層級套用 noindex，而不是逐頁處理。這就是一行程式碼勝過 200 次手動編輯的案例。

修復 D：依意圖修正內部連結（差異化判定）。 當兩個頁面合法服務不同意圖，讓你的內部連結也這樣說。來源指南的規則：如果「apples」一詞周圍的文字在講買蘋果，連到轉換頁；如果講蘋果從哪裡來，連到資訊頁。每一條內部連結都是一張選票。當你的連結一致指向應該勝出的頁面，你就消除了搜尋引擎原本會自行解決（而且常常解錯方向）的模糊性。

步驟 6：驗證修復是否撐住

修復後等兩到四週，再重跑檢查。

1. Search Console： 查詢現在應該顯示單一主導網址而非瓜分，且存活頁面的曝光應該上升。群集整體曝光在重新排名期間可能下滑一兩週——這是正常現象，不是失敗。
2. 排名追蹤器： 關鍵字應該停止在網址之間震盪。
3. AI 介面： 用你的關鍵詞組去問 AI 助理或 AI 搜尋引擎，確認被引用的是存活網址——不是被移除的那個。瓜分的頁面也會瓜分 AI 引用。整合是少數能同時幫助 Google 排名與 AI 搜尋能見度 的修復方式。

四週後群集仍在分裂，代表你漏掉了一個頁面（再檢查你不知道的變體），或者這些頁面確實服務不同意圖、本來該差異化而不是合併。重新驗證、重新決定。

防止它捲土重來

稽核是簡單的部分。保持乾淨是一條發文紀律。三個做法，依重要性排序：

1. 維護一份內容團隊下筆前會查的議題清單。 製造蠶食最快的途徑，是一個不知道頁面已經存在的作者。
2. 讓重疊成為對話，而不是圍牆。 與其禁止某個議題，不如幫作者找到互補的角度——教學文、比較文、垂直特定版本。
3. 特別盯緊 AI 生成管線。 AI 生成輸出是最快的蠶食工廠：無論提示詞品質如何，它都會產出互相競爭的重複、單薄頁面。所有生成或經 AI 簡報的頁面，都該在排程前通過議題清單檢查，且季度稽核應優先處理它們。

完整稽核每季度跑一次，並在每次為網站同一區塊新增多個頁面的發布後再跑一次。

自動化稽核：一個 Codex 技能

上述步驟先手動跑，是為了讓你理解資料的意義。理解之後，把可重複的部分交給 AI 程式碼代理。這是一份完整的 Codex 技能檔案：它讀取你的 Search Console 匯出、標出競爭群集、產出判定表——全程不碰你的網站。

---
name: keyword-cannibalization-audit
description: Find and classify keyword cannibalization clusters from Google Search Console, crawl, and rank-tracker exports. Use when a query shows multiple URLs, rankings dropped after a new page launch, or you need a cannibalization verdict sheet. Read-only: produces a report, never edits pages.
---

# Keyword Cannibalization Audit

## Inputs (required)
- `gsc-queries.csv` — Search Console query export (query, impressions, clicks, position)
- `gsc-pages.csv` — Search Console page export (page, impressions, clicks, position)
- `crawl-titles.csv` — crawl export with URL, title, H1, canonical
- `rank-history.csv` — optional rank tracker export with per-keyword URL history

## Procedure

1. Load the CSVs. Normalize URLs (lowercase host, strip trailing slash and tracking parameters).
2. Join `gsc-queries.csv` and `gsc-pages.csv` on query to build query-to-URL mappings.
3. Flag queries where 2+ URLs each received at least 10% of the query's impressions in the last 90 days.
4. Flag queries where a URL sits between positions 20-50 and a second URL for the same query was created later (compare crawl or tracker history).
5. From `crawl-titles.csv`, flag pairs whose titles or H1s are identical or share 80%+ of their significant tokens.
6. From `rank-history.csv`, flag queries whose ranking URL changed more than twice in 6 months.
7. Cross-check every flag. Keep only clusters confirmed by at least two signals (Search Console + crawl counts as two).
8. Classify each surviving cluster as MERGE, CANONICALIZE, DIFFERENTIATE, or REMOVE:
   - Same intent + one page clearly more complete → MERGE (fold unique sections into the survivor; note a 301 only if the removed URL has external backlinks)
   - Near-identical variants that must exist (parameters, variants) → CANONICALIZE
   - Same topic, genuinely different intent you want to keep → DIFFERENTIATE (rewrite one page, no title overlap)
   - Thin or fully duplicated page with no unique value → REMOVE
   - Complementary intent (how-to vs. product for the same keyword) → NOT CANNIBALIZATION, skip
9. Output `cannibalization-verdicts.md`: a table of query | competing URLs | signals found | verdict | action, ordered by query impressions. Include for each cluster the exact URLs, the evidence rows (dates, positions, impressions), and fix text ready to paste into a CMS task.

## Rules
- Read-only. Never edit pages, robots.txt, or canonicals. Output the report and a proposed action plan only.
- Never merge a URL into a survivor whose content is not equal to or better than the merged output.
- Do not classify locale variants (hreflang) or genuinely different intents as cannibalization.
- Clusters with fewer than two confirming signals get marked "unconfirmed — review manually," never dropped.
- When the rank tracker export is missing, run with Search Console + crawl only and say so in the report header.

把它存成 Codex 技能資料夾裡的 keyword-cannibalization-audit/SKILL.md，把四個 CSV 丟進一個工作區資料夾，然後執行。典型數千頁的執行只需幾分鐘，回傳判定表。

兩個更小、適合不想用完整技能時用的提示詞：

• 匯出分診：「這是我的 Search Console 查詢匯出。找出所有我兩個以上網址各自獲得至少 10% 曝光的查詢。輸出一個表格，欄位為查詢、網址、曝光分攤、每個網址的排名。不要給建議。」
• 判定群集：「我的兩個頁面都在 [查詢] 排名：[網址 A] 第 [X] 名、[網址 B] 第 [Y] 名。[網址 B] 於 [日期] 上線。比較兩者內容，用兩句話告訴我四種判定——合併、正規化、差異化、刪除——中哪一種適用及其原因。」

FAQ

我的關鍵字有多個頁面在排名——這自動算蠶食嗎？

不算。如果頁面服務不同意圖（研究 vs. 購買）或不同語言區域，搜尋引擎處理得很好。只有同一漏斗階段爭奪同一份工作的頁面需要判定。

Canonical 還是 noindex——該用哪個？

變體必須保持可訪問（商品變體、參數）且其訊號要流向官方頁面時用 canonical。純粹重複、不服務任何使用者需求的頁面，用程式化套用的 noindex。當重複頁面其實含有有用內容時，兩者都無法取代內容整合。

我該 301 輸家頁面嗎？

只有在它有外部反向連結或自己的實質排名時才該。否則把它的獨特內容摺進存活頁面後移除。導向一個並非真正替代品的頁面的 301，會浪費轉址的資產並困惑使用者。

合併後流量下滑——我弄壞了嗎？

Google 重新評估群集期間的短期下滑很常見。以四週為準來衡量：如果存活頁面拿到該查詢排名、群集曝光恢復，修復就撐住了。如果是另一頁在勝出，你合併的方向錯了。在問題惡化前把它倒轉回來。

蠶食會影響 AI 搜尋引用嗎？

會。當你的兩個網址競爭時，AI 回答會在兩者之間選擇，可能引用任何一個——或都不引用。整合會給你一個強而有力、適合被引用的網址，而不是兩個稀釋的。

我應該多久跑一次稽核？

基準是每季度一次，加上任何一波新頁面之後。用 AI 生成內容的網站，應該把稽核視為發布管線的一部分，而不是週期性雜務。

作者：Clara Bennett，Auspia 十年內容策略從業者。她撰寫關於編輯系統、主題地圖，以及讓內容發布計畫不會互相撞車的可重複內容營運。