文 | 跨屏互联
先说两个真实留言。
读者 A：我用 Codex 生成了一个详情页，很好看。但怎么把它搬进 WordPress？难道只能在 WP 里照着手抄一遍？
读者 B：我试了用 wpAPI 接入 Codex 写的页面，接是接上了——但所有 WordPress 插件全废了，SEO 插件不工作、表单也不跳了，WP 沦为了一个纯内容库。
这两个问题放在一起，刚好暴露出一个绝大多数教程从来不提的前提：在你动手"怎么搬"之前，得先想清楚——WordPress 在你这个站里到底扮演什么角色。角色定错了，后面每一步都拧巴。读者 B 的困境就是这么来的。
AI 页面只是个原型，别当成品
让 Codex 生成一个页面，门槛已经很低了。给它目标、模块结构、参考风格和文案，几分钟产出一个看起来完整的 HTML。
但最容易误判的一点：页面能在浏览器打开，不代表它适合 WordPress。WordPress 不是空白网页文件，它有主题、插件、编辑器、模板，还有"以后谁来改"的问题。拿到 AI 页面后先别问"代码怎么复制进去"，先问三件事：这页以后谁来改？是一次性活动页还是长期复用？最关键的——WP 是来渲染页面的，还是只当内容后台？
先定岔路：WP 是"渲染页面"还是"只当后台"？
这是整件事的分水岭。WordPress 有两种完全不同的用法，读者 A 默认选第一种，读者 B 不知不觉走进了第二种。
用法一：WP 渲染前端。访客打开网站，WP 自己用主题、插件、PHP 把页面拼出来。你装的 SEO 插件、表单插件、缓存插件，都是在这个渲染过程里生效的。绝大多数 WP 站是这种。
用法二：WP 只当内容后台（headless / 无头）。前端用 Codex 或 Next.js 单独做，WP 退到后面，只通过 API 把内容吐出来当数据。这就是读者 B 做的事——一旦前端不再由 WP 渲染，那些靠渲染生效的插件（SEO、表单、页面构建器、缓存）自然全部失效。这不是他配错了，这就是 headless 的定义。这些插件干的事，你得在前端全部重新写一遍。
别急着选赛道，先回答两个问题：
第一，你吃不吃 SEO 插件红利？如果你的站靠搜索流量、靠 Yoast 或 Rank Math 自动生成 meta 和 sitemap——那 headless 是逆风。传统用法下这些 SEO 信号直接写进 Google 抓取的 HTML；headless 下全得自己在前端实现，还得确认服务端渲染，否则爬虫抓到一张空页。对内容站和独立站这种吃自然流量的，传统用法通常更稳。
第二，改内容的人是不是非技术？传统用法下运营在后台填字段、点预览、发布，闭环顺畅。headless 下预览和编辑体验都要额外搭，运营容易被卡住。
判断很明确：如果你是做 SEO 内容站或独立站，团队里改内容的主要是运营，优先用法一。headless 不是不能用，但它把"省下的前端自由"换成了"自己重写 SEO 和表单、维护两套系统"——对大多数独立站，这笔账不划算。
如果选用法一（WP 渲染前端）：按页面类型落地
回到读者 A 的问题——AI 写好的页面怎么搬进 WP？答案是：不用手抄，但也别直接贴代码。中间那条最值得走的路是：把 AI 那段 HTML/CSS 做成一个 WP 自定义区块，标题、图片、文案都变成后台可填的字段。运营改内容不碰代码，前台渲染出来还是 AI 那套样式。
按三种页面类型分：
营销页。首页、服务页、活动页、Landing Page，上线后经常改文案换图调 CTA。首选做成自定义区块，让 Codex 出 HTML/CSS 原型，技术把每个模块封成区块（用 ACF Blocks 最容易上手），AI 的视觉几乎原样保留。备选：用 Elementor 或 Gutenberg 复刻——但构建器有自己的 DOM 和样式系统，很难像素级还原 AI 布局，而且嵌套深会拖累页面性能。越在意 SEO 和页面干净，越该走区块而不是构建器。
单个特殊模块。流程图、对比表、FAQ、CTA——只是一个模块想做得特别一点。一次性验证可以直接裸嵌 HTML/CSS，但要记住：如果模块里含 script、iframe、style 标签，WP 会对没有权限的账号自动过滤——普通编辑保存后直接清掉。所以一次性可以用裸嵌；要长期改、要在多个页面复用，直接做成区块。
大量同类型详情页。产品、案例、服务详情页，绝对不该每页照着 AI 手抄。正解是把 AI 页面当原型，让技术拆成 WP 模板加自定义区块加 ACF 字段。以后新增同类页面只填内容，不重搭。标题、图片、卖点、参数、FAQ 全变成后台可维护的字段。
进阶选项：让 AI 通过 MCP 直接驱动 Elementor。已经有社区插件把 Elementor 变成一个 MCP server，挂上之后 Claude 这类 agent 能直接在 Elementor 里建页面——等于 AI 建出来的页天生就是 Elementor 页面，运营照常在编辑器里改，SEO 插件照常工作。这条路绕开了 headless 全部代价，也省掉"得先有人会封区块"的技术门槛。但还比较早期，先用测试站验证，别一上来就在正式站搞。
如果选用法二（headless）：你要自己接管什么
如果你确实需要纯前端的自由，决定走 headless，那心里要有数：WP 只剩"内容库"这一个职能，下面这些原来插件替你干的活，现在全归你自己写。
SEO：meta、canonical、结构化数据、sitemap，全部在前端生成，WP 那边的插件不作数了。务必确认页面是服务端渲染而不是纯前端渲染，否则爬虫抓到空页——这是 headless 最常见也最致命的 SEO 坑。表单要走 API 提交或第三方服务。预览要自己搭。缓存归前端托管层管。
什么时候这条路才值得走？你本来就有前端开发能力、对自由度要求很高、并且有人负责把上面这套 SEO 重写到位。否则，读者 B 的体验就是常态。他没做错，他只是走上了一条"自由换重写"的路。如果站吃 SEO 又不想重写这套，回到用法一会舒服得多。
改主题前先看风险
让 AI 动主题文件之前，至少说清楚：改哪个文件、影响哪些页面、数据从哪读、改错怎么回滚、有没有测试环境先验。尤其不要直接改 parent theme——主题一更新手改全被覆盖，要改也放 child theme 里。没有测试站、备份、回滚，就别让 AI 直接动正式站。
我现在的完整顺序：先定角色（渲染还是后台）；整理页面目标；让 Codex 出几个 HTML 原型试出设计方向，然后提炼成一份 design 规范文件，之后每页都前置读这份规范；按页面类型落地（营销页和详情页优先做区块，一次性模块裸嵌，要强自助又没有技术封区块的才退回构建器）；改主题先上测试站。
---
回到那两条留言。
读者 A（怎么搬进 WP）：不用手抄。把 AI 页面封成自定义区块和模板，运营后台填字段就行——搬运、复用、维护三者兼得。
读者 B（接了 API 插件全废）：你没配错。你走的是 headless，代价是 SEO、表单、预览全得自己重写。吃 SEO 的内容站，让 WP 继续渲染前端更稳。
而这两个答案的前提是同一个判断：先定 WordPress 的角色，再谈怎么落地。Codex 解决的是"页面生成得快不快"，WordPress 解决的是"上线后能不能编辑、维护、复用"——别把这两件事混成一件。
我们 跨屏互联 做 WordPress 独立站开发十多年，见过太多把 AI 生成的 HTML 直接当成品、结果上线后运营改不动的翻车案例。下次用 Codex 做页面之前，先在需求里写清楚：这页属于哪种角色、以后谁来改。先想清楚怎么用，再决定怎么落地。
---END---
申明：若有来源错误或者侵犯您的合法权益，您可以通过邮箱与我们取得联系，我们将及时进行处理，邮箱地址：info@kuaping.com
