为什么跳转做了，收录却没跟着更新
改版、换目录、合并栏目之后，最常见的处理是把旧地址用 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，旧地址还在文件里被持续提交。
把链路长度、状态码、落点质量、站内入口这四项按顺序核对一遍，多数跳了但没交接的情况都能定位到具体环节。跳转本身只是入口管理的一部分，它决定的是抓取端能不能顺利走到新地址；至于新地址能否进入索引，仍然取决于页面本身的质量和站点整体的抓取状况。