结论先说：为了「 AI 生成前端」而拆 Headless，通常是亏的
Headless WordPress 值得拆的场景只有三类：多端复用同一份内容、前端需要独立的复杂交互、以及内容生产和发布节奏完全解耦。仅仅因为「 AI 生成前端代码更方便」就把主题拆掉，会白白丢掉预览、编辑器、插件生态和 SEO 默认能力。
判断的核心不是技术先进性，而是你愿不愿意为「控制权」付「基建税」。
拆与不拆：一张决策表
| 信号 | 建议 | 原因 |
|---|---|---|
| 内容要同时喂给 Web / 小程序 / App | 拆 | REST API 作为唯一内容出口，天然多端复用 |
| 前端是重交互应用（编辑器、看板、实时） | 拆 | 主题模板体系会成为负担 |
| 只是想让 AI 帮你写页面 | 不拆 | AI 同样能写区块模板和主题的 PHP/HTML |
| 站点靠插件提供核心能力（表单、会员、商城） | 不拆 | 这些能力的前端渲染绑定在主题层 |
| 团队没有专职前端 | 不拆 | 基建维护成本会吃掉全部收益 |
| SEO 是主要流量来源 | 谨慎 | 渲染方式、站点地图、结构化数据都要自己重建 |
一个实用的折中方案：不整体拆，只在需要的页面拆。用 WordPress 管内容和常规页面，把真正重交互的一两个页面做成独立前端应用，通过 REST API 取数。这样既拿到控制权，又不用为整站付基建税。
拆之前必须想清楚的四个代价
1. 预览与编辑体验要自己造
拆掉主题后，后台的「预览」按钮不再指向真实页面。要么搭预览环境，要么接受编辑看不见最终效果。这是最容易被低估的一项。
2. SEO 默认值全部失效
站点地图、 canonical 、结构化数据、标题与描述这些原本由主题和 SEO 插件自动产出的东西，需要在前端逐个重建。漏掉任何一项，代价都是真实流量。
3. 插件生态大半用不上
大量插件的能力体现在前端渲染上（表单、面包屑、相关文章、评论）。 Headless 之后这些插件只剩下后台配置界面，输出还得你自己接。
4. 认证与预发布变复杂
草稿、定时发布、权限内容都需要通过 REST API 的认证上下文处理，匿名请求拿不到未发布内容。这部分逻辑不难，但很容易被漏掉。
真要拆：四步最小路径
- 先确认 API 能拿到你要的数据：用 REST API 的 posts 端点验证标题、正文、摘要、特色图、分类是否都能取到。
_fields参数可以裁剪响应体积，只取前端真正用的字段。 - 固定数据来源约定：明确前端取数用公开端点还是需要认证的上下文。涉及草稿预览就必须带认证，否则草稿一律取不到。
- 重建 SEO 三件套：站点地图、 canonical 链接、结构化数据。这三项是 Headless 最容易丢、丢了最致命的部分，必须在第一版就补齐。
- 保留一套兜底渲染：给 API 不可用、前端构建失败的情况留一个能看的降级页面，否则一次 CI 故障就是整站白屏。
REST API 取数时的常用参数
per_page：单页条数，分页必配，默认只有 10 条。_fields：裁剪返回字段，显著降低响应体积。slug：按固定链接别名精确取单篇，比用 search 可靠得多。status：默认只返回已发布内容，取草稿需要显式指定并带认证。orderby=relevance：配合search做简单检索。
AI 在这里的正确用法
AI 生成前端代码的强项在于「把设计稿变成组件」，这与是否 Headless 无关。更划算的用法是：
- 让 AI 写区块模板和主题模板，保留 WordPress 的完整能力；
- 让 AI 生成取数层的类型定义和错误处理，减少样板代码；
- 让 AI 把既有页面批量转成结构化数据，供前端消费。
换句话说，AI 降低的是「写代码」的成本，不是「拆架构」的成本。架构决策该由业务决定，不该由工具决定。
Headless 后 SEO 一定会变差吗？
不一定，但一定会变麻烦。渲染方式、站点地图、结构化数据、 404 处理都要自己实现，做全了可以持平，做漏了就是掉流量。
API 默认返回多少条内容？
默认每页 10 条，需要分页参数控制。批量取数时用
_fields 裁剪字段，否则响应体积会很大。草稿能通过 API 取到吗？
默认不能。未发布内容需要带认证的请求上下文，匿名请求只会拿到已发布内容。预览功能必须为此单独设计。
可以只把部分页面做成 Headless 吗？
可以，而且推荐这样做。把重交互页面独立出去，其余页面继续用主题渲染，是成本收益比最高的方案。
评论 (0)