同一篇文章，如果在站内能從好几個網址打開，對訪客来说差別不大，点哪個都能看。但對搜尋引擎来说，這是典型的重复内容场景：同一份内容被当成几個頁面分別收錄、分別計算，抓取预算被摊薄，外鏈權重被分散，日誌里也會反复出現同一篇内容的不同 URL，排查問题时更难看清楚。canonical 标簽和網址規范化，就是用来把這類入口收口的工具。
先弄清一件事：同一篇内容可能有几個入口
在動手寫 canonical 之前，先花十分钟列一下，你的站点到底通過哪些形式暴露同一個頁面。常见的来源包括：
- 协议與主机名：http 與 https、带 www 與不带 www，如果四者都能打開，就有四個入口。
- 路径寫法：带结尾斜杠與不带斜杠、目錄名大小寫不同、多余的 index.html。
- 參數：来源追踪參數、排序參數、會话 ID、分頁參數。
- 功能頁副本：打印版、移動版、AMP 版、分享预览頁。
- 内容聚合：标簽頁、专题頁、作者頁把正文整段搬了過来，和原文高度重合。
把這些入口列成一張表，後面每一步自查才有對照物。
canonical 是提示，不是指令
需要先摆正预期：canonical 标簽對搜尋引擎来说是建议，不是强制命令。它不會自動让另一個網址消失，也不會改變訪客實际訪問的地址。真正让舊網址不再作為獨立入口存在的，是301 重定向。所以一個合理的做法是：能重定向的尽量重定向，不能重定向或者需要保留訪問的（比如带參數的跟踪連結），再用 canonical 指明規范版本。
把 canonical 当成“說明哪個版本是我認可的主版本”，而不是“让其他版本從索引里消失的開關”。
自查清單：從這几處逐個核對
1. 每個頁面是否都有 canonical，且指向自己
很多站点的問题不是寫错，而是漏寫。用爬虫抓一遍全站，把返回狀態碼為 200 的 HTML 頁面挑出来，逐個检查 head 里是否存在 canonical，並且它指向的地址與目前訪問地址是否一致。如果列表頁、分類頁、詳情頁大量缺失，先补齐這一层。
2. canonical 指向的地址是否真實可訪問
常见的坑有几種：canonical 寫的是測試域名、寫的是已经 404 的舊路径、寫的是 http 而站点早已全站 https、多個頁面互相指来指去形成环。這几種情况都會让标簽失去意义。核對办法很简單——把全站 canonical 的地址抽出来，逐個請求一遍，只看狀態碼和最终跳轉地址。
3. 分頁頁面不要全部指向第一頁
列表翻到第 5 頁，如果 canonical 仍然指向第 1 頁，等于告诉搜尋引擎後面几頁都是重复的，那些頁面上的内容就可能長期不被處理。分頁的常規做法是让每一頁 canonical 指向自身，或者至少不要一股脑指向首頁。
4. 別让所有頁面都指向首頁
有些模板在開發阶段留了一句預設 canonical，结果整站几百個頁面全部指向首頁。這種情况比漏寫更麻烦，因為它會主動传递一個错誤信号。上线前用模板級別检查一次，比事後逐頁翻要省事得多。
5. 動態渲染的頁面，canonical 可能被改掉
如果 canonical 是由前端脚本注入的，要確認脚本执行後的最终结果，而不是只看初始 HTML。有些站点初始 HTML 寫的是對的，脚本跑完之後反而被覆盖成目前带參數的完整網址。用支持执行 JS 的方式抓一次，對比两種结果。
6. 内鏈、站点地图、分享連結寫法是否统一
規范化不只是标簽的事。站内連結如果一半带 www、一半不带，一半带结尾斜杠、一半不带，搜尋引擎顺着爬就會不断發現新變体。建议固定一種寫法，然後检查導航、面包屑、正文内鏈、頁脚、站点地图，让它們都指向同一個規范地址。站点地图里尤其不要出現重定向地址和带跟踪參數的地址。
把這件事變成定期動作
網址規范化不是一次性的上线检查。新栏目上线、換域名、加 CDN、改路由規則、接入新的营销追踪工具，每一步都可能引入新的地址變体。比較省心的做法是固定一個频率，比如每月一次，抓取全站頁面，輸出三份對照資料：返回 200 的頁面清單、各自的 canonical 地址、内鏈與站点地图中出現的地址。三者對不上，就是需要處理的地方。
另外，抓取日誌也值得顺手看一眼。如果同一條内容在日誌里以多種 URL 反复出現，而且都被正常抓取，那基本可以確認規范化没做到位。這類問题越早收敛，後面的抓取效率越稳定。