页面文案已经改过好几轮，搜索结果里的摘要却还停在上一版；标题、价格、库存也对不上。这类情况常被笼统地称为“没更新”，但它涉及的环节并不止一个：搜索引擎有没有重新来抓、抓到的版本有没有替换掉旧索引、中间缓存有没有把旧 HTML 递出去。先确认卡在哪一环，再决定要不要动手。
三个容易被混在一起的“旧”
看到旧内容时，第一反应往往是“搜索引擎没更新”，但实际上至少有三层可能：
- 抓取时间旧：搜索引擎最后一次访问这个地址可能是几周前，它看到的确实是当时的旧内容。
- 索引记录旧：新版本已经抓到，但索引库里的那条记录还没被替换，展示仍是旧摘要。
- 返回内容本身就是旧：页面、CDN、反向代理或内部缓存返回给爬虫的 HTML 就是上一版，抓多少次都一样。
第三种最容易被忽略，因为你在浏览器里刷新看到的是新版，而爬虫拿到的可能是另一份。排查时要把“你看到什么”和“爬虫看到什么”分开。
按顺序核对
- 确认服务端返回的 HTML。用不带登录态、绕开浏览器缓存的请求查看，并直接看网页源代码，确认新内容在首屏 HTML 里就已经存在，而不是靠脚本后补。
- 检查 CDN 与反向代理的缓存规则。HTML 是否被设置了较长缓存时间、更新后有没有主动刷新，响应头里的缓存命中信息可以作为参考。
- 排除“缓存给爬虫单独返回旧版”的情况。可以对比同一地址在不同来源下返回的内容是否一致。
- 看服务器日志里的抓取记录。内容更新之后有没有新的抓取请求？如果完全没有，问题不在索引，而在抓取路径：内链、栏目入口、站点地图是否还指向这个地址。
- 确认搜索引擎渲染后看到的内容。依赖脚本渲染的页面，要检查渲染完成后的 HTML 是不是新版，而不只是初始 HTML。
- 抓取已经是新版、索引仍是旧版时，看是否被合并。如果该地址被规范到另一个 URL，或与站内其他页面高度重复，索引可能不再单独维护它的内容。
- 最后才是重新提交。只对确实重要、且已确认服务端内容无误的页面做，避免整站批量操作。
哪些页面刷新得更快
- 被内链反复指向、本身有稳定抓取频率的页面，重新被抓的概率更高。
- 正文、标题、结构化数据同时发生变化，比只改一个数字更容易被识别为一次实质更新。
- 长期不更新、缺少入口、权重偏低的页面，刷新节奏自然更慢，这属于正常现象。
几个常见的坑
- 只改了脚本里的变量，HTML 里呈现的内容没变，抓取到的仍是旧版本。
- 页面本身被 robots 规则屏蔽或标了 noindex，却一直在改内容——抓不到，也就谈不上刷新。
- 用参数区分新旧版本，结果两个地址各自被收录，用户和爬虫看到的不是同一条记录。
- 更新之后没有任何内链或站点地图层面的提示，完全依赖自然重抓。
索引刷新不是即时动作，通常以天到周为单位。反复请求重抓对整站帮助有限，把精力放在稳定更新、可抓取的入口和正确的返回内容上更实际。
如果只是个别页面滞后，按上面的顺序逐项核对基本能定位；如果整站长时间都是旧内容，问题多半出在抓取频率、内链结构或缓存策略上，而不是某一个页面没提交。