很多站点在发现重复 URL 被蜘蛛反复访问后，第一反应是加 canonical，然后期待抓取量立刻降下来。实际观察日志时，情况往往不是这样：canonical 已经写对，重复地址仍然隔三差五出现在访问记录里。原因不复杂，只是 canonical 的定位容易被误解。
canonical 处理的是合并，不是抓取
canonical 标签表达的是“这几个地址我更希望哪一个作为代表页”，它作用在索引与合并阶段。蜘蛛会不会访问某个 URL，主要看它有没有在别处看到过这个地址：内链、Sitemap、外链、重定向，甚至历史抓取记录里的旧链接。只要地址还在这些通道里出现，它就有可能被排进抓取队列。
换句话说，canonical 不能替代 301，也不能替代 robots.txt 的抓取限制。它更像一份“归并建议”，蜘蛛会参考，但不会因此就不再发出请求。
重复 URL 仍然被访问的几种常见情况
- 内链没有统一：文章里的推荐位、面包屑、分页仍然链接到带参数或旧域名的版本，蜘蛛顺着链接自然又走到重复地址。
- Sitemap 混入变体：Sitemap 里同时列出 canonical 版本和带参数的版本，等于主动把两个地址都提交了一遍。
- 多协议、多域名：HTTP 与 HTTPS、带 www 与不带 www 如果都能访问，且没有做好跳转，蜘蛛可能分别抓取。
- 历史链接与外部引用：旧页面被其他站引用，蜘蛛沿着外链再次访问，这部分很难完全消除。
- 分页与筛选路径：列表页组合出的 URL 数量大，canonical 指向主列表，但地址本身仍可能被访问。
什么时候需要在意这些额外抓取
少量重复抓取本身不一定是大问题，关键看它挤占了多少抓取额度，以及服务器是否因此变慢。判断方法还是看日志：统计重复 URL 的请求占比、响应时间、状态码分布。如果重复页占比不高、响应稳定，可以先放着；如果它明显消耗抓取预算，或者拖慢了整站响应，再逐项处理。
还要留意一种情况：重复页本身很重，或者需要实时查询数据库生成，那么每次抓取的成本会明显高于静态页。此时优化的重点可能不在 canonical，而在缓存与响应速度。
canonical 自身容易写错的地方
- canonical 链：A 指向 B，B 又指向 C，蜘蛛需要多跳才能理解，效果会被削弱。
- 指向已失效地址：canonical 指向 301、404 或 noindex 页面，合并信号会变得含糊。
- 相对路径与绝对路径混用：不同模板输出格式不一致时，容易解析出意料之外的地址。
- JS 注入后才写入：如果 canonical 依赖脚本插入，蜘蛛需要先渲染才能读到，发现时机可能晚于首次抓取。
- 分页之间互相 canonical：把系列分页全部指回第一页，会让后续页面的内容信号被压缩。
想让重复 URL 少被抓，可以按顺序做这几件事
- 统一站内链接，所有入口都指向 canonical 版本，包括导航、面包屑、相关推荐和分页。
- Sitemap 只保留 canonical 地址，不要同时提交参数版本和默认版本。
- 能跳转的重复入口用 301 收拢，例如多域名、多协议、尾斜杠不一致。
- 确实不需要被抓的参数或目录，用 robots.txt 或参数处理规则限制，但要确认不会挡住有用页面。
- 定期对照服务器日志，看重复访问是否集中在某几个模板或某个目录。
canonical 是建议，不是保证。它可以减少重复页进入索引的概率，但不能阻止蜘蛛发出请求，也无法替代跳转和抓取控制。
把 canonical、内链、Sitemap 和跳转看成一套配合使用的工具，比单独指望某一个标签更实际。先弄清楚重复地址从哪里被蜘蛛发现，再决定用哪种方式处理，通常比批量加标签更省事。