SEO 迁移可能涉及域名、网址、平台、架构或渲染方式的变化。工作应包括开发前的规划、发布前的验证和发布后的监测。准备工作可以减少可避免的错误，但不能保证排名或流量保持不变。
阶段一：规划并记录基线
- 确定范围：是否要改域名、协议、网址、CMS、内容，或同时改动多个方面？
- 抓取现有网站，保存网址、状态、元数据、链接和 canonical 清单。
- 记录 Search Console、分析工具、查询、落地页、转化和 Core Web Vitals 数据。
- 根据使用数据、链接和业务用途识别重要页面。
- 决定哪些网址保留、合并、变更或删除。
- 准备备份、决策负责人和恢复方案。
如果可以分阶段进行，就避免同时改变太多事项。大型网站只有在测试有实际价值且能代表目标系统时，才考虑先迁移其中一部分。
阶段二：测试环境验证
限制测试环境的索引和不必要的公开访问。检查渲染后的 HTML、链接、元数据、canonical、适用时的 hreflang、robots、sitemap 和结构化数据。确认用户和爬虫都能访问重要信息。
为每个旧网址建立与相关新页面对应的重定向映射。永久改动使用永久重定向。不要把所有网址都转向一个通用页面。检查站内链接，让它们直接指向最终网址，避免经过重定向。
测试移动页面、表单、搜索、登录和付款流程。检查分析、活动追踪、整合和同意管理功能，并确认测试数据不会混入正式数据。
阶段三：发布
切换流量前确认 TLS、DNS、HTTP 状态、robots 和服务器容量。启用重定向映射和新 sitemap。按各类模板检查网址，包括重要页面和有外部链接的旧页面。
阶段四：监测与修复
检查服务器日志、Search Console、分析数据、404 错误、重定向链、canonical 和 Core Web Vitals。与基线比较时也要考虑季节和营销活动。先修复影响用户和重要页面的问题。
Google 的网站迁移指南指出，网址重新发现和处理期间可能出现暂时波动。每个页面的处理时间没有固定期限。只要对用户和搜索引擎有帮助，就保留旧重定向，并根据数据判断后续是否需要调整。
常见问题
可以直接在正式网站上进行迁移吗？
重大改动应先在测试环境验证。若必须在正式环境紧急修复，请记录改动、验证方法和恢复方案。
技术工作开始前应该记录什么？
保存网址、内容、元数据、链接、分析和搜索基线、重要配置及决策负责人。
什么时候需要迁移专家？
当范围涉及大量网址、架构或平台变化、重要流量或多支团队时，应及早明确是否需要专家，以及各方的责任。