官网更新后 AI 仍说旧信息：日期、缓存与内容新鲜度核验

价格已经改成新方案，AI 仍复述旧价格；服务范围已经调整，搜索结果还显示旧简介。这类问题需要先回答“旧版本停在哪一层”，再决定改网页、清缓存，还是继续观察后续抓取。

官网正文更新、搜索系统重新处理、一次 AI 回答采用新信息，是三个不同的事件。 它们之间不存在可以统一承诺的同步时间。

本文讨论公开网页更新的技术核验。示例中的版本、日期和价格均为说明用途，不是平台响应时长或客户效果数据。

一、先建立一条可以辨认的新旧版本记录

不要只在工单里写“已更新”。为关键事实保留旧值、新值、适用范围、变更日期与责任来源。页面更换了模板，但业务事实没变，和真实产品条款发生变化，应分别记录。

例如，一份内部变更记录可以写成：产品 A 的交付范围从旧范围调整为新范围，仅适用于变更日起的新订单；旧合同按其约定执行。这样即使 AI 引用了旧合同，也能判断它是版本过时还是使用范围不同。

建议每条记录至少包含：

正文哈希可以帮助内部判断响应有没有变化，但它只证明字节版本。一次空格调整也会改变哈希，不能自动等同于业务事实发生实质更新。

Google 的日期文档建议在页面上清楚标注发布时间或更新时间，并保持可见日期与结构化日期一致。日期描述网页本身的发布和修改，不应拿文中事件的日期替代，也不应填写未来日期。

同一篇文章通常涉及四个位置：页面日期、Article 类结构化数据、Open Graph 的文章时间，以及 Sitemap 的 lastmod。它们可以只显示到不同精度，但不应互相矛盾。

历史迁移可能造成“修改时间早于发布时间”。应先修正数据来源；渲染层可以在有可靠首次发布时间时防止输出更早的修改信号，并记录这一修复。不能通过修改所有旧文章的发布时间来掩盖问题。

日期还要使用明确时区。UTC 的同一天，可能已经是中国或新加坡的次日。正文、列表与结构化输出使用不同的日期格式化环境，会制造看似“更新了一天”的错觉。

缓存有多个位置：应用、反向代理、CDN 和浏览器。页面在源站已更新，公开节点仍可能返回旧版本；也可能公开响应已是新版，而本机浏览器保留了历史页面。

HTTP 的缓存验证机制可以帮助识别版本。ETag 标识响应版本，条件请求可以获得 304 或新版响应；no-cache 的含义是复用前需要验证，不等于禁止存储。具体站点仍应检查实际返回的头与正文，而非仅检查配置文件。

可以保留一次正常 GET 的结果：

curl --noproxy '*' --connect-timeout 10 --max-time 20 \
  -sS -D headers.txt -o article.html https://example.com/articles/topic

然后检查 Cache-Control、Age、ETag、Last-Modified，以及正文是否真的包含新版本事实。某些响应没有全部这些头，并不自动意味着内容过期；关键是能否通过实际响应和服务配置说明版本。

对比公开域名与受控源站时，应保持目标路径和主机语义一致。不要把本机预览环境的新版，当成生产公开节点已经更新。

正文改了，RSS 摘要、列表卡片和 llms.txt 仍使用另一份文本，抓取方就可能从不同入口拿到互相冲突的信息。建议让它们读取同一内容记录，并在发布后逐项检查。

RSS 还要特别检查排序。置顶是编辑选择，近期发布是时间顺序。如果先按置顶取前 50 篇，再把结果当成“最新 50 篇”，新文章可能在查询时就被丢掉。正确做法是按真实发布时间选择近期条目，保留原始发布日期，频道更新时间再反映其中的真实修改。

Sitemap 的 lastmod 也应随重要内容变化更新。改一个版权年份或每天重建网站，不等于每篇文章都发生了重要修改。把全部时间刷新为今天，会削弱这项信号的可核验性。

不要把搜索结果里的一句旧摘要视为完整索引快照。也不要因为一个 AI 在回答里写“根据最新信息”，就认定它已经访问新版网页。真正有用的是来源 URL、时间和所引用的具体事实。

对于历史上确实生效过的旧条款，说明其有效期通常比直接删除更有助于核验。对于事实错误，应明确修正，并按修订政策保留必要的更正说明。

完成前四步，可以报告“公开内容与发现入口已更新”。后两步仍需要各自的观察结果，不能把通知成功写成“所有 AI 已同步”。

日期应该反映真实变化。本文没有证据支持通过每天刷新日期获得稳定引用增益。先把重要事实、版本与来源说明清楚，再用有对照的观察检验内容变化。

没有适用于所有页面与平台的固定天数。先确认新版已公开交付，再依据实际抓取频率和业务风险预设复核窗口；到了窗口仍不能观察时，应保留“未知”。