WordPress 迁移到 Next.js，不损失任何排名。

说实话？主要是因为 Lighthouse 永远无法达到理想状态。

我花了很多个早上向创始人解释，为什么他们精心打造的 Elementor 网站在 PageSpeed Insights 中一直卡在 62 分，即使已经用了三个缓存插件、配置了 CDN，还迁移到了新的主机。这有一个天花板。如果你真的很在乎，可以把经典 WordPress 前端推进到低 80 分，但每次插件更新都是回归风险，每次页面构建器发布都会额外增加半兆字节的你不需要的东西。

我看到迁移的团队分为三个大致的类别，它们几乎不会重叠。

性能类

一家A轮SaaS营销网站，目前托管在WP Engine，使用Elementor Pro加三个附加包。移动端Lighthouse得分64。INP为380毫秒。他们有一个内容团队每周发布两篇文章，还有一个工程团队希望开发入职流程，而不是处理WordPress补丁。Next.js重构将得分提至96，工程师们停止接触wp-admin。

工程部分

三名TypeScript工程师。其中一人负责营销网站的值班。他们每两周打开一次wp-admin然后抱怨。整个"这是PHP 7.4还是8.1，代理商留给我们的WooCommerce是什么版本"的程序是对那些乐于用Astro交付、麻烦少一半的人才的浪费。迁移，给他们一个具有适当CI的Next.js或Astro仓库，值班轮换就会减少。

安全部分

较少见，但更有决定性。董事会级别的授权，要求面向公众的应用不应运行PHP。或者一次安全事件导致修复的插件延迟三周才发布。在非公开源上使用Headless WordPress可以满足政策要求，而不会强制编辑团队学习新CMS。wp.example.com变为私密；前端只是Vercel上的静态网站。大多数渗透测试就不再有趣了。

三条。真的是三条，不是营销页面那种最后都缩小到同样范围的。每条适合不同的团队。

路径1——保留WordPress，替换前端

Headless。WordPress保留为编辑界面。Yoast继续在管理后台工作。ACF继续在管理后台工作。公开网站在Next.js或Astro中重建，并通过WPGraphQL拉取内容。编辑们除了看到URL栏显示新前端域名外，基本不会注意到迁移当天的变化。这是我规划最多的路径；近期迁移中大约三分之二走的是这条路。

何时适用：编辑团队在WordPress中很满意，工程问题纯粹是前端问题，你不想迁移一万两千页的Yoast元数据。

路径 2 — 完全离开 WordPress

将所有内容迁移到 Sanity、Payload、Storyblok 或 Contentful。在上线时关闭 WordPress。更新的代码库、更清晰的内容模型、完全没有 PHP。迁移成本更高，因为你在移动内容，而不仅仅是重建前端。当编辑团队明确想要离开 WordPress，或者当内容模型需要比 ACF 灵活内容更严格的结构时，这种方法值得采取。

合适的时机：你真正需要的是不同的 CMS，而不只是不同的前端。

路径 3 — 混合方案

部分内容留在 WordPress 中，部分内容迁移到其他地方。真实的示例模式：博客留在 WP 中，因为编辑团队成熟且 Yoast 在发挥实际作用；产品页面迁移到 Payload，因为架构需要适当的关系和验证。前端是一个 Next.js 应用，从两个后端读取数据。架构更复杂，但有时这是正确的答案。

合适的时机：同一个网站上有两种真正不同的内容形状，强行将它们放入一个 CMS 会让某人的生活变得更糟。

这是迁移成功或失败的关键，也是团队经常偷工减料的地方。没有完整的映射，你会在第一天就失去排名。有不完整的映射，你会在六周内逐渐失去排名，同时告诉自己这个下降只是季节性波动。

映射在任何代码发布之前从三个独立来源构建。

1. Search Console 导出 — Google 在过去 16 个月内爬取并认为可索引的每个 URL。这是 Google 当前期望在你的域名找到的规范列表。
2. Ahrefs 或 Semrush 导出 — 每个至少有一个引用域指向它的网址，按引用域数量排序。这些是 301 保留最重要的网址。如果你让一个拥有 200 个反向链接的页面返回 404，你就损失了 200 个反向链接。
3. WordPress 网站地图 — 你当前的 XML 网站地图导出。捕获可能没有反向链接或自然流量但仍在结构中的页面。作为第三轮检查很有用，可以找到前两轮遗漏的任何内容。

三份列表，去重，映射到新网址，在 vercel.json 或 netlify.toml 中作为边缘 301 进行传送。不是 302。不是 JavaScript 驱动的重定向。不是元刷新。真正已停用的网址返回 410。更改了 slug 的网址返回 301。如果任何迁移前的网址在映射中缺失，构建 linter 会导致部署失败。

