站内内容重复时，最常见的處理办法是加 canonical 标簽，告诉搜尋引擎“几個地址里，哪個才是正式版本”。但實际操作中，canonical 常常不是没起作用，而是被寫成了另一種問题：本来自指的頁面被指向別處，或者指向了一個根本不能作為正式版本的地址，结果收錄归属越来越乱。
canonical 只是提示，不是命令
先说一個容易被誤解的前提：canonical 是给搜尋引擎的建议，不是强制指令。系統會结合内鏈、sitemap、重定向、頁面相似度等信息综合判断，如果這些信号相互矛盾，canonical 可能被忽略。所以排查时不要只盯着這一行代碼，要把它和別的信号放在一起看。
几類常见的寫偏方式
- 指向跳轉地址：canonical 指向的 URL 會 301 到別處。此时應该直接指向最终地址，中間多一层没有意义。
- 指向不可索引的頁面：目标頁被 robots.txt 屏蔽、带 noindex，或者返回 404、5xx。正式版本自己都進不了索引，合並自然無從谈起。
- 多個 canonical：模板和 CMS 插件各輸出一份，HTML 里出現两條不同地址。搜尋引擎通常只能選一條，或者直接忽略。
- 内容並不相同：把两個主题不同的頁面用 canonical 强行合並，属于誤用；canonical 用于高度相似或完全相同的正文，不用于“權重传递”。
- 相對路径或大小寫、协议不一致：多數情况能被解析，但和實际地址不逐字一致时，容易让判断产生偏差。
- 分頁頁面全都指向第一頁：這是一種取舍，不是绝對错誤，但會让後續分頁里的内容失去被發現的机會，需要结合业務决定。
- 靠 JS 動態寫入：如果 canonical 只有脚本执行後才出現，要確認渲染环节能讀到它，否則抓取早期看到的頁面是缺失這個信号的。
按顺序自查一遍
- 確認這個頁面本身是否應该被收錄。如果内容單薄、只是聚合入口或临时頁面，该做的是 noindex 或收敛入口，而不是加 canonical。
- 检查 canonical 是否為自指（預設情况應当自指），且與實际地址逐字一致，包括协议和大小寫。
- 打開 canonical 指向的地址，確認返回 200、没有 noindex、没有被 robots.txt 屏蔽，並且能被正常抓取。
- 核對该地址是否出現在 sitemap 中、是否在站内有正常入口、内鏈是否也指向它。信号一致时，判断成本最低。
- 處理完观察一段時間，用站内搜尋或 URL 检查工具看归属是否收敛，不要当天改当天就下结论。
別把 canonical 和另外两件事混在一起
一是抓取與收錄的区別：canonical 影响的是“收錄哪一個”，前提是相關 URL 已经被抓取。目标頁長期抓不到，合並效果就無從体現。二是重复内容與收錄取舍的区別：重复内容不等于惩罚，很多情况下搜尋引擎會自行選擇版本，canonical 只是降低它選错的概率。
一句提醒：canonical、noindex、robots.txt、重定向是四件互相獨立的事，用错组合时，经常出現“以為屏蔽了却還在收錄”或“以為合並了却两個都在”的情况。
如果站内确實存在大量參數頁、篩選頁，與其逐頁纠 canonical，不如先從入口和連結结构上减少低價值 URL 的产生，再處理剩下的部分，成本會低很多。