排查收錄問题时，内容质量、内鏈结构和 sitemap 往往是第一反應。但還有一個更靠前、也更容易被忽略的因素：服務器把頁面交出去的速度。抓取和收錄是两個环节，抓取在前。如果每次請求都要等上几秒，甚至間歇性超时，爬虫愿意花在這個站点上的抓取量會慢慢缩水，收錄自然跟着變慢。
响應時間為什么會進入收錄鏈路
搜尋引擎的抓取资源有限。同一時間能發起的請求數、對單個站点的抓取频次，都带有预算性质，而且會根據站点的歷史表現動態調整。返回稳定、及时的站点，單位時間能完成更多抓取；经常超时或报错的站点，抓取會主動退避。這不是惩罚，而是资源分配的结果。
于是鏈條會這样传導：單次請求變慢，單位時間抓取量下降，新 URL 被發現得晚、已改頁面重抓得慢，索引更新随之滞後。整站内容再多，如果服務器只能慢速交付，收錄节奏也很难跟上。
慢一般慢在三個地方
TTFB 偏高
TTFB 指服務器返回第一個字节的時間，包含连接建立、服務器處理和後端查询。資料库慢查询、未缓存的動態頁面、每次請求都要走的复杂權限或統計逻辑，都會把它推高。TTFB 一旦從几百毫秒涨到两三秒，抓取並發再高，實际吞吐也會被压住。
請求超时與中断
爬虫對單次請求有等待上限。超過這個上限，請求會被放弃並记錄為超时。日誌里看到的往往不是 5xx，而是抓取中断、连接重置，或者干脆没有记錄。偶發超时影响有限，但如果集中在某些模板頁或列表頁，那些頁面的重抓會明顯變少。
渲染阶段的阻塞
如果頁面依赖前端渲染，且首屏要等大量脚本、字体或第三方资源，抓取用的渲染资源會被長時間占用。這種情况下，HTML 返回可能很快，但完整渲染很慢，同样會拉低單位時間的抓取效率。
按這個顺序排查
- 先看日誌，分清是抓取失敗還是抓取變少。前者表現為 5xx、超时、连接中断，後者表現為請求總數下降但成功率正常。两者處理方向不同，先別急着動服務器配置。
- 看响應時間的分布，而不是平均值。平均值容易掩盖長尾。關注 95 分位、99 分位，以及超时請求集中在哪些 URL 或目錄。
- 定位瓶颈在哪一层。對比静態文件和動態頁面的 TTFB，如果只有動態頁慢，問题多半在後端查询或缓存；如果整体都慢，先看带宽和服務器负载。
- 检查是否有大量低價值 URL 在消耗抓取。參數頁、篩選頁、站内搜尋结果頁如果被大量抓取，會挤占重要頁面的名額，這时需要先收敛入口，而不是只優化速度。
- 最後再看渲染鏈路。用抓取工具模拟一次完整渲染，看资源加载里有没有明顯的長耗时項。
可以做的處理與邊界
- 加缓存與静態化。對高频訪問的列表頁、詳情頁做頁面缓存，能最直接地压低 TTFB。注意缓存失效策略，避免更新長期不生效。
- 把静態资源交给 CDN。图片、脚本、样式走 CDN，能减轻源站压力，也让渲染更快完成。
- 减少首屏阻塞资源。非關键脚本延後加载，避免同步阻塞；第三方統計、客服组件按需引入。
- 合理設定服務端超时。超时時間過長會让慢請求堆积，過短又會誤杀正常請求，需要结合自身接口耗时来定。
响應速度是收錄的基础條件之一，不是萬能钥匙。速度提上去之後，頁面是否有獨立價值、是否有足够入口，仍然是决定能否收錄的關键。
最後提醒一点：優化响應時間的目标是让用戶和爬虫都能顺畅拿到内容，而不是只為爬虫做一套特供版本。方向一致时，改動才稳。