先查舊 URL 是否逐一 301 到最相近的新頁、內鏈是否更新、目的頁是否保留原本搜尋意圖，以及 Google 是否已重新抓取。把多個不同任務全部導到一頁，訊號很容易被稀釋。
頁面合併同時改 URL、內容與內鏈，若沒有 mapping 與變更紀錄，就很難知道是搬移尚未完成，還是新頁根本無法承接舊查詢。
先看哪些訊號，再決定怎麼處理
| 檢查訊號 | 代表什麼 | 下一步 |
|---|---|---|
| 舊 URL 回 404 或導首頁 | 訊號與需求無法對應 | 改成逐一 301 到最相近頁 |
| 新頁刪掉舊頁核心段落 | 搜尋意圖承接消失 | 補回必要答案或拆頁 |
| 內鏈仍指舊 URL | 站內訊號與 redirect 矛盾 | 更新所有重要內鏈 |
操作示例
操作示例：建立舊 URL、新 URL、舊主要查詢、redirect 狀態、新頁承接段落五欄 mapping。任何舊查詢找不到新頁對應答案，就先不要宣告合併完成。
最容易誤判的地方
- 所有舊頁都導向首頁或分類頁
- 只確認 301 存在，不檢查內容是否承接
適用與不適用情境
適合用在
適合近期做內容整併、URL 重構或網站搬移後流量驟降的網站。
不適合直接套用
若下降發生在合併前，應先查其他事件，不要把所有問題歸因於 redirect。
接下來怎麼做
- 匯出完整新舊 URL mapping
- 修正 redirect、canonical 與內鏈
- 按舊查詢驗證新頁內容後等待重新處理
先照這個順序拆
- 先看掉量是集中在少數頁面，還是整體頁型都受影響
- 再拆查詢、頁面、國家/裝置與日期區間
- 確認是曝光掉、排名掉、點擊率掉，還是轉換層出了問題
- 最後才決定要改內容、技術或內鏈
這題通常不是表面看到的那一種問題
- 流量掉不一定是網站整體變差，可能只是某一類查詢或頁型改變
- 先找層級，再找原因，比先猜原因有效得多
流量下滑最怕一開始就全面重寫、全面改標題。先拆清楚是查詢層、頁面層、版位層還是演算法事件，復盤才不會失焦。
這類問題真正想解的是：流量變差背後到底是哪一層出現斷點，以及應該先從哪一段資料開始切。
怎麼做比較穩
- 先用查詢層與頁面層切資料
- 保留變動時間線，對照改版與更新事件
- 用分層診斷取代全面改稿
要避開的做法
- 不要只看總流量圖就直接下結論
- 不要一掉流量就全面重寫標題或內容
- 不要把所有下滑都歸因於演算法更新
社群裡常見的問題點
- 常把總流量下滑直接當成網站整體失敗，卻沒先拆哪類頁面受影響
- 也有人一看到掉量就先改內容，忽略版位與查詢結構可能先變了
- 有幫助的回覆通常會先回到 GSC 的查詢與頁面層做切片