无头WordPress配合Next.js或Astro — 保留wp-admin，摆脱插件税。
WPGraphQL、ACF、Faust.js、ISR、预览模式、完整SEO传输。一万二千个WordPress站点的实践经验遇上现代前端。编辑保留他们熟悉的工具，公网站点去掉了臃肿。
什么时候应该用无头WordPress
当以下三种情况之一成立时，无头WordPress才是正确选择。否则默认的经典WordPress设置才是对的 — 无头增加了工程开销，你不应该没有真正的理由就为它买单。
第一个原因是性能。一个vanilla WordPress站点加五六个插件，在H1渲染前就要加载七百千字节的JavaScript，加上Elementor或Divi再配上典型的插件栈，真实站点首次加载要跑两到三兆字节。即便在最好的缓存插件前面，Lighthouse和CrUX现场数据也有一个硬天花板。无头加上静态或ISR的Next.js或Astro前端，在共享主机上始终能清出九十五加的Lighthouse评分，现场数据随之而来。
第二个原因是工程体验，同时不失编辑团队。每天写TypeScript的工程师对WordPress前端栈感到沮丧。PHP模板、jQuery、页面生成器短代码 — 语言错了，工具错了，发布流程错了。无头让工程团队在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 卡。
模式是第四项，大多数团队处理错误。我们在前端用手写模板替换插件发出的 JSON-LD，以获得更清晰的输出。Article、BlogPosting、Service、Product、BreadcrumbList —— 全部从类型化数据生成，在构建时验证。重定向是第五项：Yoast 重定向管理器或 Redirection 插件中的任何内容都会被导出并作为 vercel.json 中的 301 或 Netlify 上的 _redirects 发送，永远不会作为 JavaScript 重定向，那会在传输中丧失排名信号。
传输是自动化的。我们不会为每个网站手动构建任何这些层。相同的脚手架在我们执行的每个 headless 构建中发布，这就是为什么即使工程表面随着时间增长，每个网站的成本也下降了。
什么会出问题以及我们如何处理
页面构建器首先出问题。Elementor 和 Divi 在前端注入大量 CSS 和 HTML。这些都无法在无头前端上运行。大多数迁移项目都包括内容重写——我们提取内容，将其重新格式化以匹配新前端的组件库，完全跳过导入可视化构建器层。编辑人员获得基于 Gutenberg 块加 ACF 灵活内容的新的、更简洁的编辑体验。内容得以保留，可视化构建器不再使用，页面权重因此大幅下降。
评论和表单也需要重新思考。原生 WordPress 评论无法在没有渲染代理的情况下进行无头渲染。大多数团队将其替换为 Disqus、Giscus 或前端的自定义评论系统。表单通常迁移到 ConvertKit、HubSpot Forms 或调用电子邮件发送服务的自定义 Next.js 端点。Contact Form 7 和 Gravity Forms 有无头友好的版本，但需要明确的 GraphQL 集成，这增加了工作量。
前端插件是第三个出问题的地方。任何在 WordPress 前端注入 HTML 或 JavaScript 的东西都会停止工作——安全插件、缓存插件、架构插件、社交分享插件。每个都要么被前端代码替换，要么被托管服务替换。迁移后，插件数量通常下降百分之七十到八十。这是优势的一部分，不是倒退。