很多站点把注意力放在 robots.txt 和页面里的 meta robots 上，却忽略了一个更隐蔽的位置：HTTP 响应头里的 X-Robots-Tag。它不写在 HTML 里，用浏览器正常浏览时也看不见，但它同样能告诉搜索引擎某个 URL 或某类文件该怎么处理。一旦配置出错，影响范围往往比单页面里的 meta 标签更大。
它为什么容易被漏掉
X-Robots-Tag 由服务器、反向代理、CDN 或应用框架生成，不在模板文件里，也不在 CMS 的编辑界面里。做站内自查时，很多人习惯搜索 HTML 源码，而响应头根本搜不到。等到发现某些页面长期不收录，才会回头怀疑是不是哪一层加了限制。
它能做哪些事
- noindex：不索引当前 URL，可用于 PDF、图片或整类由同一后端输出的页面。
- nofollow：不追踪该响应中的链接。
- noarchive / nosnippet：控制是否提供快照、摘要。
- noimageindex：控制图片是否进入图片搜索。
- max-snippet、unavailable_after：限定摘要长度或页面失效时间。
正因为它可以针对一整类资源生效，用好了省事，用错了也更容易波及一大片。
常见的几种误伤
- 为了挡住测试环境，在服务器或 CDN 上全局加了一行 noindex，正式上线后忘了去掉。
- 只想减少低质量附件被索引，结果把产品手册、白皮书这类有价值的 PDF 一起挡在了外面。
- 安全插件、WAF 或防采集规则在拦截爬虫时顺带加上了 noindex，甚至直接返回 403。
- 多套环境共用一份配置，测试环境的响应头跟着同步到了生产环境。
- 改版迁移后，旧规则还留在 Nginx 或 Apache 的 location 块里，没人清理。
自查可以这样做
- 挑代表性 URL：首页、栏目页、详情页、分页、PDF、图片、JS 和 CSS、接口页各取几个。
- 用 curl -sI 带上常见爬虫 UA 分别请求，观察响应头里是否有 X-Robots-Tag。
- 对比本地、源站 IP、CDN 节点三种路径的返回结果，确认是否一致。
- 把响应头与页面里的 meta robots 放在一起看，确认两者没有互相打架。
- 翻一遍访问日志，看被限制的 URL 是否原本有稳定的抓取记录。
多个 X-Robots-Tag 头会合并，冲突时通常更严格的那条占上风；值不区分大小写，但不同指令叠加后可能产生意料之外的结果，所以不要靠猜来判断最终生效的是什么。
修复与长期维护
- 改动响应头前先记录当前配置，改完用同一批 URL 复测一遍。
- 把响应头检查写进上线清单，尤其是换 CDN、换服务器、换框架的时候。
- 用一个简单的定时任务定期抓取关键 URL，发现异常及时告警。
- 明确谁有权修改这一层配置，避免多人各自加规则、互相覆盖。
- 如果只是测试环境需要限制，尽量用访问密码或 IP 白名单，而不是依赖 noindex。
X-Robots-Tag 不是必须用的东西，但一旦用上，它就是一种沉默的指令。花十分钟把关键 URL 的响应头过一遍，比事后反复猜测为什么某些页面不收录要省事得多。