改动页面内容之后，搜索结果里的标题、摘要或正文片段还是老样子，这种情况很常见。它不一定说明新内容有问题，也不一定说明搜索引擎“没看见”。更常见的原因是：抓取、解析、入库、索引刷新这几步并不是同时完成的，中间还夹着若干缓存层。下面给出一套从日志到生效的核对顺序，帮助判断到底卡在哪一层。
先明确一件事：抓取和索引更新是两回事
蜘蛛重新访问只是第一步。它把新版 HTML 取回去之后，还需要经过解析、去重比对、质量判断，才会决定要不要替换索引里已经存在的旧版本。任何一步延迟，你在搜索结果里看到的就还是旧内容。
看到旧快照时，先不要急着反复改标题，先确认新版到底有没有被抓走。
第一层：这次访问抓到了什么
先从服务器日志入手，而不是从工具面板入手。日志能告诉你最原始的事实。
- 最近的抓取时间，是否晚于你改动的时间；
- 返回状态码是 200 还是 304；
- 返回字节数与页面实际大小是否吻合；
- 抓取频率、抓取来源是否正常。
如果日志里最近一次抓取发生在改动之前，那问题就停在这一层：还没重新抓，谈不上索引更新。
第二层：抓走的 HTML 是新版吗
这一层最容易被忽略。源站文件已经更新，但 CDN、反向代理、页面缓存插件、对象存储都可能继续吐旧内容。蜘蛛拿到的就是缓存副本，自然无法生成新版本索引。
- 用命令行或抓取工具模拟蜘蛛 UA 请求，对比返回的原始 HTML；
- 查看响应头里的缓存字段，例如是否有命中缓存的标记；
- 如果正文由前端脚本渲染，确认渲染完成后的 DOM，而不只是原始 HTML；
- 检查是否存在把 HTML 长时间缓存的规则，以及缓存刷新记录。
验证方式是直接的：改动里加一个不会影响阅读的独特词，然后看蜘蛛取回的 HTML 里有没有这个词。有，说明抓的是新版；没有，问题就在缓存。
第三层：更新信号是否清晰
lastmod 与 Last-Modified
sitemap 的 lastmod、HTTP 的 Last-Modified、ETag 都是参考信息，不是命令。它们只在和实际内容变化一致时才有价值。每次都把 lastmod 刷成当天日期，短期或许能增加抓取，长期会让这个信号失去参考意义。
改动幅度与位置
改一个错别字和重写整段内容，被判定为“值得更新”的概率并不一样。改动集中在正文主体、主标题、结构化数据时，更容易被识别为新版本；只动页脚、广告位或模板区域，通常不会触发索引重算。
版本冲突
如果同一内容存在多个 URL 版本，而 canonical、内链、sitemap 各自指向不同版本，新版本可能被算到另一个 URL 上。此时你盯着 A 页面看，变化却发生在 B 页面。
第四层：索引刷新本身需要时间
索引不是数据库里的一行更新。很多页面会分批重算，更新频繁、抓取预算充足的站点通常更快，其余站点则需要更长的观察窗口。这段时间内新旧版本并存是正常现象，不必立刻判定为问题。
常见误区
- 反复提交同一个 URL：提交是提示入口，不等于立刻重新抓取；
- 频繁改标题试探效果：版本反复跳变反而让判断变乱；
- 用假 lastmod 刷 sitemap：短期可能换来抓取，长期损耗可信度；
- 只看工具里的“已收录”标记：它反映索引库状态，不反映快照里的正文版本。
一份可执行的核对清单
- 在服务器日志确认最近一次抓取时间，与改动时间做对比。
- 模拟蜘蛛请求，确认拿到的是新版 HTML，而不是缓存副本。
- 检查 CDN、反向代理、页面缓存插件的 HTML 缓存策略与刷新记录。
- 确认 lastmod、Last-Modified、ETag 与实际改动保持一致。
- 确认改动落在正文主体，而不是模板或页脚区域。
- 确认同一内容没有多个 URL 互相争抢版本，canonical 与内链指向同一地址。
- 留出观察窗口，按周对比，避免一天内多次改动打乱判断。
把这四层分开看，绝大多数“索引还是旧版本”的情况都能落到具体一层：要么还没抓，要么抓了旧内容，要么更新信号不清晰，要么只是还没轮到刷新。定位清楚之后再动手，比反复提交和反复改标题有效得多。