意外的 noindex：请求重新抓取前先检查响应

当爬虫处理到意外的 noindex 指令时，它可能阻止原本有用的页面被编入索引。检查页面元数据和响应头，然后修复相关模板或发布配置，而不是反复请求重新抓取。

检查所有相关来源

检查最终响应中的 X-Robots-Tag 和实际提供的 robots 元素。如果 JavaScript 修改 head，应比较渲染结果。分别检查代表性模板和主机：预发布规则可能意外进入生产环境，而 CDN 或应用中间件也可能独立于 CMS 字段添加响应头。

区分抓取与索引

robots.txt 的抓取限制不等同于 noindex。如果爬虫无法获取页面，就可能无法读取修改后的索引指令。核实预期组合，不要删除所有限制，也不要假设站点地图条目会覆盖 noindex。

示例：只有 PDF 资源受影响

假设文章正常，但下载资源返回了非预期的索引响应头。检查负责该内容类型的服务器或 CDN 规则。通过发布流程修正具体规则，然后检查一个受影响资源和一篇未受影响文章。这个假设案例只检查首页 HTML 就会漏掉。

防止再次发生

在发布清单中加入重要模板的生产索引指令检查。控制预发布环境访问，并记录预期配置。定时监测器可以在下一次检查时观察响应，但不能保证在搜索爬虫到来前发现问题。

修正后核实线上响应，并持续跟踪网址检查信息。成功的实时测试不会强制立即重新索引，也不保证流量恢复日期。

检查页面元数据，并使用 Google 的 noindex 文档选择恰当实现。