蜘蛛来抓页面，本质上是一次次 HTTP 请求。如果服务器每次都要让蜘蛛等上好几秒才吐出第一个字节，它不会投诉，只会默默减少来访次数。抓取预算是有限的，同样的预算下，慢站点能抓到的页面更少，新发布的 URL 也更容易被排在后面。
先搞清楚蜘蛛眼中的“慢”是什么
抓取端的时间限制通常比人更严格。用户愿意等三秒，抓取程序可能在更短的时间内就断开连接，只留下一条“未响应”的记录。
- 首字节时间（TTFB）：从请求发出到收到第一个字节。数据库慢查询、同步调用外部接口、未加缓存的动态渲染都会把它拉长。
- 整体下载时间：TTFB 之后的传输过程。大图、未压缩的 HTML、阻塞渲染的资源都会拖后腿。
- 连接成功率：超时、连接重置、5xx 的比例。哪怕只有一小部分请求失败，抓取端也可能主动下调抓取速率。
抓取速率不是你设了多快就有多快，而是服务器撑得住多少、抓取端信任多少，取两者的较小值。
自查清单
1. 看响应码的分布，而不只是平均值
平均响应 200 毫秒听上去不错，但如果 1% 的请求超时、2% 返回 5xx，实际影响远大于平均值带来的安慰。把日志按时段切分，看高峰时段有没有明显恶化。
2. 找出最慢的那批 URL
通常不是首页，而是搜索结果页、带复杂筛选的参数页、调用了第三方接口的详情页。把这些地址单独拉出来测，比笼统地说“网站有点慢”有用得多。
3. 检查限流与防护规则
WAF、防火墙、防爬插件有时会误伤合法蜘蛛：返回 403、429，或者干脆丢包。这类拦截在日志里看起来也像“请求失败”，但原因和性能无关。确认蜘蛛 IP 段是否在白名单内，速率限制是否过于激进。
4. 核对抓取速率设置
- 如果抓取速率曾被下调，先解决服务器本身的问题，再观察它是否自动恢复。
- robots.txt 里的 crawl-delay 只有部分抓取端支持，不要指望它精确控制所有蜘蛛。
- 站点地图与内链结构决定了蜘蛛把时间花在哪，别让它反复爬低价值页面。
常见拖慢响应的原因
- 首页或栏目页每次请求都做全量统计查询；
- 页面渲染时同步调用第三方接口，对方一抖动就把你的 TTFB 拖垮；
- 日志写入、备份任务与抓取高峰撞在同一时段；
- 图片未压缩、未做尺寸适配，单页体积过大；
- 数据库缺少必要索引，列表页查询随数据量增长越来越慢。
一个可执行的观察节奏
- 每周固定时间导出一次抓取日志，按响应码和响应时间分组；
- 对响应时间排名靠前的慢页面逐个定位，改一个记录一个；
- 改动上线后观察两周，看抓取次数与响应码分布是否改善；
- 把“超时占比”和“5xx 占比”写进日常巡检表，而不是等出问题才查。
需要说明的是，响应变快不保证收录变多。它只是拿掉了蜘蛛路上的一块石头，剩下的仍取决于内容质量、页面结构与站内链接。但反过来说，这块石头没搬，后面的努力往往事倍功半。