蜘蛛抓取一个 URL 时，最先拿到的不是正文，而是状态行和 HTTP 响应头。很多入口页的问题，比如“蜘蛛来了但不抓”“抓了一次就不再来”，并不在页面内容里，而在响应头传递的信息上。这篇文章不讨论怎么讨好蜘蛛，只梳理入口页响应头里值得检查的字段，以及调整时需要注意的地方。
为什么响应头值得单独检查
蜘蛛的抓取流程通常分几步：解析 DNS、建立连接、发送请求、读取响应头、再决定是否继续读取正文。如果响应头里出现让它困惑的信号，比如内容类型不对、长度不一致、缓存指令互相矛盾，它可能提前结束这次抓取。入口页本身内容少，响应头的影响就更明显。
另一个原因是响应头容易被忽略。页面模板、服务器配置、CDN 回源规则、反向代理，任何一层都可能改掉或追加响应头。上线前只看了浏览器里页面能打开，不代表蜘蛛看到的头部是一样的。
几个关键字段怎么核对
Content-Type 与字符集
入口页应该返回 text/html，并带上明确的字符集，比如 text/html; charset=utf-8。如果返回 text/plain、application/octet-stream，或者没有字符集，蜘蛛可能把页面当成非 HTML 资源，或者按错误的编码解析。中文入口页尤其容易出现编码不一致，页面 meta 写 utf-8，响应头却是 gbk，抓取端会看到乱码。
Content-Length 与传输编码
如果服务器声明了 Content-Length，但实际返回的字节数对不上，或者同时出现 Content-Length 和 Transfer-Encoding: chunked，抓取端可能判定响应异常。动态生成入口页、gzip 压缩、代理改写都可能引发这类问题。检查方法很简单：用 curl -I 看头部，再用 curl -s | wc -c 看实际长度，对比是否一致。不一致不一定会立刻出问题，但属于隐患。
缓存相关字段
Cache-Control、Expires、Last-Modified、ETag 这几个字段会影响蜘蛛回访时的行为。入口页如果设置 no-store，每次都要重新完整下载，抓取成本会上升；如果设置过长的 max-age，蜘蛛可能长时间拿不到更新。比较稳妥的做法是给入口页一个适中的缓存时间，保留 Last-Modified 或 ETag，让蜘蛛可以用条件请求拿到 304，减少重复传输。
缓存不是越短越好，也不是越长越好。入口页更新频率低时，可以放宽缓存；频繁调整模板时，再临时收紧，并观察日志里的抓取频次变化。
X-Robots-Tag
这个响应头容易被忘记。它和页面里的 meta robots 作用类似，但优先级和写法不同。如果服务器或 CDN 统一加了一条 X-Robots-Tag: noindex，页面里写再多允许索引的标签也没用。检查入口页时，确认没有意外的 noindex、nofollow 或 noarchive 头。
Vary、压缩与变体
如果入口页会根据 Accept-Encoding 或 User-Agent 返回不同内容，Vary 头需要正确设置。设置不当可能导致缓存把 A 变体返回给 B 请求，蜘蛛拿到压缩错乱或内容缺失的版本。常见做法是只对 Accept-Encoding 做压缩变体，不要根据 UA 返回完全不同的 HTML。
重定向与 Location
入口页如果做了跳转，响应头里的 Location 要指向可抓取的绝对 URL，并且状态码用 301 或 302 保持一致，不要混用。跳转链太长、Location 指向相对路径、或者跳到需要登录的页面，都会让蜘蛛在入口处停下。跳转本身不是问题，问题是不稳定的跳转。
检查与调整的日常做法
- 用 curl -I 批量抽查入口页，重点看状态码、Content-Type、Location、X-Robots-Tag。
- 对比响应头里的 Content-Length 和实际字节数，尤其是经过 CDN 和反向代理的站点。
- 在服务器日志里观察同一入口页的返回状态和响应大小，判断头部是否稳定。
- 改动缓存、压缩、防护规则后，至少观察一个抓取周期，再决定是否继续调整。
- 把入口页和目标站的响应头策略分开管理，避免互相影响。
使用建议与常见误区
一个常见误区是把响应头当成优化排名的手段，频繁修改各种字段。响应头的首要作用是准确传递资源信息，不是制造信号。另一个误区是只看首页或少量样本，忽略批量生成的入口页。模板一变，所有入口页的头部都会变，抽查要覆盖不同模板和不同服务器节点。
如果发现蜘蛛抓取减少，先看状态码和响应头，再看内容。把响应头当作排查清单里靠前的一项，比盲目改页面更有效率。调整时保持小步、可回滚，记录变更前后的日志差异，才能判断某个字段到底有没有影响。