发布监控只查200不够：把noindex响应头和正文版本一起验

发布监控只检查HTTP 200，可能漏掉一种严重差异：公开页面可以正常打开，响应头却仍然带着测试环境的noindex。要检查发布后的索引指令，应该把正式URL的响应头、HTML与正文版本一起保存，再判断差异来自应用、代理规则还是缓存副本。

先建立少量有代表性的检查对象

选取首页、主要产品模板和文章模板的代表页面，记录期望的公开状态。若站点存在不同域名、语言路径或专门的下载路由，应按真实配置补充用例。私有页面和本来就需要noindex的页面要另列，不能为了让监控全绿，把所有限制一并移除。

每次使用完整正式URL发起GET请求，保留时间、状态码、重定向去向、响应头和HTML。先看跳转是否到预期页面，再检查最终响应；不要用后台预览结果替代公网，也不要只看HEAD请求推断正文中的标签。

HTML里的robots元标签和响应头里的X-Robots-Tag都可能携带规则。Google的robots规则说明明确支持这两种页面级设置，并指出抓取器需要能够访问页面才能读取它们。因此，看到HTML里有index，不能就忽略响应头中仍存在的noindex。

再选一段本次确实修改过的可见文字作为版本参照。若公网正文仍旧、源站正文已新，缓存副本值得检查；若正文一致而公网额外出现noindex，代理或边缘的响应头规则也值得检查。两种迹象都只是定位依据，需要结合配置确认，不能单凭一个缓存字段认定根因。

有权限的运维可在保持正确主机名和路径的条件下核对源站，避免把另一个虚拟站点的响应当成对照。若源站本身仍输出错误指令，应先定位模板、应用设置或服务器规则；只清CDN缓存，会让同样的错误再次被存入。

如果源站正确、公网仍旧，再核当前缓存策略和受影响对象。带随机参数可能访问到不同缓存键，不能据此宣布原URL已经修好。真正验收时要回到没有测试参数的正式地址，观察新正文和指令是否同时出现。

光算的公网残留noindex与缓存排查说明提供了源站、公网和响应头对照的思路。它适合用于补充发布用例，但实际清理范围仍由本站缓存配置决定，不需要为了排一个页面问题盲目清空全站。

一条有用的告警至少列出受影响URL、期望值、实际指令、正文版本特征和检查时间。应用侧仍错就交给输出该标签或头部的维护人；只有公网存在差异，就继续核边缘规则与缓存。避免所有告警都写成“SEO异常”，最后无人知道该看哪一层。

修复后记录同URL的前后响应，并检查本来需要保护的页面是否保持原状态。如果公开内容不应被禁止索引，也要确认robots.txt没有阻止搜索引擎读取新响应；真正的私有内容则继续通过访问控制保护，noindex本身不是权限机制。

这轮发布检查能证明的是“抽样请求收到预期版本和指令”。它不能证明所有边缘节点已经一致，也不能提前证明Google恢复收录。后续抓取和索引变化应单独观察，避免把技术修复完成和搜索结果恢复混成一个状态。