canonical（規范标簽）经常被当成让頁面被收錄的工具来用，但它實际做的是另一件事：在多個地址内容相同或高度相似时，告诉搜尋引擎這几個地址里，哪個是你希望代表這一套内容的主地址。它影响的是索引如何選版本，既不是收錄開關，也不决定抓取频率。
它解决的是版本選擇的問题
同一個頁面出現多個地址，来源很多：带跟踪參數、大小寫不同、结尾斜杠有無、www 與非 www、列表頁翻頁、篩選條件组合等。這些地址内容基本一致时，搜尋引擎需要挑一個放進索引，其余的可能被折叠。canonical 就是在這时候提供一個偏好，把索引位置集中到一版，避免同一套内容在索引里反复出現、彼此稀释。
但它是建议而不是命令。如果你指定的那一版本身质量差、返回错誤、被 robots 屏蔽，或者指向關系自相矛盾，搜尋引擎仍然可能按自己的判断選另一個版本。
三種常见寫法
自引用：指向自己
最稳的寫法是在每個頁面的 head 里寫一個指向目前頁面自身的 canonical，地址用绝對地址。它不改變什么，但能减少參數、大小寫之類的變体在抓取過程中被誤判成另一套頁面的机會，也方便统一站内地址格式。做自引用时，地址要和頁面實际返回的最终地址一致，不要寫成一個還要再跳一次的地址。
跨地址指向：多版指向主版
当确實存在多個變体、且你希望只保留一版时，才用跨地址指向。比如带參數的變体、打印版、按篩選生成的地址，都指回不带參數的主地址。前提是各版本内容确實相同；如果篩選後的内容實质不同，價格、库存、型号都不一样，硬指回主版反而會让這些有獨立價值的頁面收不進去。
不寫
不寫也有它的道理。功能頁、站内搜尋结果頁、後台相關頁面這類本来就不打算让索引保留的地址，用 noindex 處理更直接，不需要再用 canonical 绕一圈。
几组容易打架的组合
- canonical 與 noindex 同时出現：一個说保留這一版，一個说別收錄我。两個信号方向相反，结果通常以 noindex 為准，被指向的地址也可能跟着受影响，這種寫法要尽量避免。
- 指向的地址本身不干净：指向一個 404、一個重定向、一個被屏蔽的地址，等于让索引去選一個不存在或進不来的版本，判断只能由系統自己做。
- 一頁出現多個 canonical：模板寫了一個，CMS 又輸出一個，或者 A 指向 B、B 指向 A 互相指，等于没给出明确答案。
- 用 JavaScript 寫入：脚本执行不完整时，标簽可能根本没出現在最终渲染结果里。能用服務端直接輸出的，就別放在 JS 里生成。
- 指向還没收錄的地址：以為 canonical 能把收錄带過去是常见誤区。收錄要靠地址被成功抓取並被判断為合格頁面，canonical 只是在判断過程中提供一個偏好。
和重定向、參數收敛的分工
頁面已经废弃、内容搬到新地址，用 301 更合适，因為它把用戶和抓取一起送過去。canonical 更适合两個地址都要保留、都能正常訪問的场景，比如同一内容的两個展示路径。至于參數造成的地址扩散，優先在連結层面收敛，内鏈统一用干净地址，再配合規范參數處理，canonical 是补充手段，不是唯一手段。
上线後的自查清單
- 抽查几類模板頁，查看源代碼，確認 canonical 出現在 head 中，且寫的是绝對地址。
- 把 canonical 指向的地址逐個打開，確認返回 200，不是重定向、不是错誤頁。
- 检查是否存在多個 canonical、是否存在 A、B 互相指向。
- 對照 robots 屏蔽規則和 noindex，確認没有方向冲突。
- 關掉脚本再看一次，或用抓取工具查看原始 HTML，確認标簽不是靠 JS 才出現的。
- 记錄修改時間，之後在服務器日誌和索引狀態里观察這批地址的變化，不要只看一两天。
把 canonical 当成整理地址顺序的建议书来用，比当成收錄開關更容易得到预期结果。它做的是多個版本之間的取舍，取舍之外的事，還是得靠頁面本身和地址規范来解决。
實际排查中，经常不是标簽寫错了，而是站点同时存在好几套地址、内鏈又不统一。先把地址收敛做干净，再回头看 canonical，往往能少绕不少弯。