content-migration

内容迁移

将内容从一个平台、域名或 URL 结构迁移到另一个，同时不影响 SEO、用户书签或下游集成。与技术栈无关。

---

适用场景

• 从一个 CMS 迁移到另一个（例如，从 WordPress 迁移到无头架构）
• 将多个网站整合为一个
• 将一个网站拆分为多个
• 更改 URL 结构
• 域名迁移（从一个品牌迁移到另一个品牌，合并，品牌重塑）
• 从定制开发迁移到平台（或反向迁移）
• 在更大规模的迁移中，根据内容审计结果进行清理

不适用场景

• 全新网站，没有现有内容（无需迁移）
• 在现有网站中进行单页编辑或内容更新（使用 content-and-copy）
• 不涉及 URL 更改的性能或技术 SEO 改进（使用 seo-technical）
• 常规内容审计（使用 seo-content-audit）

---

必需输入

• 来源：当前平台、当前 URL 结构、当前内容清单
• 目标：目标平台、目标 URL 结构、目标平台的功能
• 迁移原因（决定优先保留哪些内容）
• 限制条件（时间线、预算、可接受的停机时间）
• 利益相关方（SEO、内容、开发、沟通、支持）

---

框架：6 个阶段

每次内容迁移都遵循相同的流程。跳过任何阶段，都可能导致迁移出问题。

阶段 1：盘点

不了解现有内容，就无法迁移。请建立一份完整的现有内容地图。

为每项内容记录：

• URL
• 标题
• 内容类型（文章、着陆页、产品、文档等）
• 状态（已发布、草稿、已归档、已安排）
• 上次修改时间
• 作者或负责人
• 流量（过去 12 个月），如果缺少数据，则按数据可用性规则说明
• 反向链接（主要外部引荐来源）
• 指向该内容的内部链接
• 嵌入资源（图片、视频、下载内容）

数据来源：CMS 导出、XML 站点地图、服务器日志、分析工具、搜索控制台、反向链接工具。

清单应以电子表格形式维护。它是整个迁移过程中其他工作的事实依据。

阶段 2：审计并决策

针对每项内容，做出以下决定：

• 保留： 原样迁移
• 更新： 修改后迁移（刷新、扩充、修复）
• 合并： 与其他内容合并，并将两个旧 URL 重定向到新 URL
• 重定向： 不迁移内容；将其重定向到相关页面
• 删除： 不迁移，也不设置重定向（谨慎使用；仅适用于明确价值低的页面）

这属于 seo-content-audit 工作。迁移时正是进行审计的好时机，而不是跳过审计的理由。

对于每项“更新”或“合并”的内容，请记录具体变更。

阶段 3：映射 URL

URL 映射表是迁移中最重要的产物。

旧 URL	新 URL	状态码	原因
/old/path	/new/path	301	直接对应
/old/page-1, /old/page-2	/new/merged	301	内容已合并
/old/deprecated	/related/replacement	301	最接近的替代页面
/old/junk	(none)	410	有意删除

规则：

• 有新归属位置的内容使用 301（永久重定向）
• 有意删除的内容使用 410（已删除）
• 如果 410 更准确，避免使用 404（未找到）
• 绝不要将所有内容重定向到首页；越具体越好
• 为所有有流量或反向链接的 URL 建立映射；优先级较低的 URL 可按规则批量映射

对于域名迁移，默认采用一对一路径映射（old.com/page → new.com/page），并针对结构变更的部分设置特定例外。

阶段 4：构建并暂存

构建目标站点。不要跳过预发布环境。

• 使用新内容搭建新平台
• 实施 URL 映射（大多数平台都支持重定向文件或规则）
• 抽样验证重定向是否正常
• 测试关键用户流程（注册、购买、联系）
• 验证分析工具、监控和集成
• 从搜索引擎的角度进行测试：robots.txt、站点地图、规范 URL

如果可行，在切换前让 Google 抓取目标站点，这样在重定向切换时，目标站点就已被收录。

第 5 阶段：切换

真正的切换。像发布一样做好规划（并结合此技能使用 launch-runbook）。

切换前：

• 向利益相关者沟通（日期、预期影响）
• 如预计会停机，向用户沟通
• 做好支持团队准备，应对可能出现的问题
• 提前一天降低 DNS TTL（为稳妥起见，提前 1～3 天）
• 备份源平台（以备需要回滚）

切换时：

• 重定向规则上线
• DNS 变更生效
• 向搜索引擎提交新站点地图
• 删除或更新旧站点地图
• 审查并更新内部链接，使其指向新 URL（如可行）
• 如用户可见的服务受到影响，更新状态页面或添加横幅

切换后立即执行：

• 对清单中排名靠前的 50 个页面进行冒烟测试
• 确认重定向状态码为 301（而非 302）
• 在搜索控制台中检查错误
• 实时监控流量，留意意外下降
• 查看错误日志，检查是否存在资源缺失或集成失效

第 6 阶段：监控与恢复

迁移并非在切换时就结束。接下来的 30～90 天会暴露问题。

关注：

