不损害SEO的网站迁移

我见过五位数的迁移项目变成六位数的SEO灾难，因为团队把迁移当作技术问题而不是连续性问题。模式总是一样的。构建新网站。切换。看着有机流量在接下来的八周内下降40%到70%。花接下来的一个季度来恢复切换日丧失的东西。

技术迁移很少会毁掉你。80%完成的重定向映射会毁掉你。指向暂存域的规范标签会毁掉你。仍然指向旧结构的内部链接会毁掉你。"趁机进行"的URL更改会毁掉你。构建本身是简单的部分；连续性工作是我在规模化迁移中成功或失败的地方。

五件事，在Seahawk Media的12,000个网站上艰难地学到的经验。每一项在我们进行的每次迁移中都是不可协商的。

首先，重定向映射在任何代码之前就要构建好。每个旧网址都会获得一个 301 重定向到其新对应地址。我们从 Search Console、Ahrefs 和现有网站地图导出源网址列表，然后在电子表格中构建映射，该映射成为切换的真实来源。如果任何迁移前的网址在映射中缺失，构建 linter 会导致部署失败。

其次，新平台允许的地方保留网址结构。每个网址变更都是排名风险。我们仅在有真实的内容原因时才更改网址——比如重复内容、拼写错误、要合并的规范标签——绝不会因为新平台建议使用不同的约定。"趁机整理一下"的诱惑在我们的迁移实践中造成的排名损失比任何其他决策都要多。

第三，超过一万页的网站采用分阶段推出。先迁移流量最低的内容，验证排名保持不变，然后扩展。分阶段迁移限制了如果某个模板或内容类型出现问题的影响范围，也让团队有机会在高流量页面受影响前修复问题。

第四，平行运行期。旧网站在启动后三十天内以只读模式保持在线。如果新网站出现问题，流量立即重新路由回去。运行两个堆栈一个月的成本相对于四周流量恢复周期的成本来说很小。

第五，启动后九十天的监控。Search Console 抓取统计、索引覆盖率、展示次数、日志文件分析、Schema 验证器、Core Web Vitals 字段数据。在几天内修复回归问题，而不是数个季度。到第九十天时网站已稳定，我们要么进行干净的交接，要么转入持续维护计划。

几种迁移类型几乎占我们所有项目工作的比例。每种都有自己的行动手册和常见的失败模式。

WordPress 迁移到 Next.js 或 Astro 是最常见的项目类型。简报通常是一个市场营销或内容网站，已达到经典 WordPress 的性能天花板，团队想要现代化的前端开发体验又不想失去用于编辑团队的 wp-admin。使用 WPGraphQL 的无头 WordPress 加上 Next.js 或 Astro 前端可以满足双方需求。

Drupal、Sitecore 或 Typo3 迁移到 WordPress 是第二种模式。从传统企业 CMS 迁移出来，又不破坏传统团队在十年间建立的 SEO 排名。迁移速度较慢，内容建模更复杂，但行动手册是一样的——完整的重定向映射、尽可能保留网址、平行运行、分阶段推出。

Shopify 迁移到无头商务是第三种。Shopify Plus 店面配合 Next.js 或 Hydrogen 前端，完全自定义设计，更快的 Core Web Vitals，保留了商务引擎。Shopify 继续充当目录、库存和结账的真实来源；前端采用自定义方案。

我们经常看到的其他模式包括：域名整合（多个旧域名合并为一个，配合适当的规范标签和重定向策略）、子域名转子目录整合（将 blog.example.com 迁移到 example.com/blog/ 来整合链接权重），以及托管和平台迁移（在 Kinsta、WP Engine、Pressable 之间迁移托管 WordPress，或迁移到裸金属基础设施）。

少于一千页的网站需要四到八周的端到端周期，包括规划、重定向映射、内容迁移、质量保证和发布后监控。一万到两万页的网站需要十二到二十周。五万页或以上的企业级迁移最少需要六到九个月，周期中包含分阶段推出和并行运行期。

最大的变量是源网站的内容质量。混乱的分类体系、重复的 URL 和不一致的元数据会让规划阶段增加数周。我们会在审计中诚实地告诉你，你的源网站是否已为迁移做好准备，或者是否需要先进行内容清理。假装源网站很干净，实际上并非如此，这是迁移从一个季度拖延到半年的原因。

基于最近真实项目的诚实价格范围。五百页以下的小企业迁移费用为四千到一万二千英镑。一千到一万页的中型市场迁移费用为一万五千到六万英镑。十万到十万页的企业级迁移费用为六万到三十万英镑，包括发布后第一个季度的持续 SEO 支持。

成本的百分之三十到四十用于规划和质量保证，而不是技术构建。报价便宜的团队通常是那些跳过规划的团队。你后来会为此付出代价，表现为排名下降，而重建排名的成本总是比保留排名的成本更高。