蜘蛛访问一个 URL 时，最先拿到的是 HTTP 响应。状态码决定接下来怎么处理，响应头则像一组附加说明，告诉蜘蛛这个 URL 的类型、能否索引、是否有替代版本、多久之后可以再来。很多抓取问题不在正文里，而在这些容易被忽略的头部字段中。

响应头为什么会影响 URL 发现

蜘蛛解析 HTML 链接的前提，是它把响应内容当作 HTML 处理。如果 Content-Type 写成 text/plain 或 application/octet-stream，蜘蛛可能只保存文本，不去提取其中的 a 标签。结果就是页面能被抓取，但里面的链接不会进入待抓取队列，URL 发现路径在这里断掉。

另一个常见情况是响应头里带了 noindex 或 nofollow，而站点管理员只检查了 HTML meta 标签。X-Robots-Tag 的优先级不低，尤其是由服务器、CDN 或 WAF 统一添加时，很容易影响到整站或某个目录。

三个常被写错的响应头

Content-Type

HTML 页面应返回 text/html，并带字符集，例如 text/html; charset=utf-8。如果后端框架、反向代理或 CDN 把类型改成了 text/plain，蜘蛛仍可能抓取，但对链接的解析会变得不可靠。动态渲染服务、下载接口和 API 路由尤其容易出这个问题。

X-Robots-Tag

这个头部可以按 URL 路径批量控制抓取和索引。比如给测试目录加 noindex，给图片加 noindex 但保留抓取，都是常见用法。问题在于：一旦规则写宽了，或者某个中间层默认加上了 noindex，蜘蛛会按头部执行，页面即使有正常内链也可能不被索引。排查时先看响应头，再看 HTML meta，顺序不要反。

Link

Link 头可以传递 rel=canonical、rel=alternate、rel=next/prev 等关系。蜘蛛会把它当作页面关系的一部分。如果 Link 头里的 canonical 指向了错误 URL，或者和 HTML 里的 canonical 不一致，蜘蛛需要自己判断，抓取路径可能被带偏。多语言站点的 hreflang 如果只写在 Link 头里，也要保证语言代码和 URL 对应正确。

Retry-After 与抓取退让

当服务器返回 503 或 429 时，可以在 Retry-After 里写明多少秒后重试，或给一个具体时间。蜘蛛会参考这个信号调整再次访问的间隔。写得太短，服务器还没恢复，蜘蛛可能继续撞墙；写得太长，URL 复查会被推迟。对于计划内维护，比直接返回 200 的空页面更清楚。

响应头是蜘蛛判断“这个 URL 现在能不能抓、抓了怎么用”的快捷依据。它不决定排名，但会影响 URL 是否被发现、是否进入索引流程。

站点侧怎么检查

• 用 curl -I 或浏览器开发者工具查看目标 URL 的响应头，确认状态码和 Content-Type。
• 搜索 X-Robots-Tag，确认没有意外的 noindex、nofollow 或 nosnippet。
• 核对 Link 头里的 canonical、alternate 是否与页面内声明一致。
• 检查 CDN、WAF、反向代理是否批量添加了头部规则，尤其是新上线的安全策略。
• 在抓取日志中观察同一 URL 的返回状态，若大量 503 或 429，结合 Retry-After 判断退让节奏。

响应头本身不复杂，难的是它经常由多个层共同写入。上线新功能、更换 CDN 或调整安全规则后，抽几个代表性 URL 看一眼头部，比事后从日志里反查要省事。把 Content-Type、X-Robots-Tag、Link 和 Retry-After 这几项纳入例行检查，蜘蛛的 URL 发现和抓取路径会更可控。