抓取频次是“换”来的，不是“要”来的
很多站长把蜘蛛来访少归因于运气或者权重，但搜索蜘蛛的调度逻辑里有一项很实际的依据：你这个站点过去一段时间响应得快不快、稳不稳。同样是新页面，一个平均 200 毫秒返回、很少出错的站，被发现的节奏通常比经常超时的站更顺。这背后是搜索引擎对服务器承载能力的一种试探式调整——先小批量抓，观察表现，再决定要不要加速。
真正影响抓取节奏的几个指标
- 响应时间：首字节时间越长，单次抓取占用蜘蛛的资源越多，同一时间段能走完的 URL 数就越少。
- 5xx 与超时比例：偶发一次可以接受，持续出现会让抓取频次被主动调低。
- 连接层表现：DNS 解析慢、TLS 握手反复失败，都会在到达页面之前就消耗掉抓取窗口。
- 返回内容的一致性：把错误页用 200 返回，蜘蛛会把它当正常内容处理，既浪费抓取额度，也干扰状态判断。
几个常见但容易被忽略的做法
第一类问题是“整站共享一个低速入口”。比如所有页面都走同一个动态接口渲染，蜘蛛集中抓取时接口排队，后面所有请求一起变慢。第二类是资源被误伤：CDN 或防火墙把不常见的 UA、不携带 Cookie 的请求直接拦掉，返回 403，蜘蛛看到的就是“这个地址抓不到”。第三类是上线即全量重建：改版当天把几万个页面同时刷新缓存，回源压力暴涨，抓取与正常用户访问互相抢资源。
还有一类是“响应时间不稳定”：同一批地址有时 80 毫秒返回，有时两秒才响应。这种波动对抓取调度的影响，往往比整体慢一点更大，因为调度系统更难预测该给多少并发。
限速与错峰怎么落地
- 静态页面与动态页面分开部署，把蜘蛛最常走访的列表页、详情页放在响应更快的链路上。
- 确实需要降速时，用 429 或 503 加 Retry-After 明确告知，而不是返回超时或者一个空白页。
- 给爬虫流量单独设置缓存策略，避免每次抓取都穿透到数据库。
- 把内容发布、缓存刷新、数据同步这类重任务放到访问低谷时段执行。
- 如果站点规模大，先保证核心栏目稳定，再逐步放开边缘页面。
怎么判断改善有没有效果
可以同时看三个地方：服务器日志里蜘蛛请求的响应时间分布和状态码占比；后台抓取统计里抓取请求总量与平均响应时间的变化；以及“已发现未抓取”地址数量的走势。建议按周对比同一时段的数字，而不是只看单日。比较合理的预期是：响应时间下降之后，抓取频次和发现速度会有滞后性的改善，而不是当天见效。别因为一两天没变化就反复调整策略。
抓取频次更像是一种授信额度：站点每次稳定、快速地完成请求，额度才会慢慢往上走；一次集中性的故障，可能要把积累退回去一部分。
稳定性是 URL 发现的隐性变量
讨论 URL 发现时，大家习惯盯着 Sitemap、内链和提交入口，这些决定了“地址能不能被看到”；而服务器表现决定的是“看到之后，蜘蛛愿不愿意继续、能不能走得完”。一个响应忽快忽慢的站，即使内链结构做得再清晰，新页面从被发现到被实际抓取之间的等待也会被拉长。把服务器稳定性当成 URL 发现链条上的一环来管理，比单独优化某一个提交渠道更实在。