頁面内容已经改過，過了一两周在搜尋结果里看到的還是舊标题、舊價格、舊联系方式。這種情况不一定是“没收錄”，更常见的是收錄已经存在，只是索引里儲存的那份内容還没被替換。要排查的是三件事：頁面對外返回的是不是新版本、爬虫有没有再来抓一次、索引有没有把新内容寫進去。顺序反過来查，容易白忙。
一、先確認服務器返回的确實是新版本
很多“索引没更新”其實頁面本身就没更新。後台点了發布，但前台讀的是缓存或静態文件，用戶看到的是新頁面還是舊頁面，取决于你從哪里看。
- 用無痕窗口打開目标 URL，查看網頁源代碼而不只看渲染後的效果，確認正文文本是否為新内容。
- 在 URL 後面加一個随机參數再訪問（例如 ?v=20240601 這類临时值），如果带參數是新内容、不带參數是舊内容，問题基本落在缓存层。
- 检查 CDN 命中狀態與响應头里的缓存時間，確認缓存是否按预期過期或被主動刷新。
- 確認發布流程里没有“多個版本並存”：模板缓存、静態化文件、多机房不同步，都會让不同节点返回不同内容。
這一步没排干净，後面所有的抓取和索引分析都建立在错誤的前提上。
二、爬虫有没有再来抓過這個 URL
打開服務器訪問日誌，按 URL 過滤，看最近一次爬虫訪問的時間。如果更新時間点之後完全没有新的抓取记錄，那問题在抓取侧；如果有抓取记錄且返回 200，那才轮到讨论索引刷新。
以下几類情况會明顯拖慢重新抓取：
- 頁面本身抓取频率低，尤其是深层頁面、更新频率低的老頁面。
- 服務器响應慢或間歇性 5xx，爬虫會主動降低對该目錄的訪問节奏。
- URL 带會话參數或不稳定參數，每次被抓到的都是“新地址”，歷史權重無法累积。
- 站点整体可抓取量被大量低價值 URL 占據，真正需要更新的頁面排队靠後。
這一步的结论很重要：没有抓取和抓取了但没換索引，後續動作完全不同。
三、更新信号有没有發對
sitemap 里的 lastmod
sitemap 中的 lastmod 應当反映内容實质變化的時間。長期不更新、或者每次全量刷新成目前時間，都會让這個字段失去參考價值。只改真正變過的 URL，比整份文件重寫更有意义。
頁面上的可见時間
正文里如果有“更新于”這類明确時間，並且與内容變化一致，比頁脚寫死一個版權年份要清晰。结构化資料中的日期字段也應與實际修改時間保持一致，不要出現頁面寫 A 時間、标记里寫 B 時間的情况。
内鏈與入口
從首頁、栏目頁或其他常被抓取的頁面，给被更新的 URL 一個正常的内鏈入口，比等爬虫自己想起来更實际。入口尽量用稳定地址，不要指向带一堆參數的版本。
四、改動幅度會影响判断结果
只改了頁脚年份、調了几個词序，多數情况下被判定為“未發生實质變化”，索引保留舊版本並不奇怪。标题、主体段落、價格、库存、联系方式這類核心信息發生變化，被重新處理的概率更高。
如果改動确實重要，可以顺带調整标题、首屏内容和内鏈锚文本，让頁面整体呈現出“這是一次真實更新”的狀態，而不是只改一個字。
五、URL 本身没有漂移
同一篇内容如果同时存在大小寫不同、末尾有無斜杠、http 與 https、带參數與不带參數等多個地址，更新很可能只發生在其中一個版本上，而索引里保留的是另一個。核對时確認：
- 頁面的規范地址唯一且自指向。
- 站内連結统一使用同一個版本，不要混用。
- 舊路径通過跳轉指向新路径，而不是让两個地址都返回 200。
六、观察與收尾
把上面几步過完之後，剩下的就是观察。重新抓取和索引刷新都需要時間，不同頁面差別很大，更新频繁、入口多的頁面通常更快。可以记錄每次修改時間、日誌里的抓取時間和搜尋结果中顯示的内容版本，用两三次對比就能摸清自己站点的节奏。
需要說明的是，以上都是提升可發現性和可判断性的做法，並不能保證某個頁面一定被重新抓取或索引一定刷新。搜尋引擎是否重新處理、何时處理，最终取决于其自身策略。把頁面、信号和入口做扎實，是站点侧能控制的部分。