canonical 是頁面自己發出的一條归並建议：告诉搜尋引擎，這一组相似地址里，希望把收錄归属算在哪個 URL 上。它不阻止抓取，也不像 301 那样把訪問者直接送走，所以寫错了不會有明顯报错。問题往往過很久才在索引里顯現——被指向的目标進了索引，頁面本身長期查不到，或者几個地址的信号互相冲突。
先確認問题出在归並信号，而不是内容本身
几種典型表現：頁面抓取正常、返回 200、正文可讀，但 site 查询里找不到它；或者能查到，顯示的却是另一個 URL；又或者同一篇内容在索引里出現多條，标题在不同地址之間来回切換。這類現象應優先核對 canonical、hreflang、參數處理等归並信号，而不是先怀疑内容质量或權重。
逐項核對 canonical 的寫法
- 自指是否成立。每個頁面應指向自己的規范地址，並且與頁面實际訪問的地址完全一致，包括协议、域名、大小寫、结尾斜杠。
- 是否被模板變量污染。列表頁、篩選頁、分頁常见的變量如果没正确輸出，很容易让整站或整批頁面都指向同一個 URL。
- 是否跨域或跨語言誤指。多語言、多地区站点把地方版本 canonical 到主站，等于主動放弃该版本的收錄归属。
- 是否指向了重定向或不存在的地址。canonical 指向的 URL 自己會跳轉或返回错誤时，這條信号很可能被忽略。
- 是否與 Sitemap、内鏈、hreflang 冲突。几個信号指向不同地址时，搜尋引擎會自行判断，结果不一定符合预期。
- HTTP 與 HTTPS、带 www 與不带 www 是否统一。頁面能通過多個入口訪問时，归並信号的寫法要格外克制。
從頁面到模板的排查顺序
建议按"先看结果、再看来源"的顺序推進，避免一上来就翻模板：
- 抽取五到十個典型 URL：首頁、栏目頁、詳情頁、分頁第二頁、带篩選參數的頁、移動版頁面。
- 查看渲染後的 HTML 源碼，注意脚本渲染前後 canonical 可能不同，要確認搜尋引擎看到的是哪一版。
- 回到模板层，確認這個值由哪個變量生成，是否存在預設值兜底導致全部指向同一地址。
- 检查 CDN、反向代理或前端框架是否在輸出环节改寫或注入了标簽。
- 最後比對 Sitemap 與站内連結中的寫法是否與 canonical 一致。
修正之後怎么观察
改完不保證立刻變化，索引更新本身需要時間。可以關注的观察点包括：日誌里被指向 URL 的抓取是否恢复正常、頁面的返回狀態是否稳定、Sitemap 中的時間标记是否真實、索引中呈現的地址是否逐步回到自指 URL。短期内不要反复改動同一批信号，否則很难判断哪一次調整起了作用。
canonical 是建议而不是指令，最终归並判断在搜尋引擎手里。因此寫法要尽量單一、明确、可驗證，並且與站内其他信号保持一致。
几種容易被忽略的情况
- 分頁第二頁之後统一 canonical 到第一頁，導致深层列表内容不被單獨收錄。
- 商品的颜色、尺碼、排序參數生成了獨立地址，却没有收敛到主商品頁。
- 打印頁、AMP 或纯移動版頁面互相指向混乱。
- 站内搜尋结果頁被模板自動加上了指向首頁的 canonical。
- 被采集或镜像的域名同时可訪問，且带上了與原站相同的标簽。
把 canonical 当成一條需要维護的配置，而不是一次性寫完的标簽。新增頁面類型、上线新模板、更換域名或接入 CDN 时，都應该回头抽查一遍，確認它仍然指向正确的地址。