蜘蛛来过，但页面没有被完整抓取，这种情况在蜘蛛池运营里很常见。很多人的第一反应是“是不是被识别了”，但实际排查下来，原因往往更朴素：服务器返回了错误、页面响应太慢，或者同一时间涌进来的请求把资源挤爆了。按状态码、超时、并发这三个层面依次看，通常能定位到大部分问题。
第一层：先看状态码，别急着改策略
访问日志里最直接的线索就是状态码。把一段时间内的记录按状态码分组，各段占比一眼就能看出问题集中在哪。
- 200 但正文为空或只有模板壳：后端渲染失败、接口超时被吞掉，日志里却显示成功。这类问题最隐蔽，需要用页面快照或抽样抓取来核对，而不是只看状态码。
- 3xx 跳转链过长：入口页到落地页跳三四次以上，每次都要重新建连，抓取效率会被明显拖低。
- 403 与 429：前者多半是 WAF 规则误伤，后者是限流阈值设得太低。两者表现相似，但处理方式完全不同，需要结合请求头判断。
- 500 / 502 / 504：网关或后端的问题，属于硬失败。这类失败比例一旦升高，先修服务，不要先怀疑蜘蛛。
- 软 404：页面返回 200，内容却是“已删除”“内容不存在”。长期存在会持续消耗这个站点的抓取信任度。
第二层：超时与响应速度
状态码正常，也不代表抓取一定成功。蜘蛛对等待时间是有上限的，超过之后它会断开连接，日志里可能只留下一条不完整的记录。
优先看 TTFB，也就是从请求发出到收到第一个字节的时间。这个指标比页面完整加载时间更能反映服务端状态。常见的拖慢因素有几个：DNS 解析慢、TLS 握手反复重建、后端同步调用外部接口、数据库慢查询。这些都能在服务端监控里看到对应曲线。
实践中的一个参考区间是，把 TTFB 压到几百毫秒以内，超时类失败会明显减少。如果做不到，至少不要让响应时间出现大幅抖动，忽快忽慢比稳定偏慢更麻烦。
第三层：并发与排队
入口页数量上去之后，同一秒可能出现几十甚至上百个请求。这时候瓶颈通常不在代码，而在连接数、带宽和 CPU 上。
并发问题的典型特征是间歇性：闲时一切正常，忙时集中出现 5xx 或超时。如果日志里能看到这种时间上的聚集，基本可以判断是资源排队而不是识别问题。
限流和排队机制要有，但要给搜索蜘蛛留出通道。比较稳妥的做法是分队列处理，把普通访问和蜘蛛访问分开，避免高峰期互相抢占。具体阈值需要结合自己服务器的实测承载能力来定，别人的数字直接照搬意义不大。
一个可执行的排查顺序
- 按状态码分组，先确认失败集中在哪一类。
- 拉出响应时间分布，看 P95、P99 是否明显偏离日常水平。
- 对照同一时间段的并发峰值和服务器负载曲线。
- 以上都正常，再去检查 robots、跳转链和页面内容本身。
- 最后才考虑访问来源和识别层面的因素。
按这个顺序走，多数问题在前两步就能收敛，不必一上来就大改配置。
几个容易被误判的地方
抓取失败不等于站点被处理，抓取量下降也不等于内容质量出了问题。很多时候只是某个入口页被下掉、某次改版改了跳转，或者服务器在某个时段扛不住。
- 单次失败不必大动干戈，先看是不是偶发。
- 抓取量下降要先核对入口页数量有没有变化，再看目标页。
- 把“失败率”单独作为一个指标长期观察趋势，比盯着某一天的绝对值更有意义。
把抓取失败当成一个可以量化的问题来处理，比反复猜测要省力得多。日志、响应时间、并发这三份数据摆在一起，大部分疑问都能得到解释。真正需要长期投入的，是让这套观察持续下去，而不是每次出问题才临时翻一遍记录。