改版、換域名、調整目錄结构，頁面内容可能一個字都没改，但 URL 變了。這时候最容易被忽略的不是新頁面能不能被抓到，而是舊 URL 在索引里還留多久、新 URL 有没有顺利接上。下面按顺序梳理自查動作。

先分清三種“舊”

• 舊 URL 已经 404 或跳轉，但索引里還有记錄，属于待清理的残留。
• 舊 URL 和新 URL 都在，内容一样，属于重复，需要收口。
• 新 URL 已经能被抓到，但索引還没替換過来，属于迁移延迟，多數情况下只需观察。

三類問题的處理動作不同：第一類要推動移除，第二類要做規范收口，第三類基本不用干预。不先分類就動手，很容易把正常的延迟当成故障来處理。

第一步：把新舊 URL 對上号

做一張映射表，至少包含舊 URL、新 URL、跳轉類型三列。資料来源可以是服務器日誌、舊站的 sitemap、以及站内連結的導出结果。映射表不要求百分之百覆盖，但覆盖比例越低，後面的判断越不可靠——因為你會分不清“索引没更新”和“根本没人告诉搜尋引擎该去哪”。

第二步：確認跳轉本身是干净的

常见的問题是跳轉鏈條太長，或者跳到了不相關頁面。检查要点：

• 舊 URL 最好一次跳到最终的新 URL，不要 A→B→C 层层轉。
• 跳轉目标頁面要和原頁面對應，不要整站跳到首頁。
• 跳轉返回的狀態碼要正确，避免用临时跳轉表達永久變更。

跳轉本身是给搜尋引擎指路，路指得含糊，索引迁移就會拖。

第三步：区分“被移除”和“被替換”

很多人預設舊 URL 會自動消失，其實舊记錄和新记錄在一段時間内是並存的。要主動区分两種情况：如果舊頁面确實不再需要，就用規范的移除方式提交；如果只是換了地址，重点是让新 URL 承担原来的角色，同时通過 canonical 或跳轉表明两者關系。

這里有個判断依據：在搜尋结果里看到的是舊 URL 還是新 URL。如果長期只出現舊 URL，說明替換信号不够明确；如果两個都出現，說明收口還没做完。

第四步：给观察定一個窗口

迁移期的波動是常態，但如果没定窗口，就會陷入天天查、天天改的循环。建议按頁面類型分別设窗口：栏目頁、詳情頁、聚合頁的更新节奏本来就不一样，用同一套标准衡量只會自找麻烦。窗口内只记錄不改動，窗口後再根據趋势决定是否干预。

几個容易踩的坑

• 舊站没有保留跳轉，直接下线，導致大量舊連結無路可走。
• 新舊 URL 同时可訪問且内容一致，又没有規范标注，形成站内重复。
• 改版时顺手改了頁面标题和正文结构，把“地址變更”和“内容變更”混在一起，出問题时说不清是哪一項導致的。
• 只盯着首頁和几個大栏目，長尾頁面的映射根本没做。

改版後的收錄問题，多數不是“搜不到”，而是“该消失的没消失、该接上的没接上”。先做映射，再谈優化。

把上面四步走完，你會得到一張清晰的迁移狀態清單：哪些舊 URL 還在、哪些新 URL 已接上、哪些属于正常延迟。剩下的事情，交给時間和持續观察就好。