很多人做蜘蛛池入口頁时，把精力都花在“連結怎么寫、寫多少條”上，却忽略了一個更底层的問题：服務器返回的 Content-Type 是否正确。這個响應头决定了抓取程序把頁面当成“網頁”還是“一段文本”。如果它不對，頁面里寫得再清楚的連結，也可能只是普通字符串。
Content-Type 决定了頁面被当成什么解析
浏览器和搜尋蜘蛛拿到一個 URL，第一步先看响應头里的 Content-Type，再决定用哪種方式解析内容。常见几種情况：
- text/html：正常網頁，a 标簽里的 href 會被当作連結解析和跟進。
- text/plain：按纯文本處理，連結只是普通文字，通常不會被当成可抓取的 URL。
- application/xhtml+xml：按 XHTML 解析，連結一般仍然有效。
- application/json、application/xml、text/xml：按資料文件處理，里面的 a 标簽不會被识別成連結。
- 缺少 Content-Type 或没带 charset：中文容易出現乱碼，解析结果不稳定，連結也容易被截断。
入口頁最常见的三種踩坑
1. 伪静態規則把 .html 指到了错誤的後端
很多入口頁是伪静態的。如果 rewrite 規則把 .html 請求轉發给了一個返回 JSON 或纯文本的接口，响應头就會變成 application/json。頁面看着有内容，實际對抓取端来说是一份資料文件。
2. 動態脚本没有顯式設定头部
PHP、Python 等脚本預設輸出 text/html，但如果前面有額外的輸出，或者用了框架自带的 JSON 响應方式，头就變了。建议在輸出 HTML 之前顯式声明一次，不要依赖預設值。
3. 模板文件後缀不常见，被服務器按預設類型返回
有些站点把入口頁存成 .tpl、.txt、.dat 再通過規則輸出。如果服務器没配好對應類型，返回的可能是 text/plain。這種情况下浏览器里看到的是一堆带标簽的纯文本，連結自然也不會被跟進。
怎么快速自查
- 用命令行只看响應头，確認狀態碼是 200，且 Content-Type 是 text/html。
- 浏览器打開入口頁，查看網頁源代碼或响應信息，看類型和编碼是否正常。
- 把入口頁和一個正常頁面做對比：如果入口頁返回 200，但抓取日誌里始终没有目标 URL 的记錄，就要怀疑解析环节。
- 检查源碼里的連結是不是真的寫成了 a 标簽，而不是按钮、脚本或注释里的文字。
修正方向
- 静態頁：確認 .html、.htm 後缀被正确映射成 text/html。
- 動態頁：在輸出前顯式設定头部和字符集，避免和模板里的 meta charset 冲突。
- 反向代理或 CDN：检查是否改寫了 Content-Type，尤其是啟用了“自動轉換”類功能时。
- 改完後重新抓一次，先確認头部正确，再观察連結是否被跟進。
头部正确了，連結還是没被跟進怎么办
按顺序排除：頁面是否有 noindex、連結是否带了 nofollow、連結是否靠 JavaScript 動態插入、連結是否寫在注释或脚本块里、頁面是否必须登入才能看到。這些属于“能不能解析”的問题；而抓取频次、抓取预算属于“愿不愿意抓”的問题。两類問题最好分開排查，不要在同一個环节反复改。
提醒：Content-Type 是最容易被忽略、也最容易驗證的一項。排查抓取問题时，先花两分钟確認头部，往往比反复調整連結寫法更有效。