运营中很常见的一幕：页面标题、价格、活动时间已经改了，搜索结果显示的还是两周前那一版。很多人第一反应是“是不是没收录”，于是反复提交 URL 或者反复查 site: 结果。其实更可能的情况是：页面确实在索引里，只是索引中保存的那份快照还没被替换。
把“收录”和“更新”当成两件事来看，排查思路会清楚很多。
索引里存的是抓取时的快照，不是你的实时页面
搜索引擎展示的标题、描述和摘要，来自它上一次成功抓取并处理这份 URL 时保存的内容。整个链条大致是：调度抓取 → 取回 HTML → 渲染 → 抽取正文与关键信息 → 写入索引。任何一环慢下来，你看到的就是旧版本。
还有一点容易被忽略：展示的标题和描述不一定完全照搬你写的那段。搜索引擎会参考页面标题、正文首段、外链锚文本等信号自己生成一段摘要。所以展示文字和你改的内容不一致，有时不是没更新，而是它本来就没打算照抄。
更新生效慢的常见原因
- 抓取频率本身就低。访问量少、内链少、站点整体权重不高的 URL，重新被抓取的间隔本来就更长。
- 下次抓取是由调度决定的。你改了内容，但没有任何机制主动告诉它“这里变了”，只能等下一轮。
- CDN 或页面缓存返回了旧内容。蜘蛛拿到的 HTML 是缓存里的旧版，它自然只能记下旧版。
- 更新后的内容依赖 JS 渲染。渲染要排队，更新会比静态内容更慢一步。
- 旧 URL 仍然可访问。改版后新的 URL 已经上线，旧地址还返回 200，两个版本可能同时存在于索引里，你看到的可能恰好是旧的那个。
先自查：到底是没更新，还是看错了页面
- 用 URL 检查类工具看这个 URL 的最近一次抓取时间。如果时间就在改动之前，那说明只是还没轮到。
- 看抓取时的页面快照，和线上实际内容对比。很多“没更新”在这一步就能确认原因。
- 用命令行直接请求源站，带上缓存相关头部，看返回的是不是新内容，以及 Age、ETag、Last-Modified 这些字段是否显示命中缓存。
- 确认是否存在多版本：新旧 URL、带参数版本、移动端版本分别打开看看。
- 确认改动落在搜索引擎真正读取的区域，而不是被折叠、被懒加载挡住的部分。
推动更新，可以按这个顺序做
- 先保证源站返回的就是新内容，并刷新 CDN 缓存。这一步没做，后面的操作都是白费。
- 把入口重新接上。在列表页、导航、相关推荐里更新指向该页的链接，让爬虫从高频访问的页面重新走到它。
- 更新 sitemap 中的 lastmod，但只写真实修改时间。长期乱写会让这个字段失去参考价值。
- 对少数关键页面主动提交抓取请求，注意额度有限，优先给真正重要的 URL。
- 修改幅度小、只改几个字的页面，不必投入太多精力。改动越大、页面越重要，被重新处理的优先级通常越高。
如果只是担心标题描述被改写，可以先观察一段时间。搜索结果的展示文案本来就允许被生成和调整，它和页面的收录状态、排名表现是两回事。
小结
页面改了但索引还是旧版，多数时候不是收录出了问题，而是快照替换需要一轮新的抓取。先确认线上内容、缓存、多版本这三件事，再看抓取时间和入口链接，基本能把原因定位到具体环节。真正需要长期投入的，是让重要页面持续有访问、有内链、有明确的更新时间，而不是每次改动后反复刷新搜索结果页面。