做蜘蛛池入口頁时，很多人只看 HTTP 狀態碼：返回 200 就認為没問题。但搜尋蜘蛛拿到响應之後還有一步“解碼 + 解析”，如果這一步失敗，頁面上寫得再整齐的連結也等于不存在。狀態碼 200 只說明服務器愿意回應，不說明内容能被讀懂。

先给结论

Content-Type 和字符编碼属于“能不能讀懂”的范畴。寫错通常有两種後果：一是搜尋蜘蛛放弃解析，整頁連結都發現不了；二是解析出乱碼，連結被拼成错誤 URL，抓取失敗，甚至在日誌里留下無效的抓取记錄。這两種情况下，你可能都能看到蜘蛛来訪問，但目标 URL 就是不见動静。

容易踩坑的几類配置

1. Content-Type 不是 text/html

响應头寫成 text/plain 时，部分抓取器會按纯文本處理，不做 HTML 解析；寫成 application/json 或 application/octet-stream 更直接，等于声明“這不是網頁”。入口頁建议统一返回 text/html; charset=utf-8。

2. charset 缺失或前後冲突

頁面實际是 GBK，响應头却寫 utf-8，或者 HTTP 头與 meta charset 声明不一致。抓取器通常以 HTTP 头優先，解出来就是乱碼，域名和路径里可能出現替換字符，連結自然拼不對。

3. 压缩與传輸声明不一致

服務器開了 gzip 或 br，但 Content-Encoding 没带上，或者中間层解压後又原样传递，抓取器拿到的是压缩字节流，解析结果往往為空。

4. 前置 BOM 或多余輸出

文件開头带 BOM、程序在模板标簽前多輸出一個空行，都可能影响解析起点，让第一段連結被吃掉。

自查：三條命令基本能看明白

1. 用 curl -I 查看入口頁响應头，確認狀態碼以及 Content-Type 里是否带 charset。
2. 用 curl -s 取一次正文，只看開头 500 字节，判断是不是可讀的 HTML，有没有乱碼。
3. 再用 curl -s --compressed 取一次，與上一步對比，判断問题出在解压环节還是内容本身。

如果本地看正常、抓取工具看異常，就要怀疑 CDN 或 WAF 在中間改寫了响應头。

修复顺序與注意点

• 先统一 Content-Type：入口頁一律声明為 text/html 並带上 charset。
• 再统一编碼：文件儲存為 UTF-8 無 BOM，meta charset 與响應头保持一致。
• 最後處理压缩：確認 Content-Encoding 與實际传輸一致，中間层不要重复压缩。
• 改完之後观察一段時間日誌，別只改一次就下结论。

連結能否被發現，前提是“响應可解析”。Content-Type 和编碼属于基础设施层面的問题，優先級高于入口頁數量、模板規模這類运营手段。

常见追問

改了 Content-Type，以前的抓取會重新解析吗？

通常不會自動回溯。要等搜尋蜘蛛下次重新抓取该入口頁，所以入口頁保持可訪問、有合理的更新频率仍然重要。

只有一部分入口頁出問题，要不要全量排查？

如果這些入口頁由同一套程序或同一台服務器生成，建议批量抽查。這類配置错誤往往是成片出現的，單獨修一两個頁面意义不大。

Content-Type 正确了，連結就一定會被抓吗？

不一定。它只是排除了“讀不懂”這一层障碍，後面的抓取预算分配、頁面质量判断、目标 URL 自身狀態都會影响结果，排查时按顺序一层层来。