抓取日志里有记录，内容也不是拼凑的，但索引里始终搜不到，这种情况很容易被归到“页面质量不够”。在动内容之前，先把三处设置核对一遍，通常更省时间：noindex、canonical、robots.txt。它们属于开关型问题，一旦配错，页面本身再好也拿不到收录机会。
一、noindex：最直接的拒绝收录
noindex 常见有两种写法：一种是页面 head 里的 meta 标签，另一种是服务器返回的 X-Robots-Tag 响应头。后者往往优先级更高，而且不出现在页面源码里，只看 HTML 很容易漏掉。
- 模板继承：列表页、筛选页、打印页的模板被复制到详情页，禁止收录的指令跟着一起带了过去。
- 响应头注入：CDN、安全插件或测试环境用的规则被同步到了正式环境。
- 批量规则过宽：为了控制参数页，给带参数的 URL 统一加了 noindex，结果正规详情页也被覆盖。
核对方式很直接：抓一次页面源码看 head，再用抓取工具或接口看响应头，两处都要确认。
二、canonical：指错方向等于把页面让出去
canonical 声明的是这一组内容里应该被索引的代表版本。写错方向时页面不会报错，但收录机会会被转移到别的 URL 上。
- 相对地址解析异常：写成本地路径，却被解析到了错误域名或层级。
- 协议与主机名不统一：http 指向 https，带 www 与不带 www 混用。
- 多版本互指：同一内容的多条 URL 各自 canonical 到自己，等于没有声明。
- 分页指向第一页：详情页被合并，长期拿不到独立索引。
处理原则是让每个页面的 canonical 指向自身或真正唯一的代表版本，并保持协议、主机名、路径写法一致。
三、robots.txt：拦住抓取，也拦住了后续判断
robots.txt 的 Disallow 只阻止抓取，并不直接阻止索引，这带来两个容易误判的情况：被拦住的 URL 可能出现在索引里却没有正常摘要；页面本来就没被抓到，即使再补一条 noindex 也不会生效，因为机器没机会读到它。
所以当 robots.txt 与 noindex 同时使用时，要先确认顺序：先放开抓取，再让 noindex 生效，最后才是提交与观察。反过来做，往往只会看到“抓取量正常但收录不动”的假象。
四、一个可复查的核对顺序
- 确认目标 URL 是否允许抓取，robots.txt 有没有误拦整站或目录。
- 查看响应头里是否有 X-Robots-Tag，页面返回状态码是否为 200。
- 查看页面 head 里的 meta robots 是否被模板继承。
- 确认 canonical 指向自身或正确的代表版本，写法与协议保持统一。
- 修改完成后重新抓取一次，隔几天再查索引状态。
把改动记录下来
设置类问题容易被反复踩，建议用一张简单的表记录：URL、问题类型、修改时间、修改内容、复查日期。同一批页面集中出问题时，表格能让规律更快显现，比如它们是否都来自同一个模板或同一次发布。
设置层面的问题通常比内容问题好修，也更容易被忽略。页面不进索引时，先花十分钟排掉这三处开关，再谈内容调整会更有方向。