用途：在平台、域名或 URL 结构之间迁移内容，避免破坏 SEO、用户书签和下游集成，技术栈无关。适用场景：更换 CMS（如 WordPress 迁移到无头架构）、多站合并、单站拆分、修改 URL 结构、域名迁移（品牌更换、并购、更名）、自建站与平台互迁，以及顺带进行内容审计清理。不适用：全新站点无内容可迁、站内单页编辑或内容更新、不改 URL 的技术 SEO 优化、常规内容审计。
必需输入：源端（当前平台、URL 结构、内容清单）、目标端（目标平台、URL 结构、能力）、迁移原因（决定保留优先级）、约束（时间、预算、可容忍停机）、干系人（SEO、内容、开发、传播、支持）。
六阶段框架：1）盘点：逐条记录 URL、标题、内容类型、状态、最后修改、作者、近 12 个月流量（数据不可得时按数据可用性规则说明缺口）、外链、内链、嵌入资源，来源包括 CMS 导出、XML 站点地图、服务器日志、分析工具、搜索控制台等，产出电子表格作为唯一事实来源。2）审计决策：对每条内容决定保留、更新、合并、重定向或删除，并记录具体变更。3）URL 映射：核心产物，记录旧 URL、新 URL、状态码与原因；有新房用 301，有意删除用 410，避免 404，不要全部重定向到首页，有流量或外链的 URL 必须逐条映射。4）构建与预发：在接近生产的环境搭建新站、实现重定向、验证样本、测试关键流程、校验分析与监控及 robots.txt、站点地图、canonical。5）切换：提前沟通、降低 DNS TTL、备份源站，切换时上线重定向与 DNS、提交新站点地图，切换后冒烟测试前 50 页、确认 301 非 302、检查搜索控制台与实时流量、错误日志。6）监控与恢复：切换后 30 至 90 天观察流量（常见暂时下降 10% 至 30%，4 至 8 周恢复）、索引、排名、外链、404 和用户反馈，修复遗漏重定向。
工作流：确定范围、建立盘点、逐条决策、映射 URL、预发构建、测试（按流量与外链前 20 及边界情况）、按清单切换并准备回滚、监控（首周日更、首月周更、90 天月更）、记录结果。
常见失败：无 URL 清单、用 302 替代 301、全部重定向到首页、重定向链过长、遗漏非 HTML URL 与查询字符串、忽略尾斜杠、无预发环境、源站未下线或域名未续费、无回滚方案、在繁忙期切换、缺少沟通、把迁移当作一次性事件、仅由开发主导。
输出为迁移计划文档，含范围、清单、审计决策、URL 映射、架构、切换与回滚方案、监控方案、沟通方案、负责人与时间线。数据不可得时，应说明所需数据、实际获得情况及受影响部分，不得编造估计值。参考文件：references/migration-runbook.md，包含切换日分步手册、预检、实际切换、即时验证及前 24 小时监控。