站点調整 URL 结构、合並栏目或更換域名时，一般都會给老地址做 301。做完之後常常會遇到一件事：索引里老地址仍然存在，有的還繼續出現在搜尋结果里。這时候容易有两種反應，一是反复提交新地址，二是干脆把老地址的跳轉删掉。两者都不太稳妥。更值得做的，是按跳轉類型、跳轉执行情况、索引現状、内鏈與入口這几條线依次核對。
先確認跳的是哪一種
同样是“跳轉”，浏览器里的观感差不多，但搜尋端收到的信号差別很大：
- 301 永久跳轉：最常见的迁移信号，用于结构永久調整。
- 302、307 临时跳轉：本来用于临时场景。如果長期挂着，搜尋端可能繼續保留老地址，甚至反复抓取老地址。
- meta refresh 與 JS 跳轉：服務端返回的仍是 200，只是頁面里寫着跳轉。這種地址本身會被当成正常頁面處理。
- 跳轉鏈：A 跳到 B，B 又跳到 C。鏈條越長，抓取端越容易中途停下。
把這几種和自己的實际情况對一遍，很多“看起来没生效”的問题，其實是類型用错了，或者压根没走服務端跳轉。
检查跳轉是否真的發生在服務端
用不带 JS、不带 Cookie 的方式直接請求老地址，看返回的狀態碼和响應头。核對要点大致是：
- 狀態碼是不是 301 或 308，而不是先返回 200 再靠前端跳。
- Location 指向的是不是最终地址，而不是鏈條中的下一跳。
- 最终地址本身是不是 200。有些鏈條最後落在一個 404 或空頁面上。
- 跳轉是否對搜尋端和普通訪客返回一致。有些站点會按 UA 区分，這容易造成两邊看到的不是同一個東西。
如果老地址返回 200，只是頁面里在跳，那它在搜尋端就是一個獨立頁面，被收錄是正常结果，不能算“没生效”。這類頁面要么改成服務端跳轉，要么按普通頁面决定留還是收。
索引里老地址還在，先別急着下判断
做了跳轉不等于索引立刻更新。老地址在一段時間内繼續出現在索引和搜尋结果里，本身是可以理解的。真正需要区分的是下面三種情况：
- 老地址被收錄，但点開跳到了新地址。這類通常會逐步被替換。
- 老地址被收錄，点開仍是老内容。說明服務端跳轉没生效，或者中間存在缓存。
- 新地址還没被收錄，老地址仍在顶替展示。這时重点不在老地址，而在新地址本身。
對第二種，先回到上一步检查响應；對第三種，重点是把新地址的入口、導航和内容理顺，而不是反复去動老地址。
内鏈、外鏈和 sitemap 里還指向老地址
跳轉只是兜底，不是入口。真正影响抓取優先級的，是站内還往哪里指。常见的遗漏有：
- 導航、面包屑、侧栏里仍寫着老地址。
- 正文里的歷史内鏈没有同步更新。
- sitemap 里同时列着老地址和新地址。
- 老地址的 canonical 指向自己，或者干脆没寫，而新地址的 canonical 又反過来指向老地址。
這几處對齐之後，搜尋端收到的信号才是“大家都指向新地址”。canonical 寫反是很常见的一處，值得單獨看一眼。另外，老地址如果還有外鏈進来，不必急着彻底断開，保留一個轻量的 301 通常比直接 404 更平稳。
什么时候可以考虑停掉跳轉
並没有统一的時間表。可以先看两個信号：老地址在服務端日誌里的請求量是否已经降到很低，以及搜尋结果里是否基本被新地址替代。即便到了這一步，保留一個 301 的成本通常也很低，除非有明确的业務原因必须刪除。
把跳轉当成過渡手段，把入口和内容当成長期手段。前者處理歷史，後者决定新地址能不能被稳定發現。
整体顺序可以记成：先看跳轉類型，再看服務端响應，然後按索引現状分類，最後回到内鏈與 sitemap 收口。每一步只解决一個問题，避免一上来就删跳轉、改 canonical 或者反复提交。