蜘蛛池解决的是“让蜘蛛发现 URL”这一步，真正能不能变成一次有效抓取，很大程度取决于目标页这一侧接不接得住。入口页做得再顺，如果目标页响应慢、状态码乱、链接不稳定，蜘蛛来过一次之后往往就不再给机会。这篇聊的是承接侧的问题怎么排查。
一、先把两段链路分开看
整条链路可以拆成两段：入口页负责“被发现”，目标页负责“被读到”。不少人的监控只盯着入口页的访问日志，看到蜘蛛来了就认为任务完成，忽略了蜘蛛顺着链接进入目标页之后到底拿到了什么。
这两段的健康指标也不一样。入口段看的是抓取频次、状态码分布、响应耗时；目标段看的是抓取深度、目标页的响应耗时、有没有大量重定向和错误页。混在一起看，很容易把承接侧的问题误判成入口侧的问题。
二、承接不住时的几种常见表现
- 抓取深度上不去。入口页天天有蜘蛛，但目标页的访问记录寥寥无几，或者只停留在第一层，说明蜘蛛拿到的链接或者进入目标页后的体验出了问题。
- 目标页响应时间明显高于入口页。入口页是静态小文件，目标页要查库、要渲染、要调接口，耗时差出好几倍，蜘蛛的并发预算很快就被耗完。
- 状态码分布异常。目标页出现大量 5xx、长时间 302 到首页、或者软 404（返回 200 但内容是空页），都会让蜘蛛降低对这批 URL 的信任。
- 跳转链路过长。入口页跳到中间页，中间页再跳到目标页，中间任何一环慢或断，蜘蛛都可能在半路停下。
- URL 不稳定。同一篇内容每次生成的参数、大小写、末尾斜杠都不一样，蜘蛛反复抓到的其实是“新 URL”，重复消耗预算。
三、排查顺序：从日志对照开始
不要一上来就改配置，先把两段日志放在一起对照。
- 取一段固定时间窗（比如 24 小时）的入口页日志和目标页日志，按蜘蛛 UA 和 IP 段过滤，确认两边记录的是同一批爬虫。
- 统计目标页的响应耗时分布，看 P90、P99 落在什么区间。均值好看不代表没问题，尾部拖长才是蜘蛛放弃的直接原因。
- 统计目标页的状态码分布，把 5xx、3xx 和内容为空的 200 单独拎出来看比例。
- 抽查几条真实抓取记录，看蜘蛛从入口页到目标页之间经过了几跳，每一跳的耗时分别是多少。
- 对比同一批 URL 在不同时段的抓取结果，区分是持续性问题还是某个时间点的资源争抢。
四、可以顺手做的几项调整
- 给入口页和目标页分开限速。入口页放得快一点没关系，目标页并发要压住，避免蜘蛛把资源全占满，也避免自己服务器被打出 5xx。
- 缩短跳转链路。能一跳到的不要两跳，能不经过 JS 跳转的就用服务端跳转，减少蜘蛛在中途放弃的概率。
- 统一 URL 形态。大小写、末尾斜杠、跟踪参数在入口页生成链接时就定死，不要留给蜘蛛去试。
- 把最想被读到的页面放在第一层。蜘蛛的抓取预算是有限的，重要的目标页不要藏在第三、第四层。
- 给目标页做缓存。蜘蛛访问的多是不带登录态的匿名请求，这类请求最适合走缓存，响应时间往往能降一个量级。
- 错峰开放。如果目标站白天有真实用户高峰，可以观察一段时间后，把入口页的链接产出节奏往低谷时段挪一挪。
五、哪些情况其实与承接无关
排查时也要留个心眼：有些现象看着像承接问题，根因却在别处。
- 目标页本身没有可索引的内容，或者内容与入口页描述完全无关，蜘蛛不深入属于正常判断。
- 目标页被 robots 规则、meta 标签或登录墙挡住，这不是性能问题，是策略问题。
- 目标站整站权重和抓取配额本身很低，蜘蛛给到这一批 URL 的额度本来就少，改承接侧帮助有限。
把蜘蛛引来只是第一步，能不能被顺利读完，取决于目标页那一刻的状态。与其反复调整入口页，不如定期对照两段日志，确认蜘蛛每次进来都能拿到稳定、快速、不绕路的响应。
最后提醒一句：抓取顺利不等于会被收录，更不等于有排名。承接侧优化能改善的是“蜘蛛愿不愿意来、来多少次、读到多深”，剩下的事情仍然取决于内容本身和站点的整体质量。