很多站点在排查收录问题时，第一反应是改 robots.txt。但 robots.txt 管的是“能不能抓”，而“能不能收录”由 noindex 和 X-Robots-Tag 决定。这两者的作用层级不同，配错的位置也更隐蔽：一个藏在模板里，一个藏在服务器或 CDN 的响应头里，从页面上不一定看得出来。
先把三件事分清楚
- 抓取控制：robots.txt、meta robots 里的 nofollow 部分，影响蜘蛛是否访问。
- 收录控制：noindex、X-Robots-Tag，告诉搜索引擎这个地址不要出现在结果里。
- 规范化：canonical，用于在多个相似地址中指出首选版本。
一个容易被忽略的点：被 robots.txt 挡住的地址，如果外部有链接指向它，仍然可能以“仅有链接、没有摘要”的形式出现。想彻底不收录，需要的是 noindex，而不是单纯屏蔽抓取。
noindex 相关自查清单
meta robots 标签
- 模板是否在所有页面统一注入了 noindex，只给少数栏目做了例外。
- 分页页、标签聚合页、站内搜索结果页是否被整批 noindex，这类页面要按实际内容质量逐个判断，不宜一刀切。
- 草稿、预览、打印版页面是否只靠登录态限制访问，而没有加 noindex。
- 指令写法是否正确：多个指令用英文逗号分隔，避免出现 noindex=true 这类非标准写法。
HTTP 响应头 X-Robots-Tag
- PDF、图片、视频等非 HTML 资源放不了 meta 标签，只能靠响应头控制。
- 检查反向代理、CDN、网关是否在某一层统一加了 noindex，而运维与内容团队互不知情。
- 多个中间件同时添加同名响应头时，可能出现覆盖或叠加，需要实际请求一次才能确认最终结果。
几种常见的误伤场景
- 测试环境的安全策略被带进生产环境，整站被加上 noindex。
- 灰度发布或 A/B 测试按比例分流，部分爬虫请求恰好命中了带 noindex 的版本。
- 多语言站或地区站中，某一语言版本的模板误加了 noindex。
- 站点迁移后旧域名的跳转页仍带 noindex，导致新地址迟迟没有被替换。
排查动作可以按这个顺序做
- 用命令行查看响应头，例如 curl -I 加页面地址，确认是否出现 X-Robots-Tag。
- 查看页面源代码，搜索 noindex 字样，确认 meta 标签的实际输出。
- 在模板、组件库、构建与部署脚本里全文搜索，找出注入点。
- 登录 CDN 与网关控制台，逐条核对与爬虫相关的响应头规则。
- 把确认要保留 noindex 的页面整理成清单，注明原因和负责人。
改动之后的验证与回归
去掉 noindex 之后，收录状态不会立刻恢复，需要等搜索引擎重新抓取并更新索引，这个周期可能从几天到几周不等。可以借助站长平台的 URL 检查工具，看当前抓取到的指令是否已经更新，再观察日志里该地址的抓取频次有没有回升。如果只是删掉了响应头，而页面本身的结构、内容质量没有改善，恢复速度通常也不会太快。
把它写进上线流程
更省事的做法是：环境区分靠配置，而不是靠人手工改标签；上线检查表里加一条“抽查三类页面的 noindex 状态”——首页、内容页、非 HTML 资源；每季度做一次全站抽查，重点看新上线的栏目和最近改过模板的模块。这样即使某次改动出了问题，也能在影响扩散之前发现。