改完标题、換過正文、調整了價格，過几天去搜尋里看，快照還是老样子。這種情况和“没被收錄”不是一回事：頁面在索引里，只是停留在舊版本，處理思路也完全不同。
先確認頁面到底有没有被重新抓取
索引里的内容要更新，通常要经過两步：蜘蛛先重新抓取頁面，搜尋引擎再根據新版本决定是否替換索引。两步之間可能隔几天，也可能更久，尤其是更新不频繁的頁面。
- 如果日誌里能看到蜘蛛在你改動之後訪問過该 URL，說明“抓取”這一步已经完成，問题多半在索引更新环节。
- 如果改動之後蜘蛛一次都没来，那就不是更新延迟，而是抓取频次或入口的問题，先去看内鏈、站点地图和整体抓取情况。
- 查日誌要带時間，不要只看訪問總量，要看你改動的那几個 URL 有没有被單獨訪問過。
更新延迟常见的几個来源
抓取频次本来就不高
權重一般、很少更新的頁面，蜘蛛回訪間隔本来就長。你改了一次内容，不會立刻把回訪频率拉起来。如果頁面長期没什么變化，間隔几周再来看也很正常。
内容變更信号太弱
服務器返回 304，或者没有正确给出 Last-Modified、ETag 时，搜尋引擎可能據此判断頁面没有變化，直接沿用舊缓存。
- 检查响應头是否带 Last-Modified 或 ETag，並且随内容變化而變化。
- 有些缓存层會把這两個字段固定成同一個值，反而让蜘蛛認為“没改過”。
中間還隔着一层缓存
CDN、反向代理、頁面缓存插件都可能返回舊版本。蜘蛛抓到的就是你缓存上的舊内容，索引自然停在舊版本上。
- 分別請求源站和 CDN 地址，對比正文和响應头是否一致。
- 改版後主動刷新相關缓存，不要干等過期時間。
站点地图里的 lastmod 没跟着改
sitemap 中的 lastmod 長期不動，或者所有頁面都是同一個時間，這個字段的參考價值就會變弱。更新了内容，顺手更新對應 URL 的 lastmod，不要整站刷成同一时刻。
一段可执行的排查顺序
- 记錄改動時間和改動的 URL 清單。
- 查日誌，看這些 URL 在改動之後有没有被抓取，抓取時間、UA 和返回狀態分別是什么。
- 對比源站與 CDN 返回的正文和响應头，確認蜘蛛拿到的是新版本。
- 核對 sitemap 的 lastmod 是否與改動時間一致。
- 過一段時間再抽样复查，只看同一批 URL，不要用全站收錄數字概括。
哪些做法有用，哪些基本没用
- 有用：给重要頁面稳定的内鏈入口，让内容确實有實质變化，让缓存和响應头如實反映更新。
- 作用有限：频繁提交 URL，但内容只是換几個词；或者每天微調一次，反而让“變化”這個信号失去意义。
- 別指望：小幅改動立刻反映到索引里。索引更新本身就有滞後，不随提交動作同步發生。
索引更新更像一次重新评估，而不是同步刷新。被抓取到了，只是拿到了更新的机會。
什么时候不用繼續等
如果改動幅度很大，頁面结构都變了，比如換了模板、調整了 URL、合並了多個頁面，與其等舊地址更新，不如让新 URL 承载内容，把老地址做規范的重定向，让新舊信号干净交接。反過来，如果只是标题微調，等一两周再看通常更省事。
判断這類問题的核心，是把“抓取”和“索引更新”分開看。日誌能告诉你蜘蛛有没有来，源站與 CDN 的對比能告诉你蜘蛛拿到了什么，剩下的時間，是索引自己的节奏。