做蜘蛛池入口页时，大家通常盯着状态码、robots、nofollow 这些比较显眼的因素，反而容易忽略一个更底层的细节：响应头里的 Content-Type。它决定了搜索蜘蛛把这页当成 HTML 来解析，还是当成纯文本、图片、下载文件直接跳过。一旦类型判错，页面里的链接基本不会被继续读取。
Content-Type 是怎么影响链接解析的
搜索蜘蛛拿到响应后，第一步是判断“这是不是我能解析的文档”。Content-Type 是最主要的判断依据：只有 text/html（以及 application/xhtml+xml 等少数几种）才会进入 HTML 解析流程，a 标签的 href、canonical、meta 这些才会被读取。如果返回的是 text/plain，抓取端多半只把内容当纯文本记录，不会从中提取链接。
常见的几类错误写法
1. 返回 text/plain
多见于程序里手动设置了 header，或者 Nginx 的 default_type 被改成了 text/plain。页面在浏览器里看着正常，是因为浏览器有较强的容错和嗅探能力，但抓取端不一定做同等程度的猜测。
2. 缺失 Content-Type，或返回 application/octet-stream
缺失时，不同抓取端的策略不一致，有的会尝试嗅探是不是 HTML，有的直接按未知类型跳过。octet-stream 这类“二进制下载”信号更明确，被当成可解析网页的概率很低。
3. charset 和实际编码不一致
比如响应头写 charset=gbk，文件其实是 UTF-8。类型判断可能仍然通过，但 URL 里带中文或特殊字符时，解码出来的链接会变成乱码，等于给了蜘蛛一个并不存在的地址。
蜘蛛大致会怎么处理
- 类型明确为 HTML：正常解析，提取页面内可抓取的链接。
- 类型为纯文本或二进制：通常只记录内容摘要或直接跳过，不提取链接。
- 类型缺失或模糊：取决于抓取端策略，结果不稳定，同一批入口页可能出现有的抓、有的不抓。
- 编码声明冲突：页面本身能解析，但提取出的 URL 可能已经损坏。
排查与修复顺序
- 用 curl -I 或浏览器开发者工具的 Network 面板看响应头，确认 Content-Type 是否存在、是否包含 charset。
- 对比响应头里的 charset 与文件真实编码，可用 file -i 或编辑器确认。
- 检查服务器配置：Nginx 的 charset、default_type，Apache 的 AddDefaultCharset，以及后端框架是否覆盖了 Content-Type。
- 确认没有被中间层改写：CDN、反向代理、WAF 有时会重置响应头，源站正常不代表最终返回正常。
- 修好后重新访问一次入口页，对比返回头与页面内链接是否完整。
几个容易忽略的细节
- 如果响应头写了 X-Content-Type-Options: nosniff，抓取端就少了嗅探空间，Content-Type 写错会更直接地影响解析。
- 用 PHP 等语言输出时，注意是否有 BOM 或额外空行被提前输出，导致 header 无法正常生效。
- gzip、br 压缩本身不影响类型判断，但压缩层出错会直接让响应变成乱码，症状看起来很像编码问题。
- 入口页返回 200 但类型错误时，从日志上看状态码完全正常，不专门看响应头很难发现。
提示：Content-Type 属于基础配置，修对了并不等于一定被抓取和收录，它只是让入口页回到“可以被正常解析”的起跑线。
如果入口页日志里状态码正常、响应体也有内容，但目标 URL 长期没有抓取记录，不妨先把响应头里的 Content-Type 和 charset 从头到尾核对一遍。这个环节成本很低，却经常被跳过。