排查蜘蛛池入口頁的 URL 發現問题时，大多數人會去看正文、連結结构、robots.txt，却很少回头检查 HTTP 响應头。實际上搜尋蜘蛛在解析一個頁面之前，首先要根據响應头判断這個响應是什么、能不能用、要不要繼續往下讀。响應头寫错，正文结构再規范也可能白費。
搜尋蜘蛛是先讀响應头，還是先讀正文
抓取一個 URL 时，蜘蛛拿到的是完整的 HTTP 响應。它會先看狀態碼，再看 Content-Type、Content-Encoding、X-Robots-Tag 這類头部字段，然後才决定用什么解析器處理正文。
也就是说，响應头决定了這段内容被当成什么，正文只决定里面有什么連結。如果头部把它当成图片、二進制流或者不可索引的资源，正文里的連結大概率不會被繼續解析。
几類容易踩坑的响應头問题
Content-Type 寫错或缺失
- 返回的是 HTML，但 Content-Type 寫成 text/plain 或 application/octet-stream，蜘蛛可能只当作纯文本處理，不再提取連結。
- Content-Type 直接缺失，不同爬虫的容错能力不一样，有的能按 HTML 猜测，有的會直接跳過。
- charset 與實际编碼不一致，中文锚文本變成乱碼。連結本身通常還能识別，但如果連結是中文路径或带中文參數，就可能解析失敗。
X-Robots-Tag 誤伤
X-Robots-Tag 寫在响應头里，作用和 meta robots 類似。常见的情况是服務器或 CDN 统一加了一條 noindex 或 nofollow，而运营只检查了頁面里的 meta 标簽，没有看响應头。
- 带 noindex：頁面本身不進索引，但抓取和連結發現通常還會繼續。
- 带 nofollow：頁面可以被抓取，但頁面上的連結可能不會被繼續追踪，這會直接影响目标 URL 的發現。
- 带 noarchive、nosnippet 之類，一般不影响 URL 發現，不用太紧張。
狀態碼和响應头内容互相矛盾
比如返回 200，但头部寫着 Content-Length: 0；或者返回 200 却带着一段跳轉指令。這類前後不一的响應會让蜘蛛难以判断頁面是否真的可用，處理方式也因爬虫而异。更稳妥的做法是让狀態碼、响應头、正文三者保持一致。
压缩與分块传輸異常
Content-Encoding 声明了 gzip，實际却没有压缩；或者分块传輸被中途截断。蜘蛛拿到的内容是残缺的，連結可能只解析到一半。這類問题在日誌里往往表現為抓取成功但發現量偏低，不容易第一眼看出。
怎么排查入口頁的响應头
- 用不带浏览器特征的請求获取响應头，比如命令行工具直接請求，而不是只看浏览器開發者工具里经過前端處理的结果。
- 換一個和搜尋蜘蛛接近的 User-Agent 再請求一次，確認没有被 CDN 或 WAF 返回不同的头部。
- 重点核對四項：狀態碼、Content-Type、Content-Encoding、X-Robots-Tag。
- 把入口頁實际解析出的連結數量和你的预期對照一遍，確認没有漏掉目标連結。
修正时的几個原則
- HTML 頁面统一返回 text/html; charset=utf-8，並确保實际编碼與声明一致。
- 不要在全站或整個目錄层面批量添加 X-Robots-Tag，需要限制时按路径或按頁面精细設定。
- 响應头、狀態碼、正文保持一致，別让蜘蛛在两個信号之間做猜测。
- 改動後持續观察一段時間服務器日誌里的蜘蛛抓取和連結發現情况，而不是改完就下结论。
响應头不是技術细节，它是蜘蛛理解頁面的第一层信号。URL 發現出問题时，先確認這层信号没有寫错，再去調連結结构和内容，能少走很多弯路。
需要說明的是，响應头配置正确只是让頁面具备被發現的條件，最终是否抓取、抓取多少，仍然由搜尋引擎按自己的策略决定，任何配置都無法保證收錄或排名。