頁面内容已经改完，搜尋结果里却還是舊标题、舊摘要，甚至点進去快照内容也不對。這種情况常被理解成“被惩罚”或“没收錄”，但多數时候只是索引更新的节奏問题：抓取、處理、刷新展示是几步不同的動作，任何一步没走完，看到的都可能是舊版本。
先分清：重新抓取和重新收錄不是同一件事
搜尋引擎發現 URL 變化後，會先安排抓取。抓取回来之後，還要经過内容解析、去重、质量判断、索引合並等處理，最後才可能替換掉舊版本。也就是说，蜘蛛来過，不等于索引已经刷新；日誌里出現 200，也不代表新内容已经進入线上结果。
如果你只盯着“有没有来抓”，很容易誤判。更合理的观察是：抓取時間、返回内容、索引里的版本，三者是否一致。
頁面改完，索引還顯示舊版本，常见卡点
1. 重新抓取還没排上
頁面權重、更新频率、站内連結位置都會影响再次抓取的優先級。一個很少被連結、流量也低的頁面，即使内容改了，也可能要等較久才被重新訪問。此时搜尋结果的舊版本，只是因為它還没被重新讀取。
2. 抓到了，但返回的還是舊内容
這種情况常出現在 CDN、反向代理、頁面缓存或服務端模板缓存上。蜘蛛請求时拿到的是缓存副本，自然無法看到新内容。自查时可以看服務器日誌里返回的响應体大小、Last-Modified、ETag 是否已经變化，或用抓取工具模拟請求，確認實际返回的是哪一版。
3. 多個 URL 在竞争同一内容
如果带參數版本、舊目錄版本、打印版、AMP 版同时存在，且 canonical 指向不一致，搜尋引擎可能仍把舊 URL 当作主版本。你改的是 A 版，索引里保留的却是 B 版，搜尋结果自然顯示舊内容。
4. 内容靠前端渲染，索引里拿到的是空壳
如果正文、标题、摘要依赖 JavaScript 在客戶端生成，而抓取时没有完整执行或执行超时，索引里可能只记錄了初始 HTML。此时頁面看起来改了，但搜尋引擎看到的内容並没有同步更新。
5. 更新幅度太小，系統判断不值得替換
只改几個标点、調整一句無關痛痒的话，搜尋引擎可能認為頁面没有實质變化，繼續沿用舊索引。标题、摘要、主体信息有實质調整时，被重新處理的概率會更高。
一套可执行的自查顺序
- 確認线上實际返回：用未登入、無缓存的請求訪問 URL，查看 HTML 源碼里是不是新内容。不要只看浏览器里渲染後的样子。
- 检查缓存层：CDN、服務器缓存、頁面缓存插件是否已经刷新。必要时手動清理對應 URL 的缓存。
- 看 canonical 和 URL：確認目前頁面 canonical 指向自己，而不是舊地址、參數地址或其他重复版本。
- 看 robots 和 meta：確認没有誤加 noindex、nofollow，也没有在 robots.txt 里屏蔽了目前路径。
- 看 sitemap 和内部連結：sitemap 里的 URL 是否更新，lastmod 是否合理；站内是否有入口連結指向這個頁面，還是它已经變成孤岛。
- 再观察抓取和索引：在日誌或搜尋後台查看最近抓取時間，確認抓取後索引是否變化。不要刚改完就下结论。
几個容易忽略的细节
- 标题和摘要可能被重寫：即使索引已更新，搜尋引擎也可能根據查询词重新生成展示标题或摘要，這不等于舊内容没被替換。
- 不同地区、不同设备结果可能不同：移動端和桌面端、不同資料中心的缓存刷新节奏不完全一致。
- 被轉载或采集的頁面先更新：如果同一内容在別處更早被索引，搜尋时可能先看到那一版，需要回到自己站内確認主版本是否正常。
- 頁面结构改動比文字改動更敏感：調整 URL、模板、目錄结构时，索引迁移會比單纯改正文更慢，期間出現舊版本並不罕见。
什么时候该繼續等，什么时候该動手改
如果確認线上返回新内容、canonical 正常、没有被屏蔽，抓取也来過，通常可以再观察一段時間。索引刷新本来就不是實时操作。相反，如果线上返回舊缓存、canonical 指向別的 URL、或頁面被 noindex 挡住，那就不该等，先修正這些硬問题。
把“抓取、處理、展示”拆開看，很多“收錄没更新”的問题會清晰很多。记錄每次改動的時間点、抓取時間和索引版本，比反复提交 URL 更有助于判断真正卡在哪一步。