为什么2025年了还有人要把WordPress拆开用？答案很简单：内容团队离不开它，但前端团队想要自由。
这不是什么复古技术怀旧，而是一个真实项目的落地记录。作者原本可以用Elementor拖拖拽拽搞定，但"每次小调整都要花比预期更长的时间"——这句话大概戳中过不少前端工程师。
这套方案到底解决什么问题
核心矛盾很典型：WordPress的后台管理确实成熟，但主题系统和页面构建器在复杂设计面前容易变成阻力。作者的选择是保留WordPress作为内容仓库（headless CMS），用Astro做服务端渲染（SSR）的前端，部署到Cloudflare Pages。
最终架构：
• WordPress装在子域名，只暴露REST API
• Astro应用挂在根域名，负责渲染和路由
• 每次git push自动触发Cloudflare部署
• 草稿预览跨系统可用
为什么选Astro而不是Next.js
原文没明说，但从技术选型可以推断：Astro的"群岛架构"（islands architecture）对内容型站点更友好，默认零JavaScript输出，需要交互的地方再注水。这比Next.js的整页水合更轻量，对SEO和首屏速度都是加分项。
Cloudflare Pages的吸引力在于边缘部署——静态资源+函数计算全球分发，不用操心服务器位置。
四个关键实施步骤
1. DNS迁移到Cloudflare
这是整个方案的地基。只有把DNS托管过去，才能统一管理子域名和边缘规则。作者强调这是"必须的第一步"，否则后续的SSL证书和边缘缓存配置会出问题。
2. 隔离CMS到子域名
WordPress被"降级"为纯内容服务，不再直接面向用户。需要配置两项：
• 告诉WordPress它实际运行在子域名（wp-config.php里加WP_HOME和WP_SITEURL）
• 写一个Must-Use插件处理两件事：所有前端请求重定向到Astro，以及草稿预览的跨域认证
这里有个细节：预览功能需要WordPress生成带nonce的临时链接，Astro端验证后从REST API拉取草稿内容。否则内容编辑的工作流就断了。
3. Astro端的核心文件结构
作者给出了五个关键文件，信息密度很高：
• Layout.astro：基础模板，注入全局样式和元数据
• blog/index.astro：文章列表页，静态生成
• blog/[slug].astro：单篇文章，服务端渲染（因为可能要预览草稿）
• sitemap.xml.ts：动态站点地图，对SEO必需
• global.css：Tailwind或自定义样式入口
[slug]路由用SSR而非SSG，是为了支持草稿预览——构建时静态生成的话，未发布内容根本不存在。
4. CI/CD配置
Cloudflare Pages原生支持Astro，但SSR模式需要额外设置：绑定Cloudflare Workers，配置NODE_VERSION环境变量，以及把WordPress API地址塞进环境变量（不是硬编码）。
安全加固不能省
Headless WordPress暴露的攻击面比传统安装更大，因为REST API是公开的。作者建议的底线：
• 限制REST API只返回必要字段（用rest_api_init钩子过滤）
• 禁用默认的用户枚举端点
• Cloudflare层面加IP白名单或认证层，保护/wp-admin
• 定期轮换应用密码（Application Passwords），别用管理员账号做API认证
这套方案适合谁
作者列出了四个典型场景，翻译一下：
• 内容团队被WordPress"绑架"，迁移成本太高
• 设计需求超出主题/页面构建器的能力边界（复杂交互、数据可视化、第三方API整合）
• 想要边缘部署和现代工具链，但不想自研CMS
• 多端内容分发：同一套WordPress喂给网站、App、小程序
反过来说，如果你的站点就是标准博客、企业官网，没特殊交互需求，这套方案属于过度设计。Elementor慢是慢点，但维护的人好找。
动手之前想清楚
这个架构的隐性成本：你需要同时维护两套系统的升级（WordPress核心、插件、PHP版本；Astro、Node、依赖库），以及它们之间的API契约。任何一边的破坏性更新都可能让预览功能或内容拉取出问题。
作者的结论是工具选择要匹配团队能力。他会写代码，所以代码比拖拽更快。如果你的团队反过来——设计师主导，工程师支持——强行上headless可能适得其反。
如果你正在评估类似方案，建议先跑通一个最小可行版本：本地WordPress + Astro dev server，验证REST API字段和预览链路，再考虑DNS迁移和边缘部署。子域名隔离那一步一旦执行，回退成本不低。
热门跟贴