蜘蛛对站点的印象，不只是“页面返回了什么”，还包括“拿回来的过程顺不顺”。同样的 HTML，放在毫秒级响应的静态文件上，和放在要等两秒的接口后面，蜘蛛后续的访问节奏往往不一样。
蜘蛛能感知的几项服务器指标
从爬虫角度看，一次抓取大致会拆成：建立连接、发送请求、等待首字节（TTFB）、传输正文、断开或复用连接。其中和服务器关系最直接的是 TTFB 与传输速度，其次是错误率。
- TTFB 偏高：常见于数据库慢查询、未命中缓存、服务端渲染较重、同步调用第三方接口。
- 传输慢：正文体积大、未做压缩、带宽被占满、CDN 回源慢。
- 错误率：5xx、超时、连接重置，哪怕只占几个百分点，也会影响判断。
响应变慢后，抓取节奏常见的变化
- 单位时间内的抓取请求数下降，两次访问之间的间隔被拉长。
- 原本会逐层跟进的路径，可能停在某一层不再深入。
- 部分 URL 被反复尝试却拿不到完整响应，实际上等于没抓到。
- 如果站点同时在提交 Sitemap，新 URL 的首次发现也会被推后。
这些变化谈不上是惩罚，更像是爬虫在控制对单个主机的压力：拿不到就先退出，过一阵再来。问题在于，站点如果一直慢，这个“过一阵”会越来越长。
偶发 5xx 比稳定 503 更麻烦
整站维护时返回 503 并带上 Retry-After，蜘蛛通常能理解。真正容易出问题的是另一类：绝大多数请求是 200，但每隔几十次冒出一个 500 或网关超时。这种随机性让爬虫无法判断是临时故障还是页面本身有问题，处理方式往往是降低频率、减少并发，把一个本来正常的站点当成不稳定站点对待。
排查时不妨把日志按状态码和响应时间分组，看 5xx 是集中在某个接口、某台后端，还是集中在某个时间段。集中就说明是局部问题，不必大动干戈。
连接层也值得看一眼
除了应用层，连接复用、TLS 握手、DNS 解析、CDN 回源都在这一趟里。如果服务器对每个请求都重新握手，或者中途直接掐断 keep-alive，爬虫每次抓取的成本都会变高。表现出来就是：日志里请求条目不少，但完成的有效抓取不多。
可以自查的几个信号
- 日志里响应时间的中位数和 P95 差多少，长尾是否集中在某类 URL 上。
- 超时和 5xx 的占比，以及是否随着并发升高而明显上升。
- 同一台服务器上多个站点的抓取量是否此消彼长，说明资源在互相挤占。
- Sitemap 中提交的 URL，从提交到首次出现抓取记录的间隔有没有变长。
调整方向
- 把能静态化的页面静态化，减少动态渲染带来的等待。
- 给爬虫路径单独设置缓存与超时上限，避免慢接口拖住整条链路。
- 精简影响首屏的同步请求，正文尽早输出，边生成边传输。
- 错误页要稳定可辨：该 404 的别返回 200，该 503 的别返回 500，别让爬虫去猜。
- 扩容或限流不要一步到位，观察几天日志里的抓取量变化再决定下一步。
服务器侧的稳定与响应速度，不直接决定页面能不能被收录，但它决定了蜘蛛愿不愿意多来几趟、多走几层。把抓取过程里的等待、超时和随机错误压下去，后面谈内链结构和抓取路径优化才有意义。