canonical 是给搜尋引擎的提示，不是强制指令。你指定了 A 作為規范頁，索引里却出現 B，這在带參數、多域名或歷史遗留較多的站上很常见。與其纠结“為什么不听我的”，不如先確認這條提示有没有被讀到，再判断它為什么更倾向另一個 URL。
第一步：確認 canonical 是否真的被讀到
- 位置與生成方式：标簽是否在 head 里；如果是脚本動態插入，抓取时可能還没生成，需要看渲染後的 HTML。
- 指向是否有效：href 是否為绝對地址，是否指向一個 301、404 或需要登入才能訪問的頁面。
- 規范頁本身的狀態：如果 A 被 robots.txt 挡住，或 A 自己带了 noindex，這條 canonical 基本不會生效。
- 是否出現多個：同一頁寫了两條互相冲突的 canonical，等于把判断權交回给爬虫。
第二步：看索引選代表頁时還參考了什么
canonical 只是信号之一。内鏈指向、sitemap 里的出現情况、多個 URL 的内容相似度、URL 结构是否稳定、哪個地址更早被收錄，都會影响最终结果。常见的一種情况是：canonical 指向 A，但全站内鏈和 sitemap 都指向 B，最後索引里留下的是 B。
第三步：按场景對号入座
带參數與被清理後的地址
篩選、排序、追踪參數會生成大量近似 URL。如果站内連結里參數顺序不统一，或者不同頁面模块用了不同的參數寫法，索引很容易選到一個你没预期的版本。做法是让内鏈统一指向無參數或參數固定的版本，其余入口用 301 收拢，而不是只在頁面里寫一條 canonical。
协议、子域與大小寫
http 與 https、带 www 與不带 www、路径大小寫不同，都可能被当作不同 URL。這類問题的重点不是补 canonical，而是從服務器层面把非規范版本 301 到規范版本，並检查 sitemap 和站内連結是否還有舊寫法残留。
分頁與聚合頁
列表分頁、标簽聚合頁、搜尋结果頁之間内容高度重叠时，索引可能選聚合頁，也可能選其中某一頁。先明确這類頁面的取舍意向：需要留的就给它稳定的入口和唯一标题，不需要留的就挡在索引之外，避免留下模糊地带。
移動版與獨立域名
PC 與移動端分属不同域名时，两邊的 canonical 和互指關系要成對检查。只在一侧寫規范，另一侧没有對應提示，容易让索引在两套地址間摇摆。
第四步：改動後的處理顺序
- 先统一站内信号：内鏈、sitemap、canonical 尽量指向同一個 URL。
- 再處理入口：不该被訪問的重复地址用 301，而不是只靠頁面内的提示。
- 確認規范頁本身返回 200、可抓取、可索引。
- 记錄改動時間，等一次完整的重新抓取後再核對索引中的實际 URL。
当内鏈、sitemap 和 canonical 各指一個方向时，爬虫只能自行判断，结果通常不會刚好等于你的预期。
別急着反复改
代表頁的選擇需要重新抓取和重新评估，短期内反复調整只會让信号更乱。比較稳的做法是：先记錄目前索引里的實际 URL 和頁面狀態，改一次，给它一個抓取周期，再對照结果决定下一步。