核对收录时，最容易忽略的一步是先确认搜索引擎到底有没有把这个页面抓下来。URL 提交了、内链也铺了、正文也不算薄，可索引里就是没有它，这时不少人的第一反应是内容和标题不够好，于是开始改版式、调结构。但如果抓取请求本身就没成功，后面所有关于内容质量的判断都建立在错误的前提上。
先把「没抓到」和「抓到没收」分开
这两件事的处理方向完全不同。前者是服务器或网络层的问题，后者才是内容与结构层面的问题。判断方法并不复杂：看抓取统计里这个地址最近一次成功返回的时间，以及返回的状态码。如果最近一次记录还是几个月前，或者根本没有记录，那大概率是抓取环节卡住了；如果最近几天都有成功抓取，但索引里依然没有，问题才轮到内容侧。
还有一个中间状态值得注意：抓取成功但拿到的是空壳。比如返回 200，正文区域却是空的，或者只有模板框架。这种情况在索引侧看来，和抓取失败的效果差不多，都需要回到抓取结果去看。
常见的几种抓取失败表现
5xx 与超时
服务器错误和响应超时是最常见的两类。数据库连接不稳、缓存被击穿、接口调用超时，都可能让页面在蜘蛛访问的那一瞬间返回 5xx。这类错误的影响会被放大：连续出现之后，抓取工具通常会主动降低对这个站点的抓取频率，恢复起来需要一段时间。
超时则更隐蔽。带宽正常，只是页面响应慢，比如首屏依赖一个慢接口，或者大量同步请求阻塞了渲染。单个请求可能只是慢，但批量抓取时就会变成大面积超时。
403 与 429
防火墙规则、UA 拦截、频率限制，都会让请求在到达应用之前就被挡回去，表现是返回 403 或者 429。有些站点为了防爬做了比较激进的策略，结果把正常的搜索抓取也一起拦了。判断方法很简单：用不带 Cookie 的普通请求访问同一地址，看看是否也会被拦。
协议与跳转层面的问题
HTTPS 证书过期、证书链不完整、HTTP 到 HTTPS 的跳转链条过长、跳转成环，都会让抓取在半路中断。尤其是改版或者接入 CDN 之后，跳转规则容易层层叠加，本来一跳能到的地方变成三四跳。
按模板分组排查，比逐个看有效
- 按模板分组取样，每个模板挑几条有代表性的 URL，不要从首页开始一条条点。
- 用不带 Cookie、不带登录态的请求访问，看到的状态码和响应头才是抓取工具看到的那一份。
- 对比同一模板下能抓到的页面和抓不到的页面，差异通常集中在某个参数、某台后端机器或者某段时间。
- 把失败记录按时间段排一遍，判断是持续性的，还是集中出现在高峰时段。
- 如果站点有多个出口 IP 或后端节点，逐个验证，确认不是单台机器的问题。
修好之后，别马上按收录结果判断
抓取恢复并重新访问之后，到索引更新之间还有一段间隔，这段时间里收录数不会立刻变化。比较稳妥的做法是把抓取失败率和收录率分开记录，先看失败率是否降下来，再看索引里的变化。两者混在一起看，很容易把正常延迟当成没修好，或者把局部修复当成整体好转。
抓取是收录的前置条件，但它不是收录本身。先保证请求能拿到一份完整的页面，再讨论这份页面值不值得进索引。
还有一点常被漏掉：如果页面本身可以正常抓取，只是内容不够独立，那不该在抓取层面花太多时间。反过来，如果抓取成功率长期偏低，再怎么优化正文也不会明显改变结果。先把状态码、响应时间和拦截规则这三项对齐，再去谈内容，顺序会顺很多。