發現某個頁面迟迟不進索引，很多人第一反應是去看蜘蛛日誌、去查 sitemap、去改内鏈。這些方向没错，但顺序上有個更省時間的起点：先確認這個 URL 在指令层有没有被明确挡在外面。抓取和收錄是两個阶段，而 robots.txt、noindex 類指令、canonical 指向，恰好卡在這两個阶段的前面。如果頁面本身被拒绝處理，後面的抓取频率、内鏈權重都谈不上。
指令层先看四样東西
所谓指令层，指的是網站主動告诉搜尋引擎「這個頁面可以怎么處理」的那些信号。它們分布在几個不同位置，容易被漏掉。
- robots.txt：整站或整個目錄被 Disallow 之後，蜘蛛通常连請求都不會發出。這類頁面在訪問日誌里看不到，但在 sitemap 里可能還挂着。
- HTML 里的 noindex 元标簽：頁面能被抓取，但抓完不會進索引。典型特征是「日誌里有請求、索引里没有结果」。
- 响應头里的 X-Robots-Tag：常由服務器、CDN 或中間层下發，不在模板文件里，排查时最容易漏。它的作用和元标簽類似，但生效位置和優先級需要單獨確認。
- canonical 指向：頁面没被禁止，却把「我是主版本」的身份让给了別的 URL。核對时看到索引里那條，其實是另一個地址。
被挡住时，症状各不相同
同样是「不收錄」，指令层原因不同，表現出来也不一样，可以先按症状缩小范围。
日誌里完全没有這個 URL
優先怀疑 robots.txt。逐條看規則，注意目錄深度、通配符和行末是否被注释掉。站点改過目錄结构时，舊規則可能還在屏蔽已经不存在的路径，也可能恰好覆盖了新路径。
日誌里有請求，但就是没有索引
這種情况去看頁面源碼里的 noindex，以及响應头里的 X-Robots-Tag。两者只要有一個生效，頁面就會被排除在索引之外。用命令行直接看响應头，比在浏览器里查看源碼更可靠。
索引里出現的是另一個地址
多半是 canonical 規則出了問题。由程序统一生成的 canonical，一旦匹配逻辑寫错，可能把全部内容頁指向列表頁或首頁。此时正文頁能抓取、能返回正常狀態碼，但索引里收錄的是被指向的那個 URL。
排查一個 URL 的實操顺序
- 用無痕模式打開该 URL，查看頁面源代碼，搜尋 noindex 關键字。
- 用命令行查看响應头，確認狀態碼和 X-Robots-Tag，顺便數一下中間经過几次跳轉。
- 打開 robots.txt，對照该 URL 所在目錄，判断是否被規則覆盖。
- 確認 canonical 指向的是自己還是別的地址，是否與實际主版本一致。
- 以上都干净，再去看抓取频率、頁面内容和内鏈层面的問题。
一個頁面同时出現 noindex 和 canonical 指向別處的情况並不少见。两個信号叠加时，不要凭印象判断谁優先，以實际生效的结果為准。
最常踩的坑是环境不一致
測試环境為了不被收錄，模板里加了 noindex，上线时忘了去掉；或者反過来，正式环境被整体套上了一個限制抓取的头。也有站点把 robots.txt 当成临时開關，測試結束忘了改回来。這類問题一旦發生，影响通常是整批頁面，而不是單頁。
還有一種更隐蔽的情况：分环境配置寫在 CDN 規則里，代碼仓库里完全看不到痕迹。排查时只看模板文件，很容易得出「一切正常」的错誤结论。
把检查做成固定動作
上新栏目、站点改版、更換 CDN、調整模板，都是容易碰到指令层的节点。與其每次出問题再回头查，不如把這几項做成發布前的固定動作：抽样几個有代表性的 URL，看响應头、看源碼、看 robots.txt、看 canonical。花費的時間不多，但能省掉後面大量無意义的抓取分析。
顺序上记住一句话：先確認頁面有没有被允许進，再讨论頁面值不值得進。前者是開關問题，後者是质量與竞争問题。混在一起查，只會让排查周期越拉越長。