做蜘蛛池入口頁时，大家通常盯着狀態碼、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 從头到尾核對一遍。這個环节成本很低，却经常被跳過。