多站点群一起改版，全站替换和 301 跳转谁先做

多站点群一起改版时，先做 301 跳转，再做全站替换。理由不是习惯，而是两个动作改的对象根本不同：301 跳转改的是 URL 的归属关系，要在旧地址还能被访问、新地址已经上线的那个时间窗里建立；全站替换改的是正文与链接文本里的关键词，属于内容层。顺序反过来，替换会把新路径写进正文，而跳转表还是空的，搜索引擎在同一轮抓取里既看到旧地址又看到新地址，收录就来回摆动。

两个动作改的对象不是一回事

跳转解决的是「这个地址现在归谁」。旧地址一旦被删而不是重定向，外面所有引用它的入口——搜索结果、其他站点的外链、用户收藏——都会落到一个空页面上，历史积累的权重也跟着断掉。跳转表是把旧的 URL 一一对应到新的 URL，属于站点结构层。

全站替换解决的是「页面里那句话怎么改」。导航文案、正文里的产品名、内链文本这些散落在许多文档里的字符串，靠逐篇手工改不现实，AnQiCMS 提供全站替换工具做批量关键词或链接替换，一次任务覆盖整批文档。它改的是内容数据，不改地址结构，所以不会替你把旧链接变成新链接的对应关系。

两者的差别在于：跳转对外部引用负责，替换对读者阅读负责。改版要同时做完，但先后顺序是固定的。

先定 URL 规则再动内容

跳转表的内容取决于新地址长什么样，所以新规则必须先定下来。伪静态规则管理负责的就是这件事：确定分类页、文档页、标签页各自的路径形态，确认扩展名、层级、是否带尾斜杠。规则一旦切换，全站替换里写的内链文本才有目标地址可指。

这一步常见的失误是边改规则边发文。新规则没定稿就替换正文，等规则再变动一次，之前替换进去的链接全部指向不存在的地址，返工范围比不做还大。多站点环境下这一点更明显：一套规则同时作用在多个站点上，改错会一起错。

跳转表要在切换前建好

建立顺序建议固定成四步：

第一步，把旧地址全量导出来，按分类分组，标注哪些在新结构里有对应页、哪些应该合并、哪些准备下线。

第二步，在新模板部署完成但还没切流量时，把跳转表配进 301 跳转管理，用少量地址验证一次，确认返回的状态码确实是永久重定向而不是临时跳转。

第三步，切流量，观察抓取与收录日志，确认旧地址的请求都被接住。

第四步，才做全站替换，把正文里的旧文案与内链文本一次性改掉，替换完抽查若干页面看有没有误替换。

跳转先于替换的好处是：任何时刻旧地址都能到达内容，切换是渐进的而不是断崖式的。

多站点分批验证的检查点

多站点管理让一个后台管住多个站点，这带来一个改版特有的陷阱：五个站点同时切，同时观察，出问题时无法判断是哪个站点的规则不对。

分批的做法是按站点排队。先挑流量最小的那个站改版，跳转表与全站替换都做完，等一轮抓取周期过去，确认收录与新地址都对，再推下一个站。每个站改完留三个检查点：旧地址的返回状态码、新地址是否正常渲染、站点地图里的地址是否已换成新规则。

替换类任务还要额外确认一件事：替换范围有没有越界到别的站点。全站替换按条件执行，条件写得宽就容易把不相关站点的内容一起改掉，先在单站点上小范围试跑，比直接全站执行安全。

顺序对照表

常见问题

改版前要不要先把旧地址备份一份？ 要。全站替换是不可逆的批量写入，改版前先做一次备份，改坏了可以直接恢复，比逐篇回滚快得多。

旧地址已经失效一段时间，还能补跳转吗？ 可以，但要先确认这些地址在外链与搜索缓存里还存在。跳转只对还有人访问的地址有意义，没人访问的地址补上也不产生价值。

能不能只做替换、不做跳转？ 只对正文有效。地址变了而不建跳转，等于把所有外部引用留在原地，旧页面从 200 变成 404，替换省下的工时会在收录损失上加倍还回来。

多个站点的规则不一致怎么办？ 分别建跳转表，分别验证。多站点管理统一的是后台入口，不是地址规则，把不一致的规则强行合并反而更难排查。