頁面文案已经改過好几轮，搜尋结果里的摘要却還停在上一版；标题、價格、库存也對不上。這類情况常被笼统地称為“没更新”，但它涉及的环节並不止一個：搜尋引擎有没有重新来抓、抓到的版本有没有替換掉舊索引、中間缓存有没有把舊 HTML 递出去。先確認卡在哪一环，再决定要不要動手。
三個容易被混在一起的“舊”
看到舊内容时，第一反應往往是“搜尋引擎没更新”，但實际上至少有三层可能：
- 抓取時間舊：搜尋引擎最後一次訪問這個地址可能是几周前，它看到的确實是当时的舊内容。
- 索引记錄舊：新版本已经抓到，但索引库里的那條记錄還没被替換，展示仍是舊摘要。
- 返回内容本身就是舊：頁面、CDN、反向代理或内部缓存返回给爬虫的 HTML 就是上一版，抓多少次都一样。
第三種最容易被忽略，因為你在浏览器里刷新看到的是新版，而爬虫拿到的可能是另一份。排查时要把“你看到什么”和“爬虫看到什么”分開。
按顺序核對
- 確認服務端返回的 HTML。用不带登入態、绕開浏览器缓存的請求查看，並直接看網頁源代碼，確認新内容在首屏 HTML 里就已经存在，而不是靠脚本後补。
- 检查 CDN 與反向代理的缓存規則。HTML 是否被設定了較長缓存時間、更新後有没有主動刷新，响應头里的缓存命中信息可以作為參考。
- 排除“缓存给爬虫單獨返回舊版”的情况。可以對比同一地址在不同来源下返回的内容是否一致。
- 看服務器日誌里的抓取记錄。内容更新之後有没有新的抓取請求？如果完全没有，問题不在索引，而在抓取路径：内鏈、栏目入口、站点地图是否還指向這個地址。
- 確認搜尋引擎渲染後看到的内容。依赖脚本渲染的頁面，要检查渲染完成後的 HTML 是不是新版，而不只是初始 HTML。
- 抓取已经是新版、索引仍是舊版时，看是否被合並。如果该地址被規范到另一個 URL，或與站内其他頁面高度重复，索引可能不再單獨维護它的内容。
- 最後才是重新提交。只對确實重要、且已確認服務端内容無誤的頁面做，避免整站批量操作。
哪些頁面刷新得更快
- 被内鏈反复指向、本身有稳定抓取频率的頁面，重新被抓的概率更高。
- 正文、标题、结构化資料同时發生變化，比只改一個數字更容易被识別為一次實质更新。
- 長期不更新、缺少入口、權重偏低的頁面，刷新节奏自然更慢，這属于正常現象。
几個常见的坑
- 只改了脚本里的變量，HTML 里呈現的内容没變，抓取到的仍是舊版本。
- 頁面本身被 robots 規則屏蔽或标了 noindex，却一直在改内容——抓不到，也就谈不上刷新。
- 用參數区分新舊版本，结果两個地址各自被收錄，用戶和爬虫看到的不是同一條记錄。
- 更新之後没有任何内鏈或站点地图层面的提示，完全依赖自然重抓。
索引刷新不是即时動作，通常以天到周為單位。反复請求重抓對整站帮助有限，把精力放在稳定更新、可抓取的入口和正确的返回内容上更實际。
如果只是個別頁面滞後，按上面的顺序逐項核對基本能定位；如果整站長時間都是舊内容，問题多半出在抓取频率、内鏈结构或缓存策略上，而不是某一個頁面没提交。