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 时，都应该回头抽查一遍，确认它仍然指向正确的地址。