服务器返回的 HTTP 头里，Content-Type 决定了蜘蛛把这串字节当成什么来处理。如果声明与实际内容对不上，页面可能被当成二进制文件、纯文本或乱码，抓取路径就在这里断掉。这类问题在浏览器里往往看不出来，因为浏览器会做内容嗅探，而抓取程序通常更依赖头部的明确声明。
三类常见的声明错配
- 类型缺失或写成通用值：头部只给 text/plain，或者干脆没有 Content-Type，程序可能按纯文本处理，标签被当成普通文字，页面里的链接自然也不会被提取成入口。
- 字符集与正文编码不一致：头部写 charset=gbk，页面 meta 里写 utf-8，或者反过来。解析器按头部解码，中文锚文本变成乱码，链接拼接和标题提取都会出现异常。
- 压缩与声明不匹配：Content-Encoding 与实际压缩方式不符，或者 CDN 与源站重复压缩，响应体在解压阶段就报错，抓取记录里表现为响应截断或内容为空。
先从响应头和抓取记录确认现象
在改配置之前，先确认是不是这一类问题，比直接动手更省时间。可以看几个点：
- 同一批 URL 中，只有某个目录或某类扩展名的页面出现异常，通常是该路径单独配置了 MIME 映射。
- 用带 Accept-Encoding 的请求和不带的请求各取一次，对比响应体长度是否一致。
- 检查头部 charset 与 HTML 内部的编码声明是否指向同一个值，同时注意文件是否带有 BOM。
- 观察抓取记录中状态码为 200 但内容长度接近 0，或长度明显小于同类页面的情况。
排查顺序
- 先固定一个受影响的 URL，用命令行工具查看完整响应头，记录 Content-Type、Content-Encoding、Content-Length 三项。
- 对比页面源码里的 meta charset 与头部 charset，不一致时以头部为准，去查服务端的编码配置。
- 检查 Web 服务器或框架的 MIME 映射表，看是否把 .html、无扩展名路径或动态路由错误地归到了 application/octet-stream 这类类型上。
- 检查 CDN、反向代理和源站是否都在追加 Content-Type，重复头部会让解析器取值出现歧义。
- 修正后重新请求，确认解码后的响应体能还原出正常的 HTML 结构，再看抓取记录里的内容长度是否恢复。
修复时容易踩的坑
让类型与编码对齐，多数时候只是配置层面的调整，但有几个地方容易反复：
- 不要只依赖页面内的 meta charset 兜底，头部声明是更靠前的判断依据，两者应保持一致。
- 修改编码声明前先确认数据库与模板文件的真实编码，贸然改声明会把原本正常的内容变成乱码。
- 静态资源与 HTML 分开配置，避免把 CSS、JS 的 MIME 规则套到页面上。
- 变更前后各保留一份响应头记录，便于和抓取记录做对照，也方便回滚时定位。
抓取异常并不等于收录结果，域名权重、内容质量和整体抓取预算同样会影响最终表现。这里排查的只是蜘蛛能不能正确读到页面这一段。
小结
Content-Type 与字符集声明看起来是小事，却决定了蜘蛛拿到的是不是一个可解析的 HTML 文档。把响应头的类型、编码、压缩三项对齐，再确认解码后的正文结构正常，入口断点基本就能补上。可以把这几项放进站点上线检查清单，改版或更换服务器之后重点复核一次。