很多站点在發現重复 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 和跳轉看成一套配合使用的工具，比單獨指望某一個标簽更實际。先弄清楚重复地址從哪里被蜘蛛發現，再决定用哪種方式處理，通常比批量加标簽更省事。