服務器返回的 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 文档。把响應头的類型、编碼、压缩三項對齐，再確認解碼後的正文结构正常，入口断点基本就能补上。可以把這几項放進站点上线检查清單，改版或更換服務器之後重点复核一次。