為什么跳轉做了，收錄却没跟着更新
改版、換目錄、合並栏目之後，最常见的處理是把舊地址用 301 指向新地址。但不少人會發現：舊地址在搜尋结果里還在，新地址迟迟不出現。原因往往不在有没有做跳轉，而在跳轉鏈有多長、中間每一跳返回什么。
抓取端訪問一個地址时，遇到重定向需要再發起一次請求。跳一次可以接受，跳三次以上就要多花两三次抓取動作，中間任何一环出問题，鏈路就断了。所以核對顺序應该從鏈路本身開始，而不是先怀疑内容质量。
第一步：把跳轉鏈完整走一遍
用命令行或跳轉检查工具，從舊地址開始逐跳记錄：
- 一共跳了几次，每一跳的狀態碼是 301、302、307 還是 308；
- 最终落点返回的是不是 200，還是 404、410 或软 404；
- 落点是否是規范域、規范目錄，有没有被自動加上參數或跳回舊地址；
- 鏈路中是否出現循环，A 跳 B 再跳回 A 的情况要優先修。
如果鏈路超過两跳，建议把中間环节改成直接指向终点，能一步到位就不要串起来。鏈式跳轉不會因為歷史原因就更容易被接受。
第二步：区分 301、302 和前端跳轉
長期的地址交接，應该用 301（永久）或 308。302、307 表達的是临时跳轉，長期挂在那里，抓取端可能一直把舊地址当作有效地址保留。更要注意的是：
- 用 meta refresh 或 JavaScript 跳轉，抓取端不一定执行，容易只看到一個空頁面；
- 用 302 指向一個随时會變的目标，會让收錄归属變得不稳定；
- 把舊地址跳到登入頁、驗證頁或需要前端渲染的頁面，落点無法被正常解析。
判断标准很简單：關掉脚本、只看服務端返回，鏈路是否仍然完整可走通。
第三步：把站内入口一起改掉
跳轉只是给老連結兜底，不是让站内繼續指向舊地址的理由。如果導航、面包屑、正文内鏈、列表頁仍然大量指向舊地址，抓取端會持續發現舊 URL，收錄归属就會一直在两個地址之間摇摆。
核對时按入口優先級排一遍：導航和首頁入口、栏目頁與列表頁、正文互鏈、sitemap。這些位置都應该直接寫成最终地址，跳轉只留给外部連結和收藏夹里的老連結。
第四步：確認落点頁面的自我声明
跳轉的终点頁面本身也要干净：
- 頁面的 canonical 指向自己，而不是指向舊地址或另一個變体；
- 落点不要带上来源地址残留的參數，避免同内容生成多個 URL；
- 落点頁能被正常抓取，没有 robots 屏蔽、没有被 noindex 覆盖；
- 落点頁的内容與原頁主题一致，否則容易被判為無關跳轉。
观察节奏與常见坑
改完之後不需要天天看结果。更實际的观察方式是看服務器日誌里舊地址的請求狀態碼分布，以及這些請求是否已经逐步轉向新地址。短時間内舊地址仍有訪問是正常的，因為外鏈、缓存和用戶收藏不會同步更新。
几個反复出現的坑：
- 把整站舊目錄 301 到一個總入口，用戶和抓取都被送到不相關的頁面；
- 跳轉鏈中間夹着一次 302，導致後續 301 的信号不完整；
- 新舊地址同时可訪問 200，只是舊地址額外挂了一段跳轉脚本；
- 只改了跳轉，没改 sitemap，舊地址還在文件里被持續提交。
把鏈路長度、狀態碼、落点质量、站内入口這四項按顺序核對一遍，多數跳了但没交接的情况都能定位到具体环节。跳轉本身只是入口管理的一部分，它决定的是抓取端能不能顺利走到新地址；至于新地址能否進入索引，仍然取决于頁面本身的质量和站点整体的抓取状况。