蜘蛛来抓頁面，本质上是一次次 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 占比”寫進日常巡检表，而不是等出問题才查。
需要說明的是，响應變快不保證收錄變多。它只是拿掉了蜘蛛路上的一块石头，剩下的仍取决于内容质量、頁面结构與站内連結。但反過来说，這块石头没搬，後面的努力往往事倍功半。