蜘蛛来抓一个页面的时候，第一步并不是判断内容好不好，而是先要拿到响应。如果服务器迟迟不给答复，或者干脆返回 5xx，这一次抓取就落空了。偶尔一次问题不大，但如果某些模板长期慢、长期报错，蜘蛛会自然地把有限的抓取时间挪到更顺畅的地方去——这不是什么惩罚机制，只是效率选择。
先确认问题出在哪一层
不要一上来就改代码。先拿到两组数据：状态码分布和响应时间分布。前者说明有多少请求是失败的，后者说明有多少请求是慢的，两个问题经常混在一起，但处理方式完全不同。
- 状态码：按 2xx、3xx、4xx、5xx 分组，看 5xx 集中在哪些路径
- 响应时间：按模板归类，找出长期偏慢的那几类页面
- 时间分布：看变慢是全天如此，还是集中在某些时段
如果只盯着平均值，很容易被少数极端值带偏，所以更要看的是慢请求占比，而不是单次最慢有多慢。
响应时间一般从哪来
网络与前置层
DNS 解析、CDN 回源、负载均衡转发，这些环节出问题通常表现为整体偏慢，而不是某几个页面慢。如果你发现几乎所有地址的响应时间一起上升，先看这一层，而不是急着查数据库。
应用与数据库
只有部分模板慢，多半在应用层：慢查询、循环里反复调接口、每次请求都重新生成同样的内容。列表页、搜索结果页、多条件筛选页是常见的重灾区，这类页面往往参数多、组合多，最容易把响应时间拖长。
外部依赖
第三方接口超时会把整页卡住。给外部调用设置独立的超时时间和降级方案，避免一个并不重要的模块拖垮整个页面的响应。
5xx 与超时的处理原则
- 能修的尽快修，不要把 5xx 当作临时挡板。频繁报错会让蜘蛛认为这个站点不稳定，降低回来的意愿。
- 确实需要临时下线时，用 503 并配合 Retry-After，明确告知什么时候可以再来，比返回 404 或者一个 200 的空页面都更清楚。
- 避免半截页面。返回的 HTML 要完整可解析，不要出现主内容缺失、只剩框架的情况。
缓存值得先做，但不是万能
静态化、页面缓存、对象缓存能挡掉大部分重复计算，是最省力的改善手段。不过要注意缓存穿透：缓存刚好失效的瞬间，大量请求同时打到源站，反而更容易超时。可以用过期时间错开、同一时间只允许一个请求回源等办法缓解。
日常怎么盯着
- 把关键入口页加入监控，包括首页、主要栏目页和核心详情模板，按小时看响应时间
- 在抓取日志里统计超时与 5xx 的数量，按周对比变化趋势
- 巡检时手动打开几个页面，感受真实加载速度，不要只看监控曲线
提醒一句：不要因为蜘蛛抓得勤就想给它限速。限流规则误伤正常蜘蛛，造成的损失往往比响应偏慢更大。
处理的顺序
先把最慢的一两个模板修好，观察一段时间；再处理偶发的超时；最后再谈整体优化。不要同时改一堆东西，否则出了问题很难分清是哪一步起了作用。响应这件事没有一次性解决的方案，它更像是一项要长期保持的日常维护工作。