改動頁面内容之後，搜尋结果里的标题、摘要或正文片段還是老样子，這種情况很常见。它不一定說明新内容有問题，也不一定說明搜尋引擎“没看见”。更常见的原因是：抓取、解析、入库、索引刷新這几步並不是同时完成的，中間還夹着若干缓存层。下面给出一套從日誌到生效的核對顺序，帮助判断到底卡在哪一层。
先明确一件事：抓取和索引更新是两回事
蜘蛛重新訪問只是第一步。它把新版 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 與内鏈指向同一地址。
- 留出观察窗口，按周對比，避免一天内多次改動打乱判断。
把這四层分開看，绝大多數“索引還是舊版本”的情况都能落到具体一层：要么還没抓，要么抓了舊内容，要么更新信号不清晰，要么只是還没轮到刷新。定位清楚之後再動手，比反复提交和反复改标题有效得多。