做站点运营时，大多数人盯的是标题、正文、内链和图片，这些确实重要。但蜘蛛第一次接触一个地址时，最先读到的并不是 HTML 源码，而是服务器返回的那几行响应头。头部信息写错，后面的内容再规整，也可能被读成乱码、空白页，或者被误当成另一类资源。
响应头平时不显眼，出问题时却很难从页面表面看出来：浏览器可能照样正常显示，只有换一个客户端、换一种请求方式，问题才暴露出来。所以它更适合放进固定的巡检清单，而不是等出了异常再回头找。
蜘蛛看到的第一层信息
一次请求的流程大致是：解析域名、建立连接、服务器返回状态码和响应头、再返回正文。蜘蛛判断这个地址是什么类型的内容、用什么编码解析、要不要继续抓，很大一部分依据就来自响应头，而不是正文里的 meta 标签。
当两者说法不一致时，服务器返回的头部通常优先级更高。这也是为什么有些页面在源码里明明写了字符集声明，抓取端读出来依然是乱码——头部先给出了另一个答案。
几类容易写错的响应头
Content-Type 与字符集
常见的写法是 Content-Type: text/html; charset=utf-8。问题往往出在两个地方：一是类型写错，把 HTML 页面标成 text/plain、application/json，甚至 application/octet-stream，蜘蛛可能直接按普通文本或下载资源处理；二是只写了 text/html，漏掉字符集，解析端只能靠猜，遇到中文就容易出现乱码。
还有一种情况是模板或框架默认输出 ISO-8859-1，而页面实际是 UTF-8，正文里的中文会整段变成问号或方块。这类问题在浏览器里可能被自动纠正，抓取端却未必有这么宽容。
Content-Encoding 与压缩声明
开启 gzip 或 brotli 压缩本身是好事，能减少传输体积。但如果声明与实际不符，比如头部说 gzip 而返回的是未压缩内容，或者压缩层级嵌套错误，接收方解出来就是一段乱码。改过 Nginx、CDN 压缩配置之后，最好顺手验证一下头部和内容是否对得上。
X-Robots-Tag
这个头部可以针对单个地址、整个目录甚至某类文件设置抓取和索引规则，作用范围比页面里的 meta 标签更广，而且不依赖 HTML 能否被解析。它的问题在于太隐蔽：一个批量下发的 noindex，可能让整批 PDF、图片或接口页悄悄退出。
排查时要留意的是，它可能来自服务器配置，也可能来自 CDN 或安全防护层的默认策略，几处叠加之后效果会被放大。
Vary 与缓存相关字段
如果站点对移动端和桌面端返回不同内容，Vary 字段会影响缓存按哪个维度区分版本。配置不当，可能出现同一个地址在不同边缘节点返回不同页面、甚至返回对方版本的情况。这类问题不一定会立刻显现，但会让抓取结果变得不稳定。
一套简单的自查步骤
- 挑几个有代表性的地址：首页、栏目页、详情页、列表页、图片或附件页各取一两个。
- 用命令行工具只取头部，例如 curl -I 加上地址，观察状态码和这几行关键字段。
- 带上不同 User-Agent 再请求一次，对比返回的头部和正文是否一致，重点看是否被差异化处理。
- 在浏览器开发者工具的网络面板里对照头部与页面实际渲染结果，确认字符集和内容类型对得上。
- 对图片、PDF、接口返回等非 HTML 资源单独抽查，它们最容易被类型声明误伤。
- 把发现的异常记录成清单，标明是服务器配置、框架默认值还是 CDN 策略造成的，避免改完又反弹。
容易被忽略的几个细节
- 状态码是 200，但正文长度为 0 或极短，头部看起来一切正常，实际是空壳页面。
- 测试环境和线上环境用了同一套模板，头部规则跟着一起上线。
- 更换 CDN 或调整安全策略后，头部字段被中间层改写，源站配置其实没变。
- 只检查了 HTML，忽略了站点地图、RSS、接口文件这些同样需要正确类型的地址。
- 批量规则写得太宽，例如对整站目录统一加限制，误伤了正常内容。
响应头这类问题，特点是不痛不痒地待着：页面能打开，用户看不出差别，只有抓取和解析环节会受影响。所以它更适合定期抽查，而不是等数据明显下滑再回头排查。
小结
把响应头纳入常规巡检，成本并不高：几条命令、几次对比，就能排除掉一批隐蔽问题。重点看 Content-Type 和字符集是否与页面实际编码一致、压缩声明是否属实、X-Robots-Tag 有没有被批量误设、缓存相关字段是否让同一个地址给出多套结果。发现问题后回到配置源头修改，比在页面上打补丁更稳妥。