很多人調试蜘蛛池入口頁时，盯着頁面 HTML 看半天，却忽略了更早被蜘蛛讀到的東西——HTTP 响應头。蜘蛛請求一個 URL，服務器先返回响應头和狀態碼，之後才是正文。头部信息如果配置得別扭，蜘蛛可能還没解析到連結就已经做了判断。
响應头在抓取鏈路里的位置
蜘蛛的工作顺序大致是：發請求、收响應头、判断狀態碼與内容類型、决定是否下载正文、解析連結。响應头處在“决定要不要繼續”的位置，它的作用往往比入口頁里多寫几行文字更靠前。
常见需要留意的头部有：content-type、last-modified、etag、cache-control、content-encoding、vary、x-robots-tag，以及跳轉时的 location。
Content-Type 與字符集：別让蜘蛛以為這是個文件
入口頁返回的應该是 text/html，並带上明确的字符集，例如 content-type: text/html; charset=utf-8。如果服務器把入口頁返回成 application/octet-stream、text/plain，或者干脆没有 charset，蜘蛛可能把它当成下载文件，或無法确定编碼，連結解析自然受影响。
- HTML 頁面：text/html; charset=utf-8
- 纯文本 sitemap：application/xml 或 text/xml
- 不要用 text/plain 返回真正需要解析連結的入口頁
字符集最好和頁面里的 meta charset 保持一致，避免出現头部说 utf-8、正文里却是 gbk 這種自相矛盾的情况。
Last-Modified 與 ETag：告诉蜘蛛“這次不用重爬”
這两個头部直接關系到蜘蛛會不會走 304 流程。入口頁内容没變时，服務器返回 304 Not Modified，蜘蛛就知道可以复用已有内容，减少下载量。這對蜘蛛池這種頁面數量多的场景挺有用：抓取预算省下来，可以分给更多待發現的 URL。
反過来，如果入口頁每次請求都返回 200 和全新的 last-modified，蜘蛛無法判断内容是否變化，可能反复下载同一批頁面。要避免“每次都假装更新”的寫法。
Cache-Control：別把蜘蛛挡在缓存外面
入口頁往往套了 CDN 或反向代理，cache-control 决定缓存多久、谁来缓存。這里容易出两個問题：
- 缓存時間過長：入口頁的連結列表更新了，CDN 還在返回舊版本，蜘蛛拿到的和實际不符。
- no-store 或 no-cache 乱用：本来想让内容即时更新，结果节点频繁回源，入口頁响應變慢，又回到抓取效率的問题上。
比較稳妥的做法是给入口頁設定較短的缓存時間，並在連結列表變動时主動刷新缓存，而不是長期缓存或完全禁用缓存。
几個容易被忽略的头部
X-Robots-Tag
它在响應头里承担和 meta robots 類似的作用。如果不小心给入口頁加了 noindex 或 nofollow，頁面里的連結可能就不被跟進了。配置 CDN、安全插件或網關时，留意它們是否悄悄加了這個头。
Vary 與 Content-Encoding
如果服務器根據 User-Agent 或 Accept-Encoding 返回不同内容，vary 要寫清楚，否則缓存层可能把移動版内容返回给桌面蜘蛛，或者反過来。压缩本身没問题，但要让蜘蛛能正常解压。
Location
跳轉时 location 指向的目标要可訪問，不要鏈條太長。跳轉层級過深，蜘蛛跟到一半就停了，這在入口頁里等于白铺。
怎么自查
- 用 curl -I 或浏览器網絡面板看响應头，先確認狀態碼和 content-type。
- 连續請求两次，观察第二次是否返回 304，last-modified 和 etag 是否稳定。
- 检查 CDN 回源配置，確認入口頁没有被長期缓存或错誤缓存。
- 核對是否有意外的 x-robots-tag，尤其是经過網關和安全组件之後。
响應头是蜘蛛對入口頁的第一印象。它不直接决定連結會不會被發現，但會影响蜘蛛愿不愿意繼續讀下去、愿不愿意下次再来。
把响應头理顺，成本不高，却能减少很多“頁面明明寫好了，蜘蛛却没動静”的困惑。蜘蛛池本身只解决 URL 發現的一环，头部配置属于把這一环做扎實的细节，剩下的收錄和排名仍要看目标頁自身。