排查收录时，canonical 常被当成“设了就完事”的标签。实际上它只是给搜索引擎的一个提示：如果它指向的那个版本本身抓不到、被屏蔽或者返回错误，你希望被收录的页面会更难进入索引，而不是更快。
这里讨论的是一种比较隐蔽的情况：当前页面本身没有问题，但 canonical 指向的目标版本不具备被收录的条件，结果两个版本都卡在索引之外。
canonical 是提示，不是“指定收录”的指令
canonical 的作用是合并重复信号，把多个相似 URL 的权重收敛到一个版本上。它既不会让目标页面一定被收录，也不会阻止抓取当前页面。理解这一点，很多“设了 canonical 还是没收录”的困惑就说得通了：问题往往不在当前页面，而在指向的那个 URL。
三种常见的指向错误
指向已经返回 404 或 410 的 URL
改版、批量换模板、删栏目时最容易出现。旧模板里写死了 canonical，模板复制到新栏目后没有替换，指向的路径已经不存在。搜索引擎抓取当前页面，顺着 canonical 去确认目标，拿到 404 之后既无法合并信号，也很难放心收录当前页面。
指向被 noindex 或 robots.txt 屏蔽的页面
另一种情况是 canonical 指向的版本恰好被 meta noindex、X-Robots-Tag 或 robots.txt 挡住。目标版本不参与索引，等于把一个“不能被收录的版本”定为标准版本，当前页面的收录也会跟着受影响。
指向重定向链中间的 URL
canonical 指向 http 版本，而 http 又 301 到 https；或者指向带参数的 URL，参数版本再跳转到干净版本。链路过长时，确认过程会被拉长，核对时也更难判断最终落到哪个 URL。还有一种常见失误是整站 canonical 都指向首页或某个栏目页，这会让大量本该独立收录的页面失去机会。
一份可执行的核对顺序
- 抽样。按模板分组取样本页面，优先选收录状态异常的那些，别只看首页。
- 取实际输出的 HTML。用抓取工具或查看源代码，确认 canonical 的最终值，而不是模板文件里写的值，JS 或后端拼接都可能改变结果。
- 核对目标 URL 的可索引性。状态码是不是 200，有没有 noindex、robots.txt 屏蔽、登录墙或空白内容。
- 反查自引用。同一模板的其他页面是否都正确指向自身？如果整站都指向同一个 URL，问题就不在个别页面。
- 比对 sitemap 与内链。提交的 URL 与 canonical 值是否一致，站内链接是否大量指向非标准版本。
- 记录改动时间。修改后按抓取周期观察，别在第二天就下结论。
自引用与多版本共存的处理
规范做法是让每个页面 canonical 指向自身，除非确实存在重复版本。确实需要合并时，主版本应当是：状态码正常、内容完整、无 noindex，并且有内链和 sitemap 支持的那个 URL。
判断主版本的顺序可以参考：先看内容是否完整，再看 URL 是否稳定，最后看内外链是否集中。三者冲突时，优先保留不需要重定向就能长期存在的版本。
修正之后看什么
改完指向关系后，观察重点是抓取与索引状态是否同步变化：目标版本有没有被正常抓取，原页面在索引里是消失还是被替换。指标上不要只盯总收录量，按模板分组看更清晰。索引更新存在延迟，通常要经过若干次抓取周期，期间状态反复也属正常。
如果核对完发现 canonical 指向没有问题，页面依然不被收录，排查方向就该转到正文质量、模板重复度、内链深度这些层面，而不是继续在标签上反复调整。