索引里的舊版本從哪来
把标题和正文改完，隔天在搜尋结果里看到的還是老样子。這種情况通常不是被降權，而是索引更新的鏈路還没走完。整條鏈路大致是：线上服務器返回新 HTML、搜尋蜘蛛重新抓取、内容進入索引並重新评估、结果頁展示更新。任何一环卡住，你看到的就還是舊版本。
常见卡点有几類：頁面没被重新抓取；抓到了但抓的是缓存里的舊 HTML；頁面存在多個版本，索引選了另一個；改動幅度太小，被判断為没有實质變化。
第一步：確認线上返回的确實是新版本
- 用無痕窗口或命令行直接請求该 URL，看源碼里是不是新标题、新正文。
- 如果源碼還是舊的，問题多半在缓存：CDN、反向代理、頁面缓存插件、對象存储都可能把舊版本留住。
- 检查响應头里的缓存相關字段，確認 HTML 本身没有被長時間缓存。
- 如果正文由前端异步加载，還要看渲染後的 DOM 有没有更新，而不只是初始源碼。
這一步没做，後面的排查都容易白費力气。
第二步：看日誌里有没有重新抓取
- 按 URL 過滤服務器日誌，找搜尋蜘蛛最近的訪問時間與狀態碼。
- 如果最近一次抓取還在改版之前，說明它還没回来，重点應放在让頁面變化被感知。
- 如果抓取了却返回 5xx、超时或 403，先修可用性問题。
- 如果抓取频繁但内容始终是舊的，回到第一步查缓存和渲染。
第三步：把“頁面變了”這件事说清楚
- 站点地图：把 lastmod 更新為真實的修改時間，而不是每次生成都寫成当天。長期失真的時間戳會被忽略。
- 内鏈：让首頁、栏目頁、相關文章指向這個 URL。發現路径越短，蜘蛛回来的間隔通常越短。
- 實质改動：只改一個标点、換一張图，一般不足以触發重新评估；补充資料、案例、结构調整，才算内容更新。
- URL 保持稳定：内容更新不需要換地址，換地址反而會把已有的歷史信号打断。
為什么有的頁面更新得快，有的很慢
刷新速度取决于抓取频率和頁面在站点中的位置。被频繁訪問、内鏈多、更新有規律的頁面，重新訪問的間隔更短；藏在分頁和篩選路径深處的頁面，可能几天甚至更久才被重新訪問一次。這属于正常差异，不必因為一天的滞後就大動干戈。
不建议用的几種做法
- 反复提交同一個 URL，短時間内多次手動請求抓取。偶尔一次可以，当成日常操作意义不大。
- 為了让新版本出現而临时加 noindex，等收錄後再撤掉，容易造成索引狀態反复。
- 改版时顺手換 URL 结构，把“内容更新”和“地址迁移”混在一起，排查會變得非常困难。
一個简單的自查顺序
- 线上返回的 HTML 是否為新版本，含缓存與渲染检查。
- 日誌里最近一次抓取的時間與狀態碼。
- 站点地图 lastmod 是否真實，该 URL 是否仍在站点地图中。
- 頁面是否存在多個地址，規范版本指向哪一個。
- 内鏈是否仍然指向该 URL。
- 改動幅度是否足以被判定為内容更新。
索引更新有滞後是常態。把线上内容、可抓取性和更新信号這三件事做對，剩下的交给時間，通常比反复手動提交更有效。