抓取速率不是站点單方面能定的
不少站長以為在 robots.txt 里寫一句 Crawl-delay，或者在服務端设定好抓取速度，蜘蛛就會照着执行。實际情况是：抓取速率是搜尋引擎根據站点表現動態調整的结果，站点能做的更多是创造條件，而不是下命令。Crawl-delay 只有部分爬虫支持，主流搜尋引擎更看重自己测到的响應時間和错誤率。
這件事和 URL 發現直接相關：蜘蛛愿意開多少並發、多久跑一轮，决定了队列里那些已经被發現、但還没被抓取的 URL 要等多久。
响應時間决定了蜘蛛愿意開多大並發
調度逻辑並不复杂。如果每次請求都很快返回，蜘蛛會認為站点還有余力，于是提高並發、缩短回訪間隔；如果請求经常要等两三秒，它會主動降速，既不把站点压垮，也不浪費自己的资源。
所以優化抓取速率的第一件事不是催，而是让頁面變便宜：
- 静態资源和入口頁尽量走 CDN 或反向代理缓存；
- 列表頁、分類頁這類被抓取最频繁的模板，做好資料缓存；
- 避免頁面渲染时同步調用外部接口，尤其是容易超时的接口；
- 資料库慢查询單獨排查，列表頁的首字节時間通常卡在這里。
错誤率是速率的刹车
比慢更糟的是错。5xx 和连接超时會被记為失敗，失敗比例一高，抓取速率會被明顯压低，而且恢复需要一段時間。几個常见坑：
- 限流誤伤：站点自己的防護規則把蜘蛛当成異常流量拦掉，返回 429 或 403；
- 發布时短暂宕机：批量生成静態頁或重建缓存时，站点整体不可用；
- 個別頁面拖垮整体：某個頁面查询极慢，蜘蛛的並發請求都堵在這類 URL 上。
如果确實需要临时维護，返回 503 並带上 Retry-After，比直接返回 404 或 500 更合适。前者表示暂时不可用，後者容易被理解成頁面消失或站点故障。
用日誌估算站点能承受的量
與其猜，不如看日誌。把最近一段時間的蜘蛛請求按小时統計，重点看：
- 峰值时段每小时来了多少請求；
- 這些請求的平均响應時間與 P95 响應時間；
- 其中有多少是 5xx、429 和超时；
- 被抓取的 URL 里，有多少是你真正希望被發現的。
如果峰值时段响應時間明顯抬升，說明目前速率已经接近上限，再提高只會带来更多失敗；反過来，如果响應時間平稳、错誤率极低，說明還有余量。
让值得抓的 URL 優先被消耗
速率提升之後，真正被消耗的是抓取队列。队列里的 URL 越多、越杂，有效頁面分到的時間就越少。所以速率和 URL 质量要一起看：
- 參數頁、篩選组合、無内容的空结果頁尽量挡住，別让它們占队列；
- Sitemap 只放需要被抓的規范地址，不要把全部歷史 URL 都塞進去；
- 重要栏目放在浅层，靠稳定的内鏈让它們持續被回訪。
這几点做好之後，同样的抓取速率能覆盖更多有效頁面。
几個實际取舍
與其追求蜘蛛来得越多越好，不如追求每次来都能顺畅抓完该抓的頁面。
大促、上线、發布會這類流量高峰，不要同时做全站重建和大規模 URL 變更，容易把响應時間和错誤率一起推高。日常則可以持續观察首字节時間、5xx 比例和蜘蛛請求量三者的關系，提前發現容量問题。
最後提醒一点：抓取速率是结果，不是開關。站点响應快、错誤少、结构清晰，蜘蛛自然會来得更勤；反過来，任何單点優化都很难長期奏效。