排查收錄时，canonical 常被当成“设了就完事”的标簽。實际上它只是给搜尋引擎的一個提示：如果它指向的那個版本本身抓不到、被屏蔽或者返回错誤，你希望被收錄的頁面會更难進入索引，而不是更快。
這里讨论的是一種比較隐蔽的情况：目前頁面本身没有問题，但 canonical 指向的目标版本不具备被收錄的條件，结果两個版本都卡在索引之外。
canonical 是提示，不是“指定收錄”的指令
canonical 的作用是合並重复信号，把多個相似 URL 的權重收敛到一個版本上。它既不會让目标頁面一定被收錄，也不會阻止抓取目前頁面。理解這一点，很多“设了 canonical 還是没收錄”的困惑就说得通了：問题往往不在目前頁面，而在指向的那個 URL。
三種常见的指向错誤
指向已经返回 404 或 410 的 URL
改版、批量換模板、删栏目时最容易出現。舊模板里寫死了 canonical，模板複製到新栏目後没有替換，指向的路径已经不存在。搜尋引擎抓取目前頁面，顺着 canonical 去確認目标，拿到 404 之後既無法合並信号，也很难放心收錄目前頁面。
指向被 noindex 或 robots.txt 屏蔽的頁面
另一種情况是 canonical 指向的版本恰好被 meta noindex、X-Robots-Tag 或 robots.txt 挡住。目标版本不參與索引，等于把一個“不能被收錄的版本”定為标准版本，目前頁面的收錄也會跟着受影响。
指向重定向鏈中間的 URL
canonical 指向 http 版本，而 http 又 301 到 https；或者指向带參數的 URL，參數版本再跳轉到干净版本。鏈路過長时，確認過程會被拉長，核對时也更难判断最终落到哪個 URL。還有一種常见失誤是整站 canonical 都指向首頁或某個栏目頁，這會让大量本该獨立收錄的頁面失去机會。
一份可执行的核對顺序
- 抽样。按模板分组取样本頁面，優先選收錄狀態異常的那些，別只看首頁。
- 取實际輸出的 HTML。用抓取工具或查看源代碼，確認 canonical 的最终值，而不是模板文件里寫的值，JS 或後端拼接都可能改變结果。
- 核對目标 URL 的可索引性。狀態碼是不是 200，有没有 noindex、robots.txt 屏蔽、登入墙或空白内容。
- 反查自引用。同一模板的其他頁面是否都正确指向自身？如果整站都指向同一個 URL，問题就不在個別頁面。
- 比對 sitemap 與内鏈。提交的 URL 與 canonical 值是否一致，站内連結是否大量指向非标准版本。
- 记錄改動時間。修改後按抓取周期观察，別在第二天就下结论。
自引用與多版本共存的處理
規范做法是让每個頁面 canonical 指向自身，除非确實存在重复版本。确實需要合並时，主版本應当是：狀態碼正常、内容完整、無 noindex，並且有内鏈和 sitemap 支持的那個 URL。
判断主版本的顺序可以參考：先看内容是否完整，再看 URL 是否稳定，最後看内外鏈是否集中。三者冲突时，優先保留不需要重定向就能長期存在的版本。
修正之後看什么
改完指向關系後，观察重点是抓取與索引狀態是否同步變化：目标版本有没有被正常抓取，原頁面在索引里是消失還是被替換。指标上不要只盯總收錄量，按模板分组看更清晰。索引更新存在延迟，通常要经過若干次抓取周期，期間狀態反复也属正常。
如果核對完發現 canonical 指向没有問题，頁面依然不被收錄，排查方向就该轉到正文质量、模板重复度、内鏈深度這些层面，而不是繼續在标簽上反复調整。