换 CMS 迁到 WordPress：URL 对照表怎么建

换 CMS 迁到 WordPress，成本最高的一步不是导入，而是迁移之后没人能说清某个旧地址去了哪里。一张逐条可核对的旧 URL 到新 URL 对照表，是这次迁移里唯一必须先做完的东西：表做完了，后面每一次"某个页面找不到了"都能很快定位；表没做，就得靠人肉一条条试。

第一步不是导入，是把旧站 URL 捞全

旧地址清单要同时来自三个地方，缺一个都会漏：旧 CMS 后台导出的完整链接、服务器访问日志里的真实请求记录、以及你记得的入口页（首页、栏目页、专题页、落地页）。日志最容易被忽略，因为很多旧地址根本不在 CMS 的链接表里——它们可能是外部抄走的地址，可能是带参数的打印页或详情页，也可能只是大小写不同。

参数变体要单独占一行。同一份内容常常有多个可访问地址：带追踪参数的、带分页参数的、历史改过路径的。对照表里每一行都算一个独立地址，不要合并成"同一个页面"。

对照表至少要有这七列

"处理方式"这一列只允许四种值：301、保留原地址、404、410。出现第五种，说明这件事还没想清楚。

目标 URL 怎么定，重定向怎么落地

先定命名规则，再填新 URL，否则表要重做。规则上可以参考 Google 关于 URL 结构的建议：能用可读的词就别用长串数字，路径里用受众熟悉的语言，参数尽量少。

重定向用永久类型。Google 对重定向类型的说明把 301、308 列为永久重定向，并写明索引流程会把重定向目标当作规范目标看待，服务器端设置的重定向最容易被正确解释。同一份文档没有给出任何生效时限，也没说规则要保留多久。

WordPress 这一侧要分清改的是重写规则还是站点选项：官方接口手册把 Rewrite 与 Options 归在公共接口的不同章节里，固定链接结构、重写规则、站点地址都属于这一层，动之前先确认自己改的是哪一个。这套文档只说明数据归属和接口用法，不对搜索表现作任何承诺。

规则量大就用命令行做，别在后台点。WP-CLI 文档里的数据库导出与批量替换命令可以在预发布环境先跑一遍、看清影响行数，再上生产。顺序永远是：先导出数据库、试跑、核对、执行、再导出一次。

什么时候这套表不适用

• 新旧两套站要并行一段时间。此时同一份内容有两个可抓取地址，先别急着上 301，等旧站确定下线再一次切干净。
• 新站 URL 规则还没定。新 URL 那一列应该留空，而不是先填一个"大概会这样"的值。
• 有些旧地址本就不该有对应页：已删除的内容、纯参数组合、后台或打印页。这些填 404 或 410，不要全部指向首页——那会造出一批指向首页的重定向，把站内关系搅在一起。
• 换域名与内容合并同时发生。要先定新站的唯一形式，再决定旧地址分别指向谁；canonical 和外链指向的 URL 有什么关系讲的就是这个判断口径。

怎么验证迁移真的完成了

1. 按表逐条请求旧地址：状态码是不是 301、跳转是一层还是多跳、最终页面是不是 200。表里"验证状态"这一列就是给这一步用的。
2. 优先验外部链接最多的旧地址。一条链接算一条还是多条：URL 变体的计数问题提醒过，同一地址的参数变体和外部链接要分开看，验证顺序也该按链接数量排。
3. 检查新站里是否还残留指向旧地址的站内链接，确认旧站已停止对外服务。域名同时更换时，更换域名后旧外链怎么处理列了几类常见残留入口。
4. 把完成时间与执行人写回表格。这张表本身就是这次迁移的交付物之一。

先做表，再动站。表里每一行都能被独立验证通过，这次迁移才算真的结束。