AO2 FIELD GUIDE · N001 · SEO 與網站搜尋
關鍵字內耗應先核對查詢、讀者任務與頁面內容。附比較表及處理流程，判斷合併、補強或保留分工，避免只因關鍵字相同就刪頁。
- 先確認查詢與頁面的關係，再看是否真的造成使用問題。
- 區分總論、比較、產品與應用頁，不要求每個詞只對應一頁。
- 合併、轉址與 canonical 是不同工作，依目的選擇。
- 保留變更前資料與獨特內容，完成後回查。
關鍵字內耗：兩頁同時出現，可能是合理的內容分工
以半導體與電子供應商的網站為情境，使用者搜尋某類介面模組，可能需要先看選型指南，也可能已準備核對某一型號。總論與產品頁都出現在查詢資料裡，不代表它們必須合併。真正要問的是：兩頁是否各自幫讀者完成不同工作？標題、內容與下一步是否說得清楚？
如果兩篇文章都在解釋相同定義、比較相同條件、導向相同服務，且沒有新的證據或工作表，才更值得檢查重複。反過來，標題都有同一個詞，但一篇是選型、一篇是故障排查，也可能有合理的獨立用途。
先把三種問題分開：內容重複、任務模糊與技術版本
| 問題類型 | 可觀察線索 | 先做的事 |
|---|---|---|
| 內容重複 | 相同問題、證據、段落與下一步 | 比較獨特資訊與整合價值 |
| 任務模糊 | 產品頁像教學，教學頁又像產品介紹 | 重定每頁任務與閱讀路徑 |
| 技術版本 | 參數網址、列印版或近似重複版本 | 檢查網址與標準網址設定 |
這三種問題可能同時存在，但不能用同一招解決。技術上指定標準網址，不會自動補足內容分工；改了文章標題，也不會處理重複網址的索引關係。先指出問題層次，再提出修改。
建立查詢與頁面對照，不只看某一天排名
在 Search Console 固定搜尋類型、日期、國家與裝置等條件，觀察相關查詢下有哪些頁面，再分別查看點擊、曝光、平均排名與變化。官方文件提醒，搜尋結果會受時間、地點、裝置與個人情境影響；你手動搜尋看到的一次結果，不足以代表所有使用者。[1]
觀察期間應依資料量、產品週期與近期變更決定，不設定所有網站通用的天數門檻。資料少時可以延長觀察，但要留意市場與季節條件是否改變。查詢資料也可能不完整；不要把查不到紀錄解讀為完全沒有需求。
比較工作表：每一頁要有自己的存在理由
| 欄位 | 頁面 A | 頁面 B |
|---|---|---|
| 主要任務 | 理解選型條件 | 核對具體型號 |
| 獨特證據 | 決策條件與情境比較 | 核准規格與文件 |
| 讀完下一步 | 縮小適合的產品範圍 | 準備技術確認或詢問 |
| 需要補的內容 | 選項差異與限制 | 版本、適用條件與資料入口 |
| 若移除的損失 | 讀者缺少判斷方法 | 讀者失去實際產品依據 |
表中為虛構分工示例。如果兩頁實際填出一樣的任務、證據與下一步，整合可能有價值。若各有不可取代的資料，就先修正定位與內鏈，而不是為了「一個關鍵字一頁」的口號犧牲讀者用途。
保留分工：讓標題、開頭與連結表達差異
總論的開頭先交代判斷方法，產品頁則先提供型號、用途與核准條件。總論在適合的位置連到產品資料；產品頁在需要背景解釋時回連總論。連結文字描述下一頁能完成的工作，例如「核對該型號的介面條件」，而不是每次都只寫「了解更多」。
不要只改標題，內文卻繼續重複。也不要在每頁加入大量相同段落，試圖讓每頁都承擔所有需求。分工應能從實際內容與讀者任務被看見。
決定合併前，先盤點會失去什麼
逐項保留兩頁的獨特證據、被引用段落、下載文件與有效連結，再選定最能承擔整合任務的頁面。選擇不能只看目前點擊較多；網址穩定性、內容品質、外部引用、既有產品關係與維護責任也應一起考慮。
整合後若舊頁不再獨立使用，可依用途規劃永久轉址至合適的新位置，並更新站內連結。Google 的轉址文件區分永久與暫時搬移；實際設定與回應狀態需由網站人員核對。不要把所有舊文章一律轉到首頁，讓讀者找不到原先需要的內容。[2]
canonical 什麼時候適合用？
Google 的 canonical 說明針對重複或非常相似的頁面，用來表達偏好的標準版本；搜尋引擎仍會自行評估。它不是讓兩篇不同任務文章停止競爭的通用開關，也不應代替內容整合與閱讀路徑設計。[3]
若兩頁需要分別被讀者找到，就要先問為什麼要把其中一頁的標準版本指向另一頁。若只是網址版本不同，則應由技術設定處理。採用哪種方式之前，將預期索引與使用者體驗寫在修改單上。
變更後看什麼，才知道問題有沒有改善？
保留變更日期、涉及網址、內容差異與預期用途，再觀察相關查詢和頁面的整體表現、索引狀態與使用路徑。舊網址流量下降可能是轉址後的預期結果，不能單看一頁判斷失敗；同樣，新頁上升也不代表所有改動都有因果效果。
還要請人實際完成任務：找到選型條件、核對產品、取得文件與提出需求。如果搜尋數字變好，讀者仍找不到必要條件，內容問題並未結束。把觀察與下一步分開記錄，避免每次排名變動都重新大改。
修改單示例：先提出可回查的假設
虛構示例：A 是某類電子模組選型文，B 是同系列新文章，兩頁都解釋相同選型條件，但 B 多一張有來源的版本比較表。編輯提議把獨特表格整合到 A，再依網站檢查結果安排 B 的去向。這是待驗證的內容改善假設，不是預先保證排名會提升。
| 修改單欄位 | 應保留的內容 |
|---|---|
| 問題證據 | 兩頁實際重複段落、相同任務與查詢觀察條件 |
| 保留資訊 | B 的版本比較表、來源與仍有用途的連結 |
| 預期結果 | 讀者在同一頁完成選型，不必來回比較重複說明 |
| 技術處理 | 由網站人員確認網址、轉址、內鏈與 Sitemap |
| 回查 | 內容任務測試、索引狀態與相關頁面整體變化 |
如果讀完全文後發現 B 其實服務另一種應用，就修改提案，改為明確分工，而不是為了維持原計畫硬合併。內容決策應能隨證據修正，尤其既有文章可能有標題清單看不出的獨特價值。
常見問題
同一詞有兩頁曝光，就一定有問題嗎？
不是。先比對兩頁各自服務的任務、產品或版本，以及查詢與被展示頁面的關係。如果一頁解釋原理、一頁支援選型，可能適合分工並加清楚連結；若兩頁重複回答同一件事，才評估整合。保存比較範圍與觀察期間，不因一次排序交換就刪頁。判定要能指出讀者混淆或內容重複的位置，而不是只看出現相同關鍵字。
較舊的文章一定要併到新文章嗎？
不一定。比較兩頁的資料正確性、來源、使用任務、外部引用與既有入口，選擇最適合承接內容的網址，再整合有用段落。日期較新不代表資料較可靠。合併時保存對照、安排相關轉址與站內連結，並驗收舊入口、標題、canonical 及下載資源。若頁面仍有不同用途，就應清楚分工，不為了減少頁數而消除必要差異。
合併後多久一定會改善排名？
沒有保證時程。先驗收整合是否完成：目的頁保留必要內容，舊網址按安排回應，站內連結與標準網址一致，且沒有產生失效文件。再以相同查詢、頁面、裝置與市場範圍觀察搜尋變化，記錄其他改動。流量少或市場波動大時應延長觀察並保留不確定性。技術成功與排名變動是不同結果，不能只憑上線日期後的升降宣稱因果。
相關閱讀與下一步
了解對應 AO2 服務，或帶著目前的資料與工作問題，先確認適合開始的範圍。
參考資料與查核範圍
資料查核日期：2026 年 10 月 21 日。官方文件支援文中對應的平台規則；工作表、決策流程與虛構示例為本文整理。Johnny Wu 的公開分享作為作者工作觀點來源，未以此推定客戶成果或產品資格。
