聊 URL 发现时，多数人把注意力放在 Sitemap、内链和提交接口上，很少回头看服务器返回的响应头。其实响应头是爬虫每次请求都会读到的内容，它既可能帮着把新地址带进抓取队列，也可能在不经意间把整段路径挡在门外。

Link 响应头：不占页面位置的补充通道

Link 头的作用是告诉客户端“这个资源还和哪些地址有关”，格式大致为 Link: <目标地址>; rel="关系类型"。和 URL 发现关系比较近的几种关系类型有：

• rel="canonical"：把规范化信息放到 HTTP 层，适合 PDF、图片这类没有 head 的资源，或者不便改动模板的页面。
• rel="next" / rel="prev"：标注分页序列。主流搜索引擎已不再把它当作索引信号，但对爬虫理解列表翻页顺序仍有参考价值。
• rel="alternate"：多语言版本、移动版与桌面版的对应关系，也可以在头部声明。
• rel="preload" / rel="preconnect"：主要服务性能，但页面渲染变快，间接有利于抓取时的解析。

需要留意的是，Link 头只能表达“关系”，不能替代页面里可见的链接。如果某个地址只出现在响应头中，站内任何页面都没有指向它的可点击链接，它的发现优先级通常仍然偏低。

X-Robots-Tag：覆盖面比 meta 标签更广

meta robots 只能写在 HTML 的 head 里，而 X-Robots-Tag 是响应头字段，因此可以作用在图片、PDF、视频等没有 head 的资源上，也能按目录批量下发。常见的取值包括：

• noindex：允许抓取，但不进入索引；
• nofollow：不追踪该响应内页面上的链接；
• none：等价于 noindex 与 nofollow 同时生效。

配置时最容易出问题的是匹配规则写得太宽。比如为了屏蔽内部搜索参数，把规则写成匹配所有带问号的地址，结果把正常分页、追踪参数甚至部分详情页一起挡掉，URL 发现自然就断了。改动前建议先用少量 URL 做验证，确认命中范围符合预期再全量下发。

缓存头：让爬虫少花力气重复下载

ETag 和 Last-Modified 的作用，是让爬虫用条件请求判断内容有没有变。服务端返回 304 Not Modified 时，传输体积很小，爬虫能确认页面没有更新，把抓取额度留给别处。

反过来，如果每次请求都返回不同的 ETag，或者 Last-Modified 一直跟着当前时间走，爬虫就无法通过条件请求得出“未修改”的结论，只能整页重新下载。对内容量大的站点，这会持续消耗抓取资源，新地址排队的空间也被压缩。

Cache-Control 的时长同样值得关注。设置得过短，回源压力大，爬虫访问时更容易遇到缓慢响应；设置得过长，又要确认更新发布后能及时刷新缓存，否则爬虫读到的是旧版本。

几个具体的检查点

1. 随机抽几个页面，用命令行工具或浏览器开发者工具查看响应头，确认没有意外的 noindex 字段。
2. 检查 CDN 与源站是否返回同一套 X-Robots-Tag，避免回源版本与缓存版本不一致。
3. 确认 ETag 在内容未变时保持稳定，内容更新后才发生变化。
4. 需要被发现的 PDF、图片目录，可以评估用 Link 头补充 canonical 或 alternate。
5. 改动屏蔽规则后，隔几天回看服务器日志，确认目标路径的抓取量变化符合预期。

两个常见误区

• 把 Link 头当成提交入口，以为写了就会被收录。它只是补充说明资源关系，发现仍然要靠内链、站点地图等通道共同作用。
• 在 404 或 5xx 响应上也带 noindex，想借此加速清理。状态码本身已经表达了地址失效，额外叠加指令反而可能让爬虫对整段路径的判断变得混乱。

响应头不产生新内容，也不替代内链和站点地图。它更像是给爬虫的一句备注：这个地址是什么、和谁有关、现在要不要重新读一遍。

把响应头纳入日常检查，成本并不高，用一次批量抓取就能拿到全部字段。真正需要花心思的是改动之前的评估：一条规则会命中多少地址，其中有多少是你希望被发现的。想清楚这一点，再动手调整配置，URL 发现的通道才不会被自己关掉。