頁面内容改完了，标题也換了，過几天在搜尋结果里看到的還是老版本，甚至摘要、快照都是舊的。這種情况很容易被理解成“收錄掉了”或“更新没被接受”，但多數时候只是索引替換還没走到最後一步。要判断問题出在哪，先把“舊”拆成几個不同层面来看。
一、搜尋结果里的“舊”，可能是三種不同的舊
同一個現象，背後對應的處理阶段完全不同。
- 抓取层面的舊：蜘蛛上次来的时候頁面還是老内容，之後還没再訪問。這时搜尋引擎手里根本没有新版本。
- 渲染层面的舊：蜘蛛抓到了 HTML，但頁面主体内容靠 JavaScript 生成，渲染队列還没處理到，或者渲染结果與预期不同。
- 展示层面的舊：索引里其實已经換成新内容，但搜尋结果為了稳定，短時間内仍可能展示舊摘要或舊标题。
先确定自己遇到的是哪一種，再選對應的處理方式，否則容易做一堆無用功。
二、蜘蛛為什么不急着回来
搜尋引擎决定何时重抓一個 URL，參考的因素比多數人想的多。
- 頁面自身的變化频率。歷史上经常更新的頁面，重抓間隔會缩短；長期不變的頁面，間隔會拉長。突然改一次，未必能立刻触發重抓。
- 站点的整体抓取額度。額度被大量低價值 URL 占着时，重要頁面的重抓排队就會往後排。
- 頁面在站内的位置。有稳定内鏈入口、点击量大的頁面，被發現得更快；深层頁面只能等下一轮爬行。
- 更新幅度。改几個错別字和重寫大部分正文，在變化檢測上的分量並不一样。
所以更新之後没動静，不代表更新没價值，也可能只是還没轮到。
三、主動让更新被發現
能做的是把信号给到位，而不是反复催。
- 让 sitemap 的 lastmod 说真话。只在内容有實质變化时更新這個時間，長期虚报會让它失去參考價值。
- 保留稳定的内鏈入口。頁面如果從導航或列表里被移走，發現速度會明顯下降。
- 用官方的提交入口提示個別重要 URL。适合少量重点頁面，不适合当成批量刷新的手段。
- 避免無意义的频繁改動。每隔几小时微調一次，既不會加快重抓，還可能让變化信号變模糊。
- URL 保持稳定。一改版就換地址、換參數，等于把歷史积累清零重来。
四、怎么確認索引到底更新了没有
判断时不要只看一個入口。
- 用頁面里獨有的、新加的一句话去搜尋，看结果摘要是否包含。
- 用官方的 URL 检查類工具看目前索引版本，注意它反映的是最近一次抓取的结果。
- 翻服務器日誌，看蜘蛛最近一次訪問的時間和返回狀態。
- 给判断留出時間窗口，分两三次观察，而不是看一次就下结论。
结果頁的展示本身就是滞後的，几天延迟属于正常范围，不必按小时去追。
五、几個常见誤判
- 把缓存当未收錄。缓存頁面或展示摘要落後，和“頁面不在索引里”是两件事。
- 把另一個 URL 的舊版本当成本頁未更新。带參數的舊地址、http 與 https、带與不带 www，都可能各自留着一份记錄。
- 以為改了 title 就该马上生效。标题是搜尋引擎综合判断後展示的，改動後需要重新抓取與评估。
- 為了“刷新”而大改没問题的内容。可能反而影响這個頁面已有的稳定表現。
六、實际處理顺序
比較稳妥的做法是：先確認日誌里蜘蛛有没有来過、拿到的狀態碼是什么；再看渲染後頁面主体是否正常輸出新内容；然後检查 sitemap 與内鏈是否還有效；最後再考虑是否需要主動提交。每一步都排除了，剩下的通常只是時間問题。
如果長期停在舊版本，而站内其他頁面更新都正常，就该回头看這個頁面本身：是不是 URL 被改過、是不是被別的地址替代、是不是主体内容依赖渲染而渲染失敗。這類問题不解决，等再久也不會自動更新。