蜘蛛抓取一個 URL 时，最先拿到的不是正文，而是狀態行和 HTTP 响應头。很多入口頁的問题，比如“蜘蛛来了但不抓”“抓了一次就不再来”，並不在頁面内容里，而在响應头传递的信息上。這篇文章不讨论怎么讨好蜘蛛，只梳理入口頁响應头里值得检查的字段，以及調整时需要注意的地方。
為什么响應头值得單獨检查
蜘蛛的抓取流程通常分几步：解析 DNS、建立连接、發送請求、讀取响應头、再决定是否繼續讀取正文。如果响應头里出現让它困惑的信号，比如内容類型不對、長度不一致、缓存指令互相矛盾，它可能提前結束這次抓取。入口頁本身内容少，响應头的影响就更明顯。
另一個原因是响應头容易被忽略。頁面模板、服務器配置、CDN 回源規則、反向代理，任何一层都可能改掉或追加响應头。上线前只看了浏览器里頁面能打開，不代表蜘蛛看到的头部是一样的。
几個關键字段怎么核對
Content-Type 與字符集
入口頁應该返回 text/html，並带上明确的字符集，比如 text/html; charset=utf-8。如果返回 text/plain、application/octet-stream，或者没有字符集，蜘蛛可能把頁面当成非 HTML 资源，或者按错誤的编碼解析。中文入口頁尤其容易出現编碼不一致，頁面 meta 寫 utf-8，响應头却是 gbk，抓取端會看到乱碼。
Content-Length 與传輸编碼
如果服務器声明了 Content-Length，但實际返回的字节數對不上，或者同时出現 Content-Length 和 Transfer-Encoding: chunked，抓取端可能判定响應異常。動態生成入口頁、gzip 压缩、代理改寫都可能引發這類問题。检查方法很简單：用 curl -I 看头部，再用 curl -s | wc -c 看實际長度，對比是否一致。不一致不一定會立刻出問题，但属于隐患。
缓存相關字段
Cache-Control、Expires、Last-Modified、ETag 這几個字段會影响蜘蛛回訪时的行為。入口頁如果設定 no-store，每次都要重新完整下载，抓取成本會上升；如果設定過長的 max-age，蜘蛛可能長時間拿不到更新。比較稳妥的做法是给入口頁一個适中的缓存時間，保留 Last-Modified 或 ETag，让蜘蛛可以用條件請求拿到 304，减少重复传輸。
缓存不是越短越好，也不是越長越好。入口頁更新频率低时，可以放宽缓存；频繁調整模板时，再临时收紧，並观察日誌里的抓取频次變化。
X-Robots-Tag
這個响應头容易被忘记。它和頁面里的 meta robots 作用類似，但優先級和寫法不同。如果服務器或 CDN 统一加了一條 X-Robots-Tag: noindex，頁面里寫再多允许索引的标簽也没用。检查入口頁时，確認没有意外的 noindex、nofollow 或 noarchive 头。
Vary、压缩與變体
如果入口頁會根據 Accept-Encoding 或 User-Agent 返回不同内容，Vary 头需要正确設定。設定不当可能導致缓存把 A 變体返回给 B 請求，蜘蛛拿到压缩错乱或内容缺失的版本。常见做法是只對 Accept-Encoding 做压缩變体，不要根據 UA 返回完全不同的 HTML。
重定向與 Location
入口頁如果做了跳轉，响應头里的 Location 要指向可抓取的绝對 URL，並且狀態碼用 301 或 302 保持一致，不要混用。跳轉鏈太長、Location 指向相對路径、或者跳到需要登入的頁面，都會让蜘蛛在入口處停下。跳轉本身不是問题，問题是不稳定的跳轉。
检查與調整的日常做法
- 用 curl -I 批量抽查入口頁，重点看狀態碼、Content-Type、Location、X-Robots-Tag。
- 對比响應头里的 Content-Length 和實际字节數，尤其是经過 CDN 和反向代理的站点。
- 在服務器日誌里观察同一入口頁的返回狀態和响應大小，判断头部是否稳定。
- 改動缓存、压缩、防護規則後，至少观察一個抓取周期，再决定是否繼續調整。
- 把入口頁和目标站的响應头策略分開管理，避免互相影响。
使用建议與常见誤区
一個常见誤区是把响應头当成優化排名的手段，频繁修改各種字段。响應头的首要作用是准确传递资源信息，不是制造信号。另一個誤区是只看首頁或少量样本，忽略批量生成的入口頁。模板一變，所有入口頁的头部都會變，抽查要覆盖不同模板和不同服務器节点。
如果發現蜘蛛抓取减少，先看狀態碼和响應头，再看内容。把响應头当作排查清單里靠前的一項，比盲目改頁面更有效率。調整时保持小步、可回滚，记錄變更前後的日誌差异，才能判断某個字段到底有没有影响。