站点改版最容易被忽略的部分不是页面设计，而是搜索蜘蛛手里那张老地图。旧 URL 一旦被删掉、新的地址又没有出现在任何它熟悉的位置，蜘蛛会继续按惯例请求旧路径，拿到 404 之后逐步减少对整站的访问。迁移要做的事情其实很简单：把新地址明确地告诉它，并让站内的链路先一步指向新地址。
先分清是「路径变了」还是「内容搬了」
两种情况处理方式不同。第一种是内容没动，只是 URL 结构变了，比如从 /p/123 改成 /guide/xxx，这类页面最适合用 301 直接对应到新地址。第二种是内容也重新组织了，一篇文章被拆成几篇，或者几篇合并成一篇，这时候不存在天然的一对一关系，需要人工指定一个最合适的目标页面，其余的旧地址统一指向它，而不是让它们各自 404。
如果分不清这两类，迁移动作就会做得很乱：该做映射的地方做了整站跳转，该人工判断的地方交给规则自动处理。
迁移依赖的三条线索
301：尽量一对一，不要串成链
蜘蛛遇到 301 会跟过去，但连续跳两次、三次之后，抓取成本就上去了，而且中间任何一环配置错误，整条链就断在中间。能直接指向最终地址的，就不要先跳到中间页。旧页面的 301 目标必须是返回 200 的真实页面，不能指向另一个 301，也不要指向首页了事——把所有旧地址都堆到首页，等于告诉蜘蛛这些内容都不存在了。
内链：蜘蛛走的主路
内链是蜘蛛发现新地址最自然的方式。改版时，导航、面包屑、栏目列表、相关推荐这些位置要一起改，不能只改正文里的链接。列表页尤其容易被漏掉，它往往由模板生成，如果模板没更新，蜘蛛顺着列表翻十页，看到的仍然是旧地址。
新页面的入口尽量从已有页面的正常位置链出去，避免大量新链接集中堆在一个孤立的落地页上。
Sitemap：新旧并行一段时间
Sitemap 是补充线索，不是主路。改版后可以先保留旧 Sitemap 一段时间，但里面列出的应当是返回 301 的地址，而不是已经 404 的地址；新的 Sitemap 则只放返回 200 的新地址。两边都写上、又互相矛盾，蜘蛛只会更犹豫。
动作顺序建议
- 先在服务器或 CDN 层面配置好 301 规则，确认旧地址拿到的是 301，而不是 404 或 200 空白页。
- 再改站内模板：导航、面包屑、列表页、分页链接全部换成新地址。
- 更新 Sitemap，并确认其中的每个 URL 都能正常返回 200。
- 最后观察日志，看蜘蛛是否已经把请求重心挪到新地址上。
把顺序反过来容易出问题：Sitemap 先更新、内链还是旧的，蜘蛛抓到的页面里全是旧链接，反而会被带回旧路径。
用日志确认迁移真的发生了
重点看两个趋势：旧地址的请求量是否在下降，且返回码从 200 变成了 301；新地址的请求量是否在上升，且返回码是 200。如果旧地址还在被大量请求、并且返回 404，说明 301 规则没覆盖到这些路径，可能是大小写、结尾斜杠或者参数形式不一致导致的。
也可以顺便看一下新页面的首次被抓时间分布：如果蜘蛛集中抓了一批新地址，随后几天没有再回来，往往是新页面的内链入口太少，或者列表页还没更新。
几个常见的坑
- 旧地址直接删掉，没有做任何指向，蜘蛛只能拿到 404。
- 301 指向的页面本身又返回 301，形成链条。
- 只改了正文内链，导航和列表模板没动。
- 把带参数的旧地址全部重定向到首页，浪费了原有的链接关系传递。
- Sitemap 里同时出现新旧地址，且部分已经失效。
改版迁移不是一次性提交任务，而是一段时间内的收敛过程。给蜘蛛留出重新学习的窗口，比急着清理旧地址更稳妥。
最后一点：迁移期间服务器要保持稳定，响应时间抖动或者间歇性 5xx，会让蜘蛛降低抓取节奏，迁移进度自然被拖慢。等日志里新地址的抓取趋于平稳，再逐步清理旧的 Sitemap 和残留的跳转规则，整个迁移才算收尾。