聊抓取的时候，大部分讨论都围绕链接：内链够不够、Sitemap 全不全、路径深不深。但蜘蛛真正把页面抓回去的前提，是服务器能把响应给出来。链接决定蜘蛛想去哪，服务器状态决定它能不能到。很多站点 URL 发现慢、抓取量上不去，问题不在链接结构，而在响应质量。
一次抓取要过哪几道服务器关卡
从蜘蛛发出请求到拿到 HTML，中间要经过 DNS 解析、TCP 连接、TLS 握手、服务器处理、首字节返回（TTFB）和内容传输。任何一环慢了或者断了，这次抓取就算失败，或者被判为低质量。
- DNS 与连接：解析慢、连接被拒，蜘蛛连门都进不去。
- TTFB：服务器处理时间过长，蜘蛛的等待成本变高。
- 传输：HTML 体积过大、中途中断，页面拿不全。
- 并发：服务器拒绝过多连接，蜘蛛只能降低请求频率。
不同响应对抓取路径的实际影响
5xx：最需要警惕的一类
500、502、503、504 表示服务器端没能正常完成请求。蜘蛛遇到 5xx 通常会重试，但如果某个目录下大量 URL 连续返回 5xx，蜘蛛会降低对整站的抓取频率，已经排在队列里的 URL 也可能被推后。更麻烦的是 URL 发现：新地址即使被内链指向或在 Sitemap 里提交，只要反复返回 5xx，它就会一直停留在待抓取状态。
429 与 503 加 Retry-After：别把它当成通用限流开关
有些站长为了控制抓取压力，对蜘蛛统一返回 429。短期看请求量确实下来了，但长期如此，蜘蛛会认为站点持续不可用，抓取节奏被压得很低。限流更合适的做法是控制单 IP 并发、给动态内容做缓存、把慢查询优化掉，而不是对所有请求一刀切。
超时与连接重置
服务器处理时间长于蜘蛛的等待上限，请求会被判超时。表现上和 5xx 类似：这次抓取没有结果，蜘蛛也不知道这个 URL 到底存不存在，于是不敢把它标记为已发现，容易反复回来试探。连接被中途重置则更糟，蜘蛛可能拿到残缺 HTML，如果初始 HTML 里缺了链接，那部分 URL 就发现不了。
200 但内容不完整
还有一种隐性情况：状态码正常，但内容是空壳，关键链接靠 JS 渲染，或者服务器按 UA、按地域返回了不同版本。对蜘蛛来说这次抓取是成功的，但抓到的链接集和你预期不一致，URL 发现自然会出现遗漏。
抓取路径被打断后的连锁反应
单次失败看起来不起眼，但影响会沿着路径扩散：
- 入口页响应慢，蜘蛛在入口就消耗掉大部分耐心，深层页排不上队。
- 中间层页面返回 5xx，蜘蛛走不到它下面的链接，更深层 URL 的发现被推迟甚至中断。
- 服务器整体不稳定时，蜘蛛整体降速，Sitemap 里提交的 URL 也不会被优先处理。
- 反复失败会让一些 URL 长期停留在已发现未抓取状态，站内看起来提交了，实际没被处理。
怎么定位：抓取日志和服务端指标对着看
单独看抓取日志很难判断是链接问题还是服务器问题，需要和服务端指标交叉比对。
- 日志里的响应码分布：如果 5xx 占比高，先修服务端，再谈内链。
- 响应时间分位：平均 TTFB 看着还行，但 P95、P99 很高，说明偶发慢请求正在拖累抓取。
- 蜘蛛 UA 的请求是否被限流、被 WAF 拦截、被 CDN 回源失败。
- 同一 URL 在日志中反复出现且都是失败状态，说明蜘蛛在重试，但一直没成功。
- 观察抓取高峰时段的 CPU、数据库连接数和慢查询数量。
可以落地的调整
- 优先保证入口页、栏目页的响应时间稳定，这些页面决定蜘蛛能不能继续往下走。
- 给耗时接口做缓存，减少动态渲染带来的 TTFB 波动。
- 对静态资源做长缓存和 CDN 分发，减少回源压力。
- 如果必须限流，用低频率的均匀限速，避免整段集中返回 429。
- 页面体积控制在合理范围，避免蜘蛛下载到一半中断。
- 保持服务器时间准确，日志时间对不上会让人误判抓取节奏。
抓取路径由链接和服务器一起构成。链接再漂亮，服务器响应不给力，蜘蛛也走不到终点。排查抓取问题时，先确认服务端稳定，再看链接结构，顺序反了会浪费很多时间。
对 URL 发现来说，最实际的结论是：新地址被提交之后能不能被真正抓取，取决于服务器在那个时刻有没有把页面正常交出去。稳定性不是优化项，它是抓取的前提。