从 WordPress 迁移到无头 CMS 而不丢流量

• 大小。 非常大的站点会在导出中途撞上 PHP 限制，生成一个看起来仍然有效的截断文件。把 XML 中的文章数与wp_posts 对比。
• 编码。 从头到尾检查一篇含非 ASCII 字符的文章。导入后才发现的编码问题排查起来痛苦不堪。

#第 3 步——先设计内容模型

本能反应是先导入再整理。反过来做。

一篇带八个自定义字段的 WordPress 文章，在结构化 CMS 里通常是两三个得体的类型。在导入之前就确定好那个形状，否则你会把 WordPress 的模型带进一个你当初正是为了逃离它才选择的系统。

在 corpusctl 中没有内置的内容类型；你从面板或 API 定义它们，字段携带角色——title、slug、body。角色就是系统不管你把字段命为什么名字都能知道哪个字段是标题的方式，也正是它让阅读时长、目录这类计算字段无需配置就能工作的原因。

一个典型的映射：

本地化是一个字段属性，而不是一个重复的站点。如果你之前在用 WPML 或 Polylang，那就是在这一步，那套结构会变得更简单。

#第 4 步——空跑（dry-run）导入

corpusctl 的导入器模块能读取 WXR，并有一个空跑模式：它生成一份计划而不写入任何东西。

响应里包含它将要创建的条目，以及带有逐条原因的skipped（跳过项）和warnings（警告）。两者都要读。静默跳过就是你到第二个月才发现 400 篇文章从未抵达的原因。

导入限制的存在是有道理的——解析器会直接拒绝含有 DOCTYPE/ENTITY 声明的 XML，因为那正是 XML 炸弹的攻击向量；而超过大小上限的文件会被拒绝，而不是流式读入内存。如果你的导出文件触发了其中任何一项，就把它拆开。

然后真正跑一遍，并核对数量：导入多少篇、导出多少篇，逐类型核对。

#第 5 步——重建前端

这是最大的一项任务，而且它是一个普通的 Web 项目，所以唯一与迁移相关的建议是关于 URL 的。

尽可能保留 URL 结构。 你保留的每一个 URL，都是一条你不必写的重定向、一个你不必迁移的排名信号。如果当前结构是/2019/03/some-post/ 而你讨厌它，改它是另一个项目——不要把 URL 重构捆绑进 CMS 迁移里。如果两者都出了错，你将无从得知是哪个造成的。

在读取端，corpusctl 的客户端不调用 API：已发布的内容在发布时写入一个不可变、以哈希寻址的文件，客户端在本地把 slug 解析到某个清单分片，然后从 nginx 边缘缓存中取回那个地址。两次请求，都可缓存，都不触及数据库。

块渲染器带着零默认样式发布，所以你的设计工作就是你的设计工作——CMS 不贡献任何需要与之争辩的 CSS。

#第 6 步——重定向，包括你会忘记的那些

每个旧 URL 都需要一个 301 指向它的新位置。人们会写下的列表：

• 文章和页面

他们会忘记的列表：

• 附件页面（/some-post/image-name/）——WordPress 会为每个媒体项生成一个，而 Google 已经把它们索引了
• 订阅源（feeds）——/feed/、/comments/feed/、逐分类的订阅源
• 分类、标签、作者和日期归档页
• 分页归档——/page/2/、/page/3/ …
• ?p=123 和 ?page_id=123 这类查询字符串形式
• 大写和带尾部斜杠的变体，如果旧服务器接受它们的话

从 Search Console（页面报告）而不是从站点地图导出 URL 列表。站点地图是你本打算发布的东西；Search Console 是 Google 实际找到的东西。

#第 7 步——切换并验证

在低流量的时段上线，然后盯两周：

Search Console——看覆盖率报告里 404 或“已排除”页面是否骤升；把性能数据按页面类型分段，看看是不是某个模板比其他模板丢得更多。

服务器日志——爬取日志告诉你 Googlebot 在访问什么、又得到了什么。日志里的一个 404，就是一条你漏掉的重定向；当天修好它分文不花，而拖一个月再修则要以排名为代价。

Core Web Vitals——看现场数据，而不是实验室分数。无头迁移通常正是在这里展现出真正的改善，因为从缓存提供的预构建内容，背后没有一个缓慢的源站可藏。

至少一个月内不要删除 WordPress 安装。让它继续运行、断开链接并设为noindex，这样你就能查看某个页面以前长什么样。

#诚实地说，什么会出问题

编辑会抱怨预览。 WordPress 在 CMS 内部预览。无头预览通过草稿模式走你的前端，如果你在切换前没把它接好线，编辑团队上线第一天就会发现。先把它接好。（corpusctl 的草稿模式辅助工具使用恒时间比较来校验密钥，并拒绝任何不是已确认相对路径的 slug，从而堵上了大多数手写预览端点都有的开放重定向漏洞。）

短代码会留下残留物。 插件本来在渲染的任何东西，都会在导入的正文里以原始文本出现。导入后在整个语料库中 grep[。

评论。 WXR 会把它们导出；大多数无头 CMS 无处存放它们。如果评论很重要，就在切换之前而不是之后规划一个第三方服务。

第一个月会更慢。 人们在 WordPress 里用了十年，知道每样东西在哪里。为此预留余量，不要把发布安排在同一周。

相关阅读： corpusctl vs WordPress · 无头 CMS 的 SEO：流量从哪里流失 · 什么是无头 CMS？