入口页本身也是一个普通网页，搜索蜘蛛要抓它，先得把服务器响应拿到手。如果这个页面经常慢、偶尔超时，或者断断续续返回 5xx，蜘蛛不会替你判断“是网站不稳定还是内容有问题”，它只会记录一次失败的抓取。次数多了，抓取端的策略就会调整。下面说清楚它大致怎么调、你怎么在日志里看出来，以及先改什么。
蜘蛛遇到慢响应的基本处理逻辑
抓取资源是有限的。当一台主机反复出现连接超时、响应时间过长或错误码密集，抓取端通常不会继续按原来的频率敲门，而是做两件事：一是降低对这台主机的并发和访问频次，二是把抓取额度挪到其他更稳定的站点或同一站点的其他路径上。这个调整不太像“惩罚”，更像成本控制——在不确定能不能拿到内容的前提下，重复尝试的性价比很低。
需要区分的是超时和明确的错误码。返回 500、502、503 这类状态码，抓取端至少知道服务器在回应；而连接超时、TLS 握手失败、响应头迟迟不来，属于“没有下文”，处理上往往更保守。
入口页不稳定时，抓取端常见的几种变化
- 抓取频次下降：原来每天来几次，慢慢变成隔几天来一次，抓取时间点也变得零散。
- 抓取页面数量收缩：蜘蛛可能只抓主入口，不再继续跟进入口页里的链接，目标 URL 的发现和抓取自然被推迟。
- 抓取时段集中：如果服务器在某个时段相对稳定，日志里会明显看到抓取集中在那几个小时。
- 已抓取记录的更新变慢：旧版本内容长期不变，新内容迟迟不替换。
- 间歇性成功但效果打折：偶尔抓通了，但页面返回的是超时后的空壳或半截内容，抓到的可能不是你想给的东西。
怎么从日志判断是入口页自身的问题
- 按蜘蛛 UA 过滤出对入口页的请求，统计响应码分布：200、3xx、4xx、5xx 各占多少。
- 看响应时间的分布，而不只看平均值。平均值正常但 p95、p99 很高，说明偶发慢请求已经不少。
- 对照同一时间段的服务器监控，确认慢是数据库、上游接口，还是带宽与连接数打满。
- 检查有没有“超时后仍返回 200”的情况：部分脚本超时后输出了半截页面，抓取端会当成正常内容存下来。
- 看蜘蛛卡在哪一步：DNS、TCP、TLS 还是首字节。不同阶段的超时，排查方向不一样。
稳定下来之后，抓取会自己回来吗
通常需要一个恢复过程，不是当天修好当天就恢复原样。抓取频次的回升往往和持续的稳定表现相关：一段时间内响应正常、错误率低，抓取量会试探性地逐步增加。中间如果再出现一次大面积超时，之前的积累可能被打断。所以与其反复小修小补，不如先保证一段时间的连续性，让抓取端重新建立对这台主机的信任。
改进顺序：先保证不超时，再谈链接和内容
- 先解决超时：给入口页加静态化或缓存，把动态查询和外部接口调用挡在蜘蛛访问路径之外。
- 正确返回状态码：临时故障用 503 并带上 Retry-After，让访客和蜘蛛都知道这是暂时状态；不要用超时挂起或返回空页面来代替。
- 减少入口页自身负担：合并重定向、精简首屏资源，避免入口页必须等第三方脚本加载完才渲染出链接。
- 保证链接是服务端可见的：入口页再稳，如果目标链接靠 JS 后插，蜘蛛拿到的也只是一个没有出口的页面。
- 让入口页和目标页的稳定性一致：入口页很稳、目标页总 5xx，抓取同样会卡在后半程。
把入口页当成抓取链路的第一个关卡：这一步不稳，后面的提交、外链、内容调整都容易被堵在这里。稳定性属于基础项，通常比技巧更能决定抓取能不能按预期推进。
最后提醒一点：日志里的抓取变化往往是多因素叠加的结果，服务器慢只是其中一种可能。排查时先固定一两周的窗口观察趋势，再下结论，比只看单天数据更靠谱。