我见过一个 5000 页的迁移在八周内失去 60% 的自然流量，因为重定向映射只完成了 87%，有人说"其他的不值得担心"。那 13% 是值得担心的。总是这样。

第一天进行插件审计。每个活跃插件都属于四个类别之一，该类别决定了工作量。

保持原样

运行在服务器端且从不接触公共前端的插件。WP Migrate DB、BackWPup、服务器端分析、角色管理。它们继续工作是因为它们的工作不涉及向访客呈现 HTML。通常约占插件总数的 20-25%。

用代码替换

将 HTML 或 JavaScript 注入到前端的插件。大多数 SEO 插件（元数据传输，前端输出是自定义的）。大多数表单插件（由 Next.js 端点或 ConvertKit / HubSpot / Mailchimp 替换）。大多数 schema 插件（由发出更清晰 JSON-LD 的手写模板替换）。Cookie 横幅用 TypeScript 重写。约占插件总数的 30-40%。

由服务替代

包装第三方服务的插件。HubSpot 嵌入插件变成 HubSpot Forms API 调用。Stripe 支付插件变成 Stripe Elements。Zapier 和 Make 保持原样，因为它们本来就在 WordPress 外。约占 10-15%。

完全删除

纯粹因为 WordPress 前端需要而存在的插件。缓存插件（Vercel 处理）。大多数安全插件（公共攻击面消失了）。性能优化插件（现在是构建时的问题）。还有那些有趣的"我不知道为什么有这个，它已经停用两年了但我们从未删除过"类别。迁移后 WordPress 端的插件数量通常下降 70-80%。这是优势所在。

预览和草稿

编辑在 wp-admin 中点击预览。WordPress 生成一个 JWT 预览令牌。Next.js 前端读取令牌，通过 WPGraphQL 绕过静态缓存获取草稿，然后渲染。草稿 URL 是签名的，永远不可索引，永远不被公开缓存。一键预览的用户体验保持完全相同。大多数编辑从不会注意到迁移日期在编辑端的影响。

评论、修订、角色

后端保持不变。文章评论可以保持 WordPress 原生，并通过 WPGraphQL 以无头方式渲染，或被替换为 Disqus / Giscus / 自定义系统，如果你的团队想要这样做的话。修订保持不变——每篇文章仍然可以从 WordPress 编辑器访问其完整历史记录。用户角色、权限、多作者设置，全部保留。

Yoast 和 Rank Math

两种传输方式都支持。Yoast SEO for WPGraphQL 公开所有字段——焦点关键词、元标题、元描述、规范标签、OG、Twitter卡片、schema面包屑——都可作为GraphQL查询。Rank Math有相应的功能。Next.js layout读取类型化响应并渲染元标签，与Yoast或Rank Math在经典WordPress上的输出完全相同。编辑在同一插件界面中继续编辑；迁移对他们来说是无感的。

第一周：发现与范围界定

插件审计。内容审计。Search Console + Ahrefs导出重定向映射源。当前性能基线。决定采用方案一还是二还是混合方案。输出：固定价格和里程碑付款计划的书面SOW。到第一周末，你清楚地知道自己要支付什么。

第2-4周：基础设施

代码库在你的GitHub中，不是我们的。托管在你的账户中。WPGraphQL（或新CMS）已配置。Next.js或Astro脚手架已交付。SEO linter和重定向映射摄取已接入。设计令牌已迁移。到第四周末，基础设施已就位，团队正在交付页面。

第5-10周：构建

逐页迁移模板。首席工程师每日在你的Slack发送Loom视频。每周进行中期构建审查会议。在Linear、Jira或你已在使用的任何工具中建立工单。边界情况在出现时被捕获。这是项目的枯燥中期，大部分实际代码在此编写。

第10-12周：上线前QA

手动跨浏览器测试。移动端审计。WCAG AA无障碍审计。真实设备Core Web Vitals（非实验室Lighthouse）。SEO linter通过。Schema验证器通过。重定向映射逐URL验证对比Search Console导出。切换计划已书面制定并演练。

第12周：上线

在你选择的时间窗口进行DNS切换。大多数团队选择周二或周三上午，流量较低。前端已在测试域名上运行；切换只需要DNS翻转。工程团队待命24小时。向Search Console提交新的网站地图。在Ahrefs和GA中添加标注。

第12-16周：全力护航

每日监控Search Console是否出现索引异常、重定向链警告、结构化数据错误。每周与基准流量进行对比。优先修复bug而非开发新功能。到第16周时，网站已稳定，我们要么完成交接，要么转入持续维护计划。