很多站点的收錄問题，並不是某一條規則寫错了，而是几條規則同时存在、方向却不一样。canonical 指向 A 頁，meta robots 寫着 noindex，sitemap 里還把這個 URL 列着，内鏈也照样指向它——四個信号，四個方向。搜尋引擎最终怎么處理，取决于它自己的優先級判断，而站点這邊往往连冲突存在都不清楚。
信号冲突大多是叠加出来的，不是技術故障
站点上线初期通常只有一两條規則，後来為了處理某個具体問题，又加了一條；再後来改版、換模板、上多語言，又加了一條。每加一次都是在已有狀態上做加法，没人回头检查新舊規則是否互相矛盾。冲突就這样攒下来了。
所以排查的第一步不是找 bug，而是把同一個 URL 上生效的所有信号列出来，看它們是否在回答同一個問题。
常见的几组冲突
- noindex 與 canonical 同頁：頁面本身都不打算進索引，再指定規范版本意义有限；两個信号叠加後，實际表現往往和预期不一致。
- robots.txt 屏蔽與 noindex 同頁：頁面抓不到，里面的 noindex 自然也讀不到，结果可能是 URL 長期留在索引里且内容陈舊。
- sitemap 里列着 noindex 頁面：sitemap 是發現入口，不是收錄承诺，但持續推荐一批注定不進索引的 URL，會消耗抓取资源。
- 301 與 canonical 指向不同目标：一個说“這條地址作废”，一個说“參考那條”，指向不同就會出現交接模糊。
- 内鏈指向被 noindex 的頁面：站内權重還在往一個不打算收錄的地址上導，容易让搜尋引擎反复回訪。
排查顺序：從能不能抓，到要不要收
建议按下面四层依次確認，前一层没弄清，後一层的判断都不可靠。
- 抓取层：robots.txt 是否放行，返回狀態碼是什么，服務器是否把完整 HTML 返回给爬虫。
- 頁面层：HTTP 响應头里的 X-Robots-Tag、HTML 里的 meta robots、rel=canonical，三者寫在哪個位置、说了什么。
- 發現层：sitemap、站内連結、外部連結分別從這個 URL 出發指向哪里。
- 内容层：這條 URL 的内容是否與其他 URL 高度重复，是否存在參數、排序、追踪等衍生版本。
頁面級信号的先後
响應头里的 X-Robots-Tag 與 HTML 里的 meta 通常由不同的模板或服務端逻辑控制，两者冲突时，實际效果以更嚴格的一方為准；具体行為建议以搜尋引擎官方文档為准，並用 URL 检查工具實测確認，而不是凭经驗推断。
canonical 的定位也需要说清：它是提示，不是指令，搜尋引擎可以采纳，也可以忽略。它回答的是“多條相似 URL 里哪一條更该作為代表”，並不回答“這條 URL 要不要進索引”。把它当成收錄開關来用，是很多冲突的源头。
站点級信号：sitemap 和内鏈
sitemap 的职责是帮助發現，不保證收錄。常见的情况是：某個栏目早先全量生成了 sitemap，後来又對這個栏目批量加了 noindex，两邊没有同步，于是 sitemap 一直在推荐一批不该進索引的 URL。内鏈同理，栏目頁、标簽頁、相關推荐模块如果寫死了連結，規則變化後不會自動跟。
一句话原則：noindex 决定收不收，canonical 决定用哪一條，sitemap 和内鏈决定找不找得到。三者不在同一层，冲突时先分清楚對方在回答哪個問题。
收口时可以按這几步走
- 建一張 URL 清單，至少包含狀態碼、robots 指令、canonical 目标、是否在 sitemap、站内入鏈數量。
- 發現冲突时，先按更嚴格的一方统一，確認稳定後再逐條放宽，別一次性改動全部規則。
- 規則調整按批次進行，改完观察一段時間，確認抓取與索引狀態没有異常再推進下一批。
- 检查时看搜尋引擎抓取到的版本，而不是浏览器里渲染後的版本，两者经常不是同一份内容。
收錄信号冲突很少有單一原因，多半是規則一层层叠加的结果。排查时先分层、再定優先級，比逐個试错要省時間，也更容易在下次改版时不重复踩同一個坑。