• 流量： 预计会暂时下降（10%～30% 很常见）；应在 4～8 周内恢复。若此后仍持续下降，就说明存在问题。
• 收录： 新 URL 应被抓取并收录。在搜索控制台中检查覆盖情况。
• 排名： 跟踪热门关键词。排名下降是正常的；排名骤降则表明可能存在重定向或规范 URL 问题。
• 反向链接： 检查从其他网站链接过来的页面是否仍能跳转到正确的目标页面。
• 404： 检查是否有本应重定向的 URL 返回 404？将其添加到映射表中。
• 用户反馈： 查看支持工单和社交媒体。用户能否找到他们之前保存的链接？

常见的 30 天内修复项：

• 根据 404 模式添加遗漏的重定向
• 更新遗漏的内部链接
• 如果收录停滞，重新提交站点地图
• 排查并修复任何抓取错误

---

工作流

第 1 步：确定范围

哪些内容在范围内？哪些不在？写下来。若不设定边界，迁移范围就会不断扩大。

第 2 步：建立清单

提取所有 URL、流量、反向链接和内部链接。电子表格就是最终产物。

第 3 步：逐项决策

保留、更新、合并、重定向或删除。记录决策。

第 4 步：映射 URL

建立完整的重定向映射表，并由 SEO 和内容相关利益方审核。

第 5 步：构建目标平台

在预发布环境中构建。使用真实内容（或有代表性的内容）和真实重定向。

第 6 步：测试

• 抽样检查重定向（按流量排名前 20、按反向链接排名前 20，以及边缘情况）
• 关键流程（注册、结账、联系）
• 分析与监控
• 从搜索引擎的角度检查（robots.txt、站点地图、规范 URL）

第 7 步：切换

按照切换检查清单执行。准备好回滚方案。

第 8 步：监控

第一周每天监控。第一个月每周监控。之后每月监控，持续到 90 天。

第 9 步：记录结果

哪些做得好，哪些没做好，以及经验教训。（参见 after-action-report。）

---

失败模式

**没有 URL 清单。**迁移团队以为已经掌握了所有内容，其实并没有。旧 PDF、归档文章、带有反向链接的营销落地页，都可能遗漏。请建立清单。

**使用 302 重定向，而不是 301。**302 表示临时重定向。SEO 权重不一定能可靠传递。除非有特定原因，否则请使用 301。

把所有内容都重定向到首页。“我们让用户自己找路。”他们不会，而是会立即离开。请逐一映射。

重定向链过长。/a → /b → /c → /d。每次跳转都会损失少量权重并增加延迟。请缩短为 /a → /d。

**忘记非 HTML URL。**PDF、图片、下载文件也都有 URL，也有反向链接。请将它们纳入映射。

忘记查询字符串。/page?id=123 和 /page 是不同的 URL。请为查询字符串变体设置匹配规则或单独映射。

**忽略尾部斜杠。**对大多数服务端来说，/page 和 /page/ 是不同的 URL。请选择一种规范形式，并将另一种重定向过去。

**没有预发布环境。**迁移第一次运行就在生产环境中，结果问题频出。请先在预发布环境中测试。

**预发布环境与生产环境差异过大。**DNS、CDN、平台都不同。测试在预发布环境中通过，却在生产环境中失败。请尽可能让预发布环境贴近生产环境。

**让源站继续运行。**两个网站提供相同内容，会导致内容重复、权重分散、用户困惑。确认目标站点运行正常后，请关闭源站。

**源域名未续费。**域名过期会导致重定向失效、流量消失。请为源域名续费较长时间，即使你不再使用它。

**没有回滚计划就进行大规模切换。**出了问题怎么办？请在切换前规划回滚方案。

**在繁忙时段切换。**季度末、节假日、大型营销活动期间都不是好时机。请选一个业务平静的时段。

**没有沟通。**用户发现书签失效，却没有收到任何通知。有些用户不会再回来。请做好沟通。

**把迁移当作一次性事件。**切换完成并不代表迁移结束。请监控 30-90 天，并修复发现的问题。

**把迁移当作单纯的开发项目。**SEO、内容、支持和沟通团队都需要参与。从第一天起就应跨职能协作。

---

输出格式

迁移计划文档包括：

• **范围：**包含哪些内容，不包含哪些内容
• **清单：**URL 电子表格
• **审核决策：**保留、更新、合并、重定向、删除
• **URL 映射：**旧 URL 到新 URL，并注明状态码
• **架构：**新平台设置、重定向实现方式
• **切换计划：**切换当天的操作手册
• **回滚计划：**发生问题时的处理方式
• **监控计划：**监控哪些内容、监控多久
• **沟通计划：**内部和外部沟通
• **负责人和时间表：**谁在什么时候做什么

---

如果无法获取所需数据

此技能的输出依赖于它无法独立生成的数据、测量结果或工具结果。如果所需输入、工具或数据源不可用或无法验证，获准的输出应是注明缺口的交付物：说明需要什么、实际获取或验证了什么，以及输出的哪些部分受到影响。绝不允许为了完成交付物而捏造、估算或插补所需数值。明确说明缺口本身就是完整的回答。

---

参考文件

• references/migration-runbook.md：切换当天的分步操作手册，包括切换前检查、实际切换、即时验证，以及前 24 小时的监控。