抓取从建立连接开始
谈到搜索抓取，多数人先看内链、Sitemap 和 robots.txt。这些决定了蜘蛛能不能发现 URL，但发现之后，蜘蛛还得真的把页面拿回去。在拿到 HTML 之前，它要经过域名解析、建立 TCP 连接、完成 TLS 握手、发送请求、等待服务器返回响应头，然后才下载正文。这一段如果慢或者不稳定，前面的链接结构做得再细，也会被打折。
抓取不是无限等待。蜘蛛有自己的时间和资源安排，一个地址迟迟不返回，或者连接中途断开，它会放弃这次请求，把资源花到别处。日志里可能只留下一条访问记录，甚至什么都没有。
首字节时间决定蜘蛛要等多久
TTFB（首字节时间）指的是从发出请求到收到第一个字节的间隔。它包含服务器处理请求、查询数据、拼接页面、经过缓存层返回的时间。
- 缓存未命中时回源慢，命中时很快，蜘蛛看到的快慢会随机波动。
- 数据库慢查询、外部接口同步调用，会把 TTFB 拉长到几秒甚至十几秒。
- CDN 边缘节点到源站链路差，用户感觉不明显，蜘蛛跨地区访问时更明显。
单个页面慢几秒看起来不严重，但蜘蛛一次抓取会发出很多请求。每个请求都多等几秒，单位时间内能抓的页面数量就下降。对于 URL 量大、更新频繁的站点，这种下降会直接表现为新页面被发现得更晚。
连接超时与连接重置更隐蔽
5xx 和 429 在日志里有明确状态码，连接层的问题往往没有。
- 连接超时：服务器不响应，蜘蛛等不到结果，访问日志里可能没有完整记录。
- 连接重置：握手完成后被中途断开，蜘蛛拿到不完整的响应。
- 响应截断：正文传到一半停止，蜘蛛可能只解析到部分 HTML。
这些情况常和防火墙、限流策略、负载均衡配置、后端进程数不足有关。它们不一定会体现在状态码监控里，但会稳定地消耗抓取机会。排查时可以在不同网络位置用命令行工具反复请求，观察连接阶段是否偶发失败。
如果同一批 URL 在日志里时有时无，先别急着改内链，先确认连接是不是稳定的。
响应头、压缩与内容完整性
蜘蛛拿到的内容取决于服务器怎么返回。Content-Encoding 声明了 gzip 或 brotli 压缩，Content-Length 表示长度，分块传输则没有固定长度。如果这些头和实际内容不一致，蜘蛛可能读到被截断的 HTML。
还有一种情况是页面过大。正文、内联脚本和样式全部塞进一个 HTML，压缩后仍然很大，蜘蛛下载时间变长，解析也变慢。把首屏需要的结构留在 HTML 里，把不必要的部分延后加载或拆出去，对抓取更友好。
CDN 与边缘缓存带来的差异
蜘蛛会从多个 IP 和地区访问站点。如果 CDN 缓存策略不一致，不同节点可能返回不同版本的页面：有的返回旧 HTML，有的返回错误页，有的直接回源。用户刷新几次可能看不出来，但蜘蛛拿到的样本会互相冲突。
需要留意的是：
- 缓存键是否包含了会影响内容的参数，避免把 A 页面缓存给 B URL。
- 回源失败时边缘节点返回的内容是不是 5xx 或伪装的 200。
- 发布后缓存刷新是否覆盖到蜘蛛常访问的节点。
日常可以检查的几项
- 用命令行工具测量 TTFB，看是稳定慢还是偶发慢。
- 对比不同地区或不同节点的返回头和正文是否一致。
- 检查服务器与 CDN 日志里是否有大量超时、重置、截断记录。
- 确认压缩配置和 Content-Length 正确，避免响应不完整。
- 大页面考虑拆分，减少单次下载体积。
连接层做得好，不会直接带来收录或排名，但它决定了蜘蛛愿不愿意、能不能顺利把页面拿回去。内链和 Sitemap 负责指路，连接层负责把路走通，两者缺一段，抓取都会受影响。