排查收录问题时，内容质量、内链结构和 sitemap 往往是第一反应。但还有一个更靠前、也更容易被忽略的因素：服务器把页面交出去的速度。抓取和收录是两个环节，抓取在前。如果每次请求都要等上几秒，甚至间歇性超时，爬虫愿意花在这个站点上的抓取量会慢慢缩水，收录自然跟着变慢。
响应时间为什么会进入收录链路
搜索引擎的抓取资源有限。同一时间能发起的请求数、对单个站点的抓取频次，都带有预算性质，而且会根据站点的历史表现动态调整。返回稳定、及时的站点，单位时间能完成更多抓取；经常超时或报错的站点，抓取会主动退避。这不是惩罚，而是资源分配的结果。
于是链条会这样传导：单次请求变慢，单位时间抓取量下降，新 URL 被发现得晚、已改页面重抓得慢，索引更新随之滞后。整站内容再多，如果服务器只能慢速交付，收录节奏也很难跟上。
慢一般慢在三个地方
TTFB 偏高
TTFB 指服务器返回第一个字节的时间，包含连接建立、服务器处理和后端查询。数据库慢查询、未缓存的动态页面、每次请求都要走的复杂权限或统计逻辑，都会把它推高。TTFB 一旦从几百毫秒涨到两三秒，抓取并发再高，实际吞吐也会被压住。
请求超时与中断
爬虫对单次请求有等待上限。超过这个上限，请求会被放弃并记录为超时。日志里看到的往往不是 5xx，而是抓取中断、连接重置，或者干脆没有记录。偶发超时影响有限，但如果集中在某些模板页或列表页，那些页面的重抓会明显变少。
渲染阶段的阻塞
如果页面依赖前端渲染，且首屏要等大量脚本、字体或第三方资源，抓取用的渲染资源会被长时间占用。这种情况下，HTML 返回可能很快，但完整渲染很慢，同样会拉低单位时间的抓取效率。
按这个顺序排查
- 先看日志，分清是抓取失败还是抓取变少。前者表现为 5xx、超时、连接中断，后者表现为请求总数下降但成功率正常。两者处理方向不同，先别急着动服务器配置。
- 看响应时间的分布，而不是平均值。平均值容易掩盖长尾。关注 95 分位、99 分位，以及超时请求集中在哪些 URL 或目录。
- 定位瓶颈在哪一层。对比静态文件和动态页面的 TTFB，如果只有动态页慢，问题多半在后端查询或缓存；如果整体都慢，先看带宽和服务器负载。
- 检查是否有大量低价值 URL 在消耗抓取。参数页、筛选页、站内搜索结果页如果被大量抓取，会挤占重要页面的名额，这时需要先收敛入口，而不是只优化速度。
- 最后再看渲染链路。用抓取工具模拟一次完整渲染，看资源加载里有没有明显的长耗时项。
可以做的处理与边界
- 加缓存与静态化。对高频访问的列表页、详情页做页面缓存，能最直接地压低 TTFB。注意缓存失效策略，避免更新长期不生效。
- 把静态资源交给 CDN。图片、脚本、样式走 CDN，能减轻源站压力，也让渲染更快完成。
- 减少首屏阻塞资源。非关键脚本延后加载，避免同步阻塞；第三方统计、客服组件按需引入。
- 合理设置服务端超时。超时时间过长会让慢请求堆积，过短又会误杀正常请求，需要结合自身接口耗时来定。
响应速度是收录的基础条件之一，不是万能钥匙。速度提上去之后，页面是否有独立价值、是否有足够入口，仍然是决定能否收录的关键。
最后提醒一点：优化响应时间的目标是让用户和爬虫都能顺畅拿到内容，而不是只为爬虫做一套特供版本。方向一致时，改动才稳。