蜘蛛抓取的本质是一次资源交換：它花時間請求你的頁面，你花带宽和 CPU 返回内容。当响應變慢时，蜘蛛並不是简單地“等一等”，而是會調整對整站的抓取安排。很多站点抱怨抓取量下降，最後查下来問题不在 robots、不在内鏈，而在服務器响應時間。
响應時間是抓取的第一道门槛
蜘蛛請求一個 URL 时，最先等待的是第一個字节返回的時間，也就是 TTFB。這個時間長期偏高，會连带出現几種情况：
- 單次請求占用连接的時間變長，單位時間内能抓的 URL 變少；
- 超過蜘蛛自身的超时阈值後，請求被放弃，頁面被记為抓取失敗；
- 失敗率升高後，蜘蛛會主動降低對该目錄甚至整站的抓取频率。
換句话说，慢不會立刻表現為“不抓”，而是表現為“抓得少、抓得浅、間隔變長”。這些變化在服務器日誌里往往先出現在响應時間那一列，而不是狀態碼那一列。
蜘蛛會做哪些調整
從日誌和抓取报告里，可以观察到几種常见反應：
- 抓取频次下降：同一批 URL 的回訪間隔從几天拉長到一两周；
- 抓取深度變浅：蜘蛛更愿意停留在列表頁和热门頁，不再往下翻；
- 新 URL 發現變慢：Sitemap 里的新連結要更久才會被訪問；
- 重试增多：同一 URL 在短時間内出現多次請求，多數是超时後的重试。
這些現象叠加起来，效果和“抓取预算被压缩”很像。区別在于，预算問题是分配策略，响應時間問题是硬约束。
哪些“慢”其實不归蜘蛛管
不是所有拖慢頁面的因素都會影响抓取，需要区分開：
- 服務器端慢：資料库查询、模板渲染、同步調用第三方接口，這些直接影响 TTFB，蜘蛛能感知；
- 浏览器端慢：图片体积、前端脚本执行、字体加载，影响的是用戶，對只取 HTML 的抓取影响有限，但渲染阶段的资源消耗仍值得留意；
- 網絡鏈路慢：跨境线路、CDN 回源異常，可能让部分位置的蜘蛛拿到的是超时结果或舊版本。
排查时先把這三類分開，避免在無關的地方反复改動。
用日誌判断响應時間是不是瓶颈
只看平均值容易誤判。更實用的做法是：
- 按蜘蛛 UA 過滤出抓取請求；
- 看响應時間的分布，重点看 P95 和最大值；
- 統計超时和 5xx 的占比，而不是只看 200 的數量；
- 對比抓取量下降的時間点與响應時間上升的時間点是否吻合。
如果 P95 長期處于偏高水平，且超时零星出現，基本可以判断响應時間已经在影响抓取节奏。
優化顺序
優先級大致可以這样排：
- 先解决超时和 5xx：這類請求對蜘蛛最不友好，也會让重试挤占正常抓取；
- 加缓存：對不常變的列表頁、詳情頁做頁面級或對象級缓存，收益通常最直接；
- 减少同步外部調用：评论、統計、推荐接口能异步就异步，別让它們挡在 HTML 前面；
- 保護性限流：给蜘蛛留出足够配額，避免高峰时被正常用戶流量挤到超时；
- 稳定發布节奏：维護窗口、批量改版尽量避開抓取高峰，减少集中失敗。
和 URL 發現配合起来看
Sitemap、内鏈和站内搜尋负责“告诉蜘蛛有哪些 URL”，服務器稳定性负责“让蜘蛛拿得到”。前者做得再细，如果响應時間不稳，URL 發現依然會滞後。比較稳妥的做法是：新内容發布後先確認關键路径上的頁面响應正常，再通過内鏈和 Sitemap 引導抓取，而不是一次性推入大量 URL。
抓取量下滑时，先看响應時間的分布和超时比例，再谈内鏈與 Sitemap，往往能少走弯路。