蜘蛛愿意来，不等于抓得完。很多站点内容正常、Sitemap 也提交了，抓取量却长期低位徘徊，最后追到服务器这一层：响应慢、偶发超时、5xx 间歇报错。抓取队列有时间预算，一次请求超时，这一轮基本就放弃了，重试要等下一轮；同一批 URL 被超时反复打断，重新抓取间隔就会被拉长。所以抓取衰减常常不是“蜘蛛不来”，而是“来了没抓成”。
先把问题量化，再动手改
凭感觉调服务器参数，很容易改错方向。建议先同时看两类数据：蜘蛛侧和服务端侧。
抓取日志里值得关注的字段
- 响应状态分布：200、301/302、404、429、5xx 各自占比，尤其看 5xx 是否集中在某几个 URL 或某个时段。
- 响应耗时：按路径分组统计，找出明显慢于站点平均值的模板页，比如带筛选条件的列表页、聚合页。
- 重试痕迹：同一 URL 在短时间被多次请求而始终未成功，说明服务端在拖后腿而不是入口不足。
- 抓取时段分布：如果失败请求集中在流量高峰，多半是资源争抢，而不是蜘蛛本身的问题。
服务端要看的指标
- TTFB（首字节时间）的 P95、P99，而不是只看平均值；平均值好看、长尾很慢是常见情况。
- 数据库慢查询数量、缓存命中率、PHP/应用进程排队情况。
- 带宽出口是否被打满，静态资源是否与页面请求争抢连接。
- 反向代理与源站之间的超时设置是否短于应用实际处理时间。
常见诱因与处理方向
- 模板页查询过重：列表页每次动态拼装、缺少缓存，是最典型的 TTFB 高发点。给列表页做短周期缓存，比优化单个页面更有效。
- 缺少压缩：HTML 未启用 gzip 或 brotli，传输体积翻倍，在带宽紧张时直接表现为慢和超时。开启压缩后注意 Content-Length 与实际长度一致，避免响应被截断。
- 连接与超时设置不匹配：代理层超时设得比应用短，请求会被提前掐断并返回 5xx。让上游超时留出余量，比事后加机器更省事。
- 第三方资源阻塞：页面渲染依赖外部接口，接口抖动就拖慢整页。关键内容尽量服务端直出。
- 抓取与用户流量争抢：高并发时段可以让蜘蛛命中的缓存优先走静态层，减少对数据库的冲击。
429 与 503 不能同等对待
限流返回 429，通常表示服务器主动拒绝，抓取方会放缓节奏甚至降低频次；503 多表示临时的服务不可用，两者都会抑制抓取，但处理方式不同。如果确实需要限速，应尽量让限流只针对异常高频请求，而不是无差别拦截，否则正常的 URL 发现也会被一起压住。使用 Retry-After 提示恢复时间，比直接返回错误更利于抓取调度。
调整后设一个观察窗口
改完不要当天就下结论。建议以两到四周为一个观察周期，对比调整前后的抓取日志：成功请求数、5xx 占比、TTFB 的 P95，以及热门与长尾目录的抓取覆盖变化。若成功数上升但覆盖率没动，说明瓶颈已从服务器转到入口或内链结构，下一轮再处理那条线。
抓取衰减的排查顺序，建议从“看不到的服务端”走到“看得到的入口”：先确认响应是否稳定、是否能在合理时间内返回完整内容，再谈 Sitemap、内链与 URL 发现。服务器这一层没理顺，后面的入口优化很难体现出来。