很多站点运营的注意力都放在内容和内链上，直到某天发现蜘蛛来访次数不少，收录却没什么动静。翻日志才看到，大量请求的响应时间在两三秒以上，中间还夹杂着 5xx 和超时。蜘蛛没有无限的耐心，服务器一直让它等，抓取频次自然会往下走。
为什么响应速度会影响抓取
搜索引擎分配给每个站点的抓取资源是有限的，这个额度既看站点本身的状况，也看服务器扛不扛得住。同一段时间里，如果每个请求都要等很久，能抓完的页面数量就会变少；如果错误率偏高，蜘蛛还会主动降速，避免给服务器添麻烦。结果是新页面排队等，旧页面的更新也变慢。
几个值得盯的基础指标
- 首字节时间（TTFB）：从发起请求到收到第一个字节的耗时，最直观的信号。
- 状态码分布：5xx 占比多少，是不是集中在某几个栏目或某个接口上。
- 超时比例：被服务器主动掐断的请求有多少。
- 并发承载：同一时刻能稳定处理多少请求，超过这个数会不会雪崩。
在日志里怎么找线索
把蜘蛛的访问记录按 URL 归类，再对一下响应时间和状态码，通常能看出一些规律：
- 静态页面快、动态页面慢，说明瓶颈在后端渲染或数据库。
- 某个栏目整体偏慢，多半是这个栏目的列表查询写得重。
- 深夜快、白天慢，多半是服务器资源和正常访客在抢。
- 某段时间 5xx 集中出现，可能是重启、发版，也可能被采集打了。
常见的拖慢原因
- 页面每次访问都查一遍数据库，没有缓存层。
- 模板里同步调用第三方接口，对方慢一点，整页就卡住。
- 列表页一次拉出几百条数据，还逐条做关联查询。
- 未压缩的图片和大体积静态文件占满带宽。
- 插件或中间件层层叠加，请求链路越走越长。
可执行的自查步骤
- 选一个正常工作日，取一段至少 24 小时的访问日志。
- 筛出蜘蛛 UA 的记录，统计平均响应时间和 5xx 占比。
- 把最慢的 20 个 URL 列出来，逐个确认是内容页还是功能页。
- 针对最慢的几类页面，先加缓存或做静态化，再复测一次。
- 给响应时间和错误率设一个监控阈值，出问题能第一时间知道。
抓取压力大时怎么处理
如果站点规模大，蜘蛛来访又密集，可以考虑把内容页生成静态文件，列表页做短周期缓存，把数据库压力降下来。也可以在服务器层面做限流，优先保证内容页可用，牺牲一些次要页面。需要提醒的是，不要把 crawl-delay 当成万能药，它只是让蜘蛛慢一点来，并不能解决页面本身慢的问题；过度依赖它，反而会让新内容更晚被发现。
服务器响应是所有运营动作的地基。内容写得再好，页面半天打不开，也很难被好好收录。
小结
响应速度这件事，不需要一步到位做到极致，但至少要保证内容页稳定、快速地返回。定期翻一翻日志，比等到收录下滑之后再回头排查要省事得多。