入口頁的正文、URL 结构、連結拓扑经常被反复讨论，但响應头這類“看不见的配置”往往没人细看。對蜘蛛来说，响應头是它判断這份内容能不能用、要不要缓存、下次什么时候再来的第一批信号。寫错一個字段，通常不會立刻出問题，却會让抓取效率慢慢變差。
一、响應头為什么值得單獨拿出来看
蜘蛛請求一個 URL 时，最先拿到的是狀態行和响應头，之後才是正文。它從中讀出几件事：這份内容是什么類型、有多大、能不能缓存、有没有額外的抓取指令。正文寫得再好，如果头部把内容類型标错，或者给蜘蛛返回了“別抓”的信号，前面做的工作就白費了。
二、Cache-Control：別把蜘蛛也一起缓存住
Cache-Control 原本是给浏览器和 CDN 用的，但蜘蛛也會參考它来决定自己的抓取节奏。常见問题有這几類：
- max-age 设得過長：比如一年。頁面更新了，缓存层和蜘蛛都可能繼續拿舊版本。
- 把入口頁设成 no-store：虽然能保證每次都是新的，但會額外增加回源压力，對入口頁這種需要反复抓取的頁面並不划算。
- CDN 與源站头不一致：源站设了短缓存，CDN 規則又覆盖成長期缓存，實际给蜘蛛的是後者。
比較稳妥的做法是：入口頁按實际更新频率给一個合理的 max-age（几分钟到几小时），並配合 ETag 或 Last-Modified 让缓存可以校驗，而不是每次都完整回源。
三、Vary：寫错會让缓存命中率掉下去
Vary 告诉缓存“這個响應會因為哪些請求头而不同”。常见誤用是把 Vary 寫成 Vary: *，意思是任何請求头不同都算不同资源，缓存基本失效，每次請求都回源。入口頁被高频訪問时，這會直接体現為源站压力上升。
如果站点确實按 Accept-Encoding 之類的字段区分内容，Vary 里只寫真正用到的字段即可。另外要留意一種隐性風險：有些站点會给不同 User-Agent 返回不同内容，這本身就容易让蜘蛛和普通訪客看到不一致的頁面。與其靠 Vary 掩盖，不如先確認這種区分是否真的有必要。
四、X-Robots-Tag：方便，也容易誤伤
X-Robots-Tag 可以在 HTTP 头里下發抓取指令，作用范围比 meta robots 更广，能覆盖图片、PDF 等非 HTML 资源。但它有两個坑：
- 寫在全局配置里：服務器或 CDN 的預設头一旦带上 noindex，整個域名的頁面都可能收到這個信号，而排查时很少有人第一時間想到去看响應头。
- 和正文里的 meta 冲突：两處指令不一致时，更嚴格的那個通常生效，结果往往不是你以為的那個。
建议把 X-Robots-Tag 的使用范围收窄到明确的目錄或文件類型，改動前先在一两個 URL 上驗證，不要直接在全局层動手。
五、几個顺手一起检查的头
- Content-Type：声明與實际内容要一致，charset 也要寫對，否則容易出現解析偏差。
- ETag / Last-Modified：给缓存和蜘蛛一個校驗依據，能减少重复传輸。
- Retry-After：返回 503 时配合這個头，比让蜘蛛反复重试更友好。
- Content-Length：與實际传輸量不符时，部分客戶端會截断或等待超时。
六、一份可以照着核對的清單
- 用命令行工具拉一次入口頁的完整响應头，再和 CDN 回源时看到的做對比。
- 確認 Cache-Control 的 max-age 與頁面實际更新频率匹配。
- 检查 Vary 是否被寫成了通配符。
- 全局搜尋 X-Robots-Tag 的配置位置，確認没有意外的 noindex。
- 確認内容類型、字符集、ETag 都正常。
- 改動後隔一段時間看日誌，观察抓取狀態和返回碼有没有變化。
响應头的問题通常不會立刻顯現，它更像是慢慢拖低效率的因素。與其一次性大改，不如把它纳入常規巡检，每次只動一個變量，便于回看效果。
把响應头当成入口頁配置的一部分来维護，並不需要多复杂，但要保證源站、CDN 和蜘蛛看到的是同一套東西。這種一致性带来的确定性，往往比多堆几個入口頁更有價值。