先把旧站所有能拿到的地址列成一张表,再为每条地址指定一个明确去向:保留同路径、跳到最接近的新页、或返回 410。不要先改 DNS,映射规则没定完就切换,后面只能靠日志被动补洞。
换空间时最麻烦的不是搬家本身,而是旧地址和新地址对不上。你能拿到的资料通常分三档:
这三档对应的映射精度完全不同。资料完整时可以做逐条 301;资料极少时只能做前缀级规则加兜底,接受一部分旧地址落到 404。关键是先承认自己在哪一档,而不是假装能还原全部历史地址。
拿到地址表后,不要急着写规则。先给每条地址打一个标签,标签决定它走哪种处理:
/category/post-name/,换空间后路径不变,不需要额外规则。/archives/123 对应新文章 /news/post-name/,写单条 301。分类完成后,先统计第 2 类有多少条。如果超过几十条,手工写规则容易漏,应改为从地址表生成规则文件,再整体部署。
假设你只有旧站 sitemap 和 WordPress 后台的文章列表,没有访问日志,也没有旧服务器权限。此时可以执行的最小动作是:
<loc> 地址,去重后作为旧地址主表。/tag/ 全部跳到新站标签首页或最相关栏目。这个动作的结果是:你能得到一张“旧地址—处理方式—目标地址”的三列表。它不保证覆盖所有历史地址,但能覆盖 sitemap 中公开过的部分。下一步就是拿这张表去生成服务器或插件可读的跳转规则。
需要说明的是,sitemap 里没有的地址不代表不存在。旧站可能有过未进 sitemap 的页面、被屏蔽的附件页或已删除内容,这些只能等上线后从 404 日志里发现。所以映射不是一次完成,而是先覆盖已知部分,再根据实际请求补漏。
规则可以放在三个位置,选择依据是你对服务器的控制程度:
rewrite 或 RedirectMatch 批量处理前缀级跳转,性能最好,但改错影响全站。假设旧站有 200 条文章地址需要一对一跳转,放在 WordPress 层意味着每次请求都要经过 PHP 判断;放在服务器配置层则直接在入口完成。规则数量少时两者差别不明显,数量大时服务器层更稳。但服务器层改错会导致整站跳转异常,所以部署前应先在测试环境验证规则语法。
切换完成后,不要只看首页能否打开。按下面顺序验证:
如果某条旧地址返回 404,先看它是否在旧地址表里。不在表里,说明它来自未覆盖的历史地址,应补进下一轮规则;在表里却 404,说明规则没生效或目标地址写错,应先修规则再继续观察。不要把 404 数量下降当作映射正确的唯一证据,因为 404 也可能被跳转到首页后消失,而首页并不是合适的目标。
映射设计的目标不是让所有旧地址都返回 200,而是让每条旧地址都有明确、合理的去向。能做到这一点,换空间后的地址断层就控制在可处理范围内。