改完标题、补了正文，过一阵去搜索里查，结果还是旧的那一版：标题没换、摘要还是老句子，有时连正文都是修改前的。这种情况容易让人以为“没收录”，但更多时候页面其实在索引里，只是索引里的版本没有跟着更新。把“有没有收录”和“收录的是哪一版”分开看，核对顺序会清楚很多。

第一步：先确认差异出在哪一层

搜索结果的标题和摘要并不总是照搬页面。搜索引擎常会从正文里摘句子，或按查询词改写标题。所以先比对正文主体段落：如果摘要里的句子在现在的页面上仍能找到，只是标题被改写，那多半是展示层的正常调整，不是版本旧的问题。

真正需要核对的，是缓存快照的日期和正文主体。快照日期明显早于最后一次修改，并且被改掉的段落还完整出现在快照里，才说明索引里的版本没刷新。

第二步：核对最后一次抓取是否发生在改动之后

索引更新建立在重新抓取的基础上。改动之后的抓取如果还没发生，索引维持旧版本是正常现象，不算故障。顺序上先看日志或抓取统计里该 URL 最近一次抓取时间，再和内容修改时间对照：

• 抓取时间早于修改时间：等下一轮抓取即可，不必急着改动结构
• 抓取时间晚于修改时间，快照仍是旧的：进入下一步核查
• 抓取时间长期没有更新：检查内链、导航与 sitemap 是否还指向这个 URL

第三步：改动幅度与信号是否足够

小幅改动，比如改几个词、调一下标点，通常不足以触发重新抓取和索引刷新，这不是漏收，只是优先级问题。如果确实希望更新，改动要落在主体内容上，例如补充段落、更新数据、修正事实。

更实际的做法，是把改动同步到抓取端能读到的信号上：

• sitemap 里的 lastmod 是否同步更新（不要每次全站刷一遍时间）
• 页面结构化数据里的 dateModified 是否跟着变
• 指向该页的内部链接锚文本若已过时，是否一并改掉
• 页面在站内的位置和入口数量是否有变化

第四步：URL 与 canonical 有没有换过版本

如果改版过程中 URL 变过（加斜杠、改大小写、换目录），容易出现一个局面：旧 URL 在索引里保持旧内容，新 URL 刚被发现。这时先确认 canonical 指向的是想保留的那个版本，并且这个版本自身可以被抓取。canonical 指向的版本没被收录时，容易两个版本都不更新。

另外检查是否同时存在多个近似版本，比如带参数、http 与 https、有无 www 的说法。同一份内容被拆成多个地址，抓取力量被分散，旧版本留在索引里的时间往往更长。

一份可执行的核对顺序

1. 记录目标 URL、最后一次内容修改时间、日志里最后一次抓取时间
2. 打开搜索结果的缓存快照，比对正文主体，而不是只看标题
3. 检查 sitemap 的 lastmod 与 dateModified 是否同步
4. 检查 canonical、重定向与参数版本，确认只留一个主版本
5. 确认主版本在站内有正常内链入口，没有被 noindex 或 robots 拦住
6. 若以上都正常，用抓取工具请求一次该 URL，观察返回内容与状态码
7. 记录当前状态，隔一段固定周期再看一次，避免每天改动

抓取与收录是两件事：抓到了不等于入库，入库了也不等于版本会立刻跟着页面更新。把这几个环节分开记录，判断会稳得多。

结尾的几点提醒

不要因为一次快照没刷新就频繁改标题、改 URL、反复重新提交，这些动作反而会让索引里的版本更不稳定。除非页面确实有实质变化，否则先给一点观察时间。如果长期不更新，且入口、canonical 都没有问题，再考虑通过站点地图重新提交，或在站内新增一处合理入口，而不是反复改动页面本身。