事情本身不复杂，线索都在日志里。上线当天用预热脚本把两千条新地址推到了 CDN，其中包含一批模板默认带 noindex 的草稿页。后来这些页面改成正式发布，源站已经是 index，但节点上还是三天前的副本，GSC 里一直显示被 noindex 排除。
第一反应是「缓存键带 cookie 变体，purge 只清掉了其中一个变体」，验证下来不成立。
原因不止一个，得分开看。预热脚本只按 URL 列表推送，不检查页面的 robots 状态。另一种情况是页面缓存 TTL 设成了七天，改状态后不会自动回源。
不容易想到的是，回源时命中了 304，边缘认为内容没变，继续用旧响应。
动手时先确认边缘返回的页面里 robots 是什么
curl -s https://www.example.com/p/1024 | grep -o '<meta name="robots"[^>]*>'然后按 URL 逐个清理而不是整站刷新
curl -X PURGE https://www.example.com/p/1024预热脚本里加一道 robots 过滤，只推可索引页面
grep -rn 'preheat' deploy/ | head剩下的就是把 HTML 的 TTL 降到十分钟，靠回源验证新鲜度
proxy_cache_valid 200 10m;改完先别撤，确认这几项。同一地址在节点和源站返回的 robots 标签一致，索引报告里的 noindex 排除数一周内归零。
容易忽略的是，预热是为了让用户更快拿到内容，不是为了让搜索引擎更快收录，把不可索引的页面也推上去只会帮倒忙。这类问题最好一次改到位，反复小改反而容易把原因搅混。