在 Next.js 或 Astro 上使用 Headless WordPress，保留 wp-admin，省去插件税。

Headless WordPress 在以下三种情况之一成立时是正确的。否则默认的经典 WordPress 设置是对的，Headless 增加了工程开销，没有真实理由就不应该为之付出代价。

第一个原因是性能。一个vanilla WordPress站点加五六个插件，在H1渲染前就要加载七百千字节的JavaScript，加上Elementor或Divi再配上典型的插件栈，真实站点首次加载要跑两到三兆字节。即便在最好的缓存插件前面，Lighthouse和CrUX现场数据也有一个硬天花板。无头加上静态或ISR的Next.js或Astro前端，在共享主机上始终能清出九十五加的Lighthouse评分，现场数据随之而来。

第二个理由是工程体验不损失编辑团队。每天写 TypeScript 的工程师会对 WordPress 前端栈感到沮丧。PHP 模板、jQuery、页面生成器快捷码，语言错了，工具错了，部署流程错了。Headless 让工程团队在 Next.js 或 Astro 代码库中工作，具有版本控制、类型检查、边缘部署和组件驱动设计，同时编辑人员保持 wp-admin、Yoast 和 ACF 不变。

第三个原因是多端分发。一个营销网站、一个移动应用、一个内部门户、一个合作伙伴门户，全都从同一个内容源读取。经典WordPress是一个CMS、一个前端。无头WordPress成为你所需任何端点的编辑后端，每个端点都有针对其表面优化的前端框架。

三项决策决定了大部分工程故事。

前端框架通常是带有 App Router 的 Next.js，用于营销网站和需要认证或交互的应用。Astro 是内容密集型网站的最简路径，这些网站受益于静态生成并且只需要在特定组件上进行部分水合。当团队已经运行 Vue 时，Nuxt 是正确选择。我们默认使用 Next.js 加 WPGraphQL 加少量自定义脚手架，而不是 Faust.js，因为 Faust 附带了我们有时不同意的观点，但如果你想让框架为你做决定，Faust 也很不错。

API 层默认为 WPGraphQL。按形状类型化的查询 API，通过 WPGraphQL for ACF 支持 ACF，通过 Yoast SEO for WPGraphQL 支持 Yoast，RankMath 等价物。WP REST 无需插件就能工作，对于简单网站也没问题，但你会获取超过需要的数据，前端没有模式内省。仅当 WPGraphQL 被托管策略阻止或数据集很小时才采用 REST。

托管将前端与后端分开。前端在 Vercel、Netlify 或 Cloudflare Pages 上，取决于团队偏好。后端在 Cloudways、Kinsta 或 WP Engine 上，位于非公开子域 cms.yourdomain.com，由 Cloudflare Access 或 IP 白名单锁定。公网流量永远不会直接访问 WordPress。WordPress 对公网隐形；只有编辑人员知道它在那里。

成功的 headless WordPress 构建从 WordPress 端向公开前端传输五样东西，而不会沿途丧失保真度。

内容是显而易见的，每篇文章、页面、自定义文章类型、分类和 ACF 字段都通过 WPGraphQL 在构建或重新验证时获取。媒体其次：每个上传的图像，如果可用则使用 WordPress 端 WebP 优化，否则使用前端端图像优化。SEO 元数据是第三个，Yoast 或 Rank Math 字段通过插件伴侣 GraphQL 模式桥接，从类型化响应中呈现为规范链接、标题、描述、OG 和 Twitter 卡片。

Schema 是第四个，大多数团队处理得不对。我们用前端手写模板替换插件发出的 JSON-LD，以获得更干净的输出。Article、BlogPosting、Service、Product、BreadcrumbList，全部从类型化数据生成，在构建时验证。重定向是第五个：Yoast 重定向管理器或 Redirection 插件中的任何内容都会被导出并作为 vercel.json 或 Netlify 上的 _redirects 中的 301 重定向发布，永远不会作为 JavaScript 重定向（会在传输中失去排名信号）。

传输是自动化的。我们不会为每个网站手动构建任何这些层。相同的脚手架在我们执行的每个 headless 构建中发布，这就是为什么即使工程表面随着时间增长，每个网站的成本也下降了。

页面生成器最先损坏。Elementor 和 Divi 向前端注入重 CSS 和 HTML。都不会在 Headless 前端上运行。大多数迁移在项目中附带内容重写，我们提取内容，将其重新格式化以匹配新前端的组件库，并完全跳过导入可视生成器层。编辑人员获得基于 Gutenberg 块加 ACF 灵活内容的新的、更简单的编辑体验。内容保留，可视生成器不保留，页面权重也显著下降。

评论和表单也需要重新思考。原生 WordPress 评论无法在没有渲染代理的情况下进行无头渲染。大多数团队将其替换为 Disqus、Giscus 或前端的自定义评论系统。表单通常迁移到 ConvertKit、HubSpot Forms 或调用电子邮件发送服务的自定义 Next.js 端点。Contact Form 7 和 Gravity Forms 有无头友好的版本，但需要明确的 GraphQL 集成，这增加了工作量。

前端插件是第三个损坏的东西。任何向 WordPress 前端注入 HTML 或 JavaScript 的东西都会停止工作，安全插件、缓存插件、schema 插件、社交分享插件。每一个要么被前端代码替换，要么被托管服务替换。迁移后插件数量通常下降百分之七十到八十。这是胜利的一部分，不是回归。