搜尋觀點
canonical、301、sitemap 訊號衝突時，Google 會信誰？
一條 URL 不需要四個答案。遷移時最重要的工作，是讓每一個可控制的訊號指向同一個可索引版本。
當 301、canonical、XML sitemap 和站內連結指向不同網址時，Google 會綜合判斷，未必照任何一個訊號行事。這不是搜尋引擎「不聽話」，而是網站本身把同一頁的偏好版本說成了四個不同答案。
這類問題常出現在網站搬遷後：舊網址 301 到新頁，但新頁的 canonical 還指向舊址；sitemap 保留參數版；文章內鏈仍用 http；多語言頁又各自指回首頁。要修好它，不能只挑一個欄位改掉。
先選定唯一的「可索引目標 URL」
每個有搜尋價值的主題，先決定一個最終版本：能回傳 200、內容完整、可被索引、適合讓用戶和搜尋引擎長期使用。以下四種訊號才有共同的落點：
- 301 redirect：舊版本應直接帶往目標 URL，不經過多跳或首頁。
- HTML canonical：目標頁多數情況使用 self-canonical；不要指向會 redirect 的 URL。
- XML sitemap：只提交可索引的最終 URL，不應混入 301、404、noindex 或測試頁。
- 內部連結：導覽、麵包屑、相關文章與正文連結都改到目標 URL，減少 crawler 重新發現舊版。
三個常見衝突，應怎樣判讀？
情境一：301 到新頁，但 canonical 指回舊頁
這通常不是「雙重保險」，而是矛盾。使用者和 crawler 從舊頁會被帶到新頁，HTML 卻說舊頁才是偏好版本。先確認新頁內容是否真的承接原主題；若是，canonical 應放在新頁並指向自己，舊頁保留單跳 301 即可。
情境二：sitemap 還列出篩選或參數版本
例如產品分類頁同時有排序、追蹤碼或篩選參數。sitemap 的角色是告訴搜尋引擎哪些 URL 值得抓取和索引，不是把網站所有可開啟路徑列出。先把真正的分類主頁、服務頁、文章頁保留；其餘版本按情況使用 canonical、noindex 或不在 sitemap 內出現。
情境三：導覽已更新，舊文章內鏈仍指向舊網址
這會令 Google 和使用者持續遇到不必要 redirect。遷移後優先更新高流量文章、分類頁、頁尾和常見 CTA，而不是隻修一個主選單。若舊文數量很大，可先以資料庫匯出或爬蟲列出內鏈最多的舊 URL，按影響排序處理。
用抽查表找出「哪一層在拖後腿」
不要只看 view source。對每條代表 URL 同時檢查 request URL、最後 status、Location、頁面 canonical、sitemap 是否存在、主要內鏈來源及 Search Console 所示 Google-selected canonical。只要其中一欄不一致，就能定位問題是在伺服器、模板、內容，還是 sitemap 生成流程。
| 優先頁型 | 為何先查 | 最少要確認 |
|---|---|---|
| 首頁／核心服務頁 | 品牌與商業查詢集中 | http/https、www、尾斜線與 canonical 是否統一 |
| 有外部連結的舊文 | 可能累積歷史權重 | 301 是否直達對應新主題 |
| 分類／產品集合頁 | 容易出現參數與重複版本 | sitemap、pagination、篩選規則 |
| 多語言頁 | 常同時涉及 hreflang | 每種語言是否 self-canonical |
不要把 robots.txt 當作 URL 整理工具
robots.txt 不會替你合併重複頁，也無法把權重「導向」新網址。若封鎖了舊頁而 Google 又讀不到 redirect 或 canonical，反而更難重新處理。重複 URL 的選擇問題應先由 URL 架構、redirect、canonical、sitemap 和內鏈處理；robots.txt 只用於抓取管理。
想釐清「改完 canonical 為何仍未生效」，可閲讀 Canonical 修改後要等多久？；如涉及中英日版本，下一步是 hreflang 與 canonical 的常見錯配。若要把這批技術修正接回主題承接與商業頁排序，可先回看 Google SEO 主文章 與 Google 搜尋 SEO 服務入口。需要逐條驗證舊新 URL，可使用 重定向鏈路分析工具 或聯絡 YUSIHK 做 網站遷移技術診斷。