WordPress 和 Astro 都能做博客、作品集或企业网站，但起点完全不同。WordPress 自带内容管理系统：编辑后台、用户账号、媒体库一应俱全。Astro 则是一个前端框架，开发者可以自由搭建界面，再自行决定内容怎么管理。
真正决定选型的往往不是技术，而是上线之后谁来改这个站。开发者用代码维护站点，和客户要自己改服务项目、发文章、跟进询盘，需要的是完全不同的东西。
本文用一个小型 demo 对比两者的差异，不预设谁更适合所有场景。
Astro 是什么，以及它不包含什么
Astro 是一个面向内容驱动网站的开源框架。默认情况下，它在构建阶段生成 HTML 页面；借助适配器，也可以在请求时渲染路由，支持 Node.js、Netlify、Vercel、Cloudflare 等运行时和托管平台。
它的 islands 架构允许开发者只在需要的地方加入交互组件，而不必让整页都跑成客户端 JavaScript 应用。内容集合、server islands、Actions 和 sessions 支持更复杂的站点需求，但它们并不会让 Astro 变成一个开箱即用的 CMS。
Astro 背后的公司已于 2026 年 1 月加入 Cloudflare。公告中明确表示，Astro 继续以 MIT 许可证保持开源，且仍可部署到 Cloudflare 之外的平台。
用于对比的单页 demo 在构建输出目录中生成了一个 2,734 字节的 HTML 文件。这个数字只是单个产物文件的大小，并不代表包含图片、样式和其他资源后的整页体积。
Astro 从项目源码和内容生成可部署的静态文件。
Astro 本身不包含编辑后台、媒体库或开箱可用的用户管理系统。内容可以放在 Markdown、MDX 和数据文件里，也可以来自外部 CMS。
如果不接 CMS，维护内容就意味着直接操作项目文件和开发环境。接上 CMS 可以给非技术编辑提供浏览器里的操作界面，但挑选和配置这个界面本身也成了项目的一部分。
开发过程中，Astro 还提供了一条工具栏，其中的 Audit 应用会检查当前页面的无障碍与性能问题，让开发者在编写过程中就能拿到反馈。
WordPress 在同类项目里自带的东西
WordPress 从一开始就带齐了内容管理工具。编辑可以创建文章、上传媒体、管理修订版本，并通过后台直接发布。
开发者可以用 WordPress 核心 API 注册自定义文章类型和元数据。搭配自定义字段插件，可以为字段定义和编辑界面的呈现提供更方便的实现。配置得当的话，文章类型和字段也能通过 REST API 对外暴露。
对于全站级设置，开发者可以用 WordPress Settings API 构建 options page，也可以直接用带界面的插件来做。
Advanced Custom Fields PRO 包含 options page 功能，其年费方案在撰稿时为单站点 49 美元、10 站点 149 美元、不限站点 249 美元。Secure Custom Fields 是 ACF 的免费分支，同样提供 options page。
WordPress 还拥有规模庞大的插件与主题生态，站点所有者有很多现成方式来增加功能，不必每个集成都自己开发。代价是要自己挑选兼容性好的工具，并长期维护它们。
真正决定选型的问题：上线之后谁来编辑？
技术栈重要，但站点所有者在下个月要做的事情同样重要。一个小型客户站最容易看出这其中的差别。
同一个客户站在两个平台上的样子
我手上的客户站通常都有 options page、自定义文章类型和自定义字段。客户在 options page 上修改公共设置，并通过一组固定字段录入内容。
在 WordPress 上，这些操作都在同一个后台里完成。发一篇新文章或更新已发布的内容，改动即时可用，无需单独跑一次前端构建——当然，缓存可能让访客暂时看不到最新状态。
在 Astro demo 里，等价结构是用一个内容集合承载项目内容，用一个设置数据文件存放共享的业务信息，再由一份 Zod schema 定义字段结构并校验取值。
schema 定义了预期的内容结构，能帮你拦住不合法数据。
但 schema 只做校验，不会凭空生成编辑界面。要让客户不打开项目文件就能管理这些字段，就必须再接入一个 CMS。
之后页面读取设置文件和集合条目，用它们来渲染设计。在这个 demo 中，工作室信息来自设置文件，项目卡片来自内容集合。
给 Astro 选一层编辑能力
接入 CMS 大致有几条路：
- 基于 Git 的编辑：Keystatic、TinaCMS、CloudCannon 这类工具直接管理存放在代码仓库里的内容。
- 托管内容平台：如 Sanity，内容单独存储，通过 API 提供给前端。
- Headless WordPress：WordPress 负责编辑环境，Astro 拉取内容并构建面向访客的页面。
从设置页到编辑体验：Astro 上的内容管理长什么样
Keystatic 提供了一个很直观的参照：一套基于文件的内容管理系统。它采用的「单例（singleton）」模型，本质上类似 WordPress 里通过选项页（Options Page）管理的那类全局共享内容数据。
在运行方式上，Keystatic 的本地模式直接写入本地文件系统，适合开发阶段快速迭代；如果要部署成对外可用的编辑界面，官方文档推荐接入 GitHub 工作流，也可以用 Keystatic Cloud 简化认证环节。无论走哪条路，部署态的集成都需要一个兼容的服务端运行时来支撑。
一个值得注意的工程细节：在示例项目中，同一组字段定义既存在于 Astro 的校验 schema 里，也写在 CMS 配置中。这两处定义必须保持一致——共用同一份定义，或者补上额外校验都可以，但这份「对齐」工作本身就是实现成本的一部分。
一次编辑多久能上线
这是两类平台差异最容易被低估的地方。
在传统 WordPress 站点上，发布或更新内容不需要重新构建前端，变更直接通过 WordPress 生效，速度主要受缓存和既有发布流程影响。
而静态生成的 Astro 站点，内容变更通常会触发一次构建与部署。Git 提交或 CMS webhook 可以自动启动这个过程，但访客要等部署完成后才能看到更新页面。构建耗时取决于内容规模、集成数量和托管环境。
Astro 在 7.2 版本中引入了实验性的增量静态构建（experimental incremental static builds），可以复用那些代码和内容都没有变化的页面，从而压缩重建范围。
还有一条折中路径：如果某个 Astro 路由在请求时拉取 CMS 的当前内容，就能在不重新构建该路由的前提下展示更新——但它的新鲜度依然取决于缓存策略和数据获取方式。
对客户来说，他们未必关心你选了哪套技术栈，但一定关心日常改动是否省心、可靠。选型之前更该先回答三个问题：站长（内容所有者）能改什么、预览是怎么运作的、已发布的变更什么时候真正对外可见。
在 Astro 上重做 WordPress 的常见功能
WordPress 插件的价值，是把大量成熟的站点功能打包成可直接安装的产品。而到了 Astro，等价能力往往要由 CMS、托管服务、JavaScript 包或自定义集成来拼装。Astro 本身已支持图片处理和国际化路由，官方集成涵盖 sitemap、RSS 等功能，官方文档主题 Starlight 还自带搜索。真正拉开差距的，是表单、电商、账号体系和可视化编辑这几类需求。
表单
Astro Actions 和按需 API 端点可以处理提交，但存储、邮件投递、反垃圾机制和提交记录管理仍需开发者自行接入。另一种做法是让表单直接提交到外部服务，公开页面就能继续保持静态。
相比之下，WordPress 表单插件把更多流程封装进了后台仪表盘。像 Divi 这类页面构建器，还提供了对 Gravity Forms、Contact Form 7 等插件表单的样式集成能力。
电商
Astro 能支持结账链接、嵌入式支付服务，以及对接电商 API 的自定义店铺前台，但不自带商品与订单管理后台。其电商指南中提供了 Lemon Squeezy、Paddle、Snipcart 等服务示例——不过这些示例代表的是文档给出的起点，而非技术上限。
WooCommerce 则把商品、购物车、结账和订单管理完整放在 WordPress 内部；Divi 的 WooCommerce 模块则进一步提供店铺页面的可视化设计控制。
账号与会员
WordPress 自带用户和角色体系，插件在此基础上延伸出会员、课程、客户门户等场景。Astro 可以集成 Better Auth、Clerk 等认证工具，但站点自身的权限规则和会员功能仍要开发者实现。有登录会话，不等于有完整的会员系统。
可视化编辑
WordPress 内置区块编辑器，Divi 的 Visual Builder 提供所见即所得的页面搭建能力；Astro 框架本身没有等价编辑器。CloudCannon 等服务及其他 CMS 集成可以补上可视化编辑，具体能力取决于所选服务及其实现深度。
从规划角度看，几个维度的差异可以这样归纳：
- 内容编辑：WordPress 自带后台仪表盘；Astro 依赖项目文件或额外接入的 CMS。
- 常见站点功能：WordPress 有成熟的插件工作流；Astro 把选型和拼装的责任更多交给开发者。
- 设计改动：WordPress 的编辑器与构建器暴露设计控件；Astro 的可编辑设计能力取决于集成方案。
- 长期成本：要把托管、授权、服务订阅、开发与维护都纳入完整方案的比较，而不是只看单一维度。
性能：数字说明了什么，又没说明什么
Astro 官网首页展示过一组 Core Web Vitals 对比数据：Astro 约为 71%，WordPress 约为 48%（文章使用的是 2026 年 8 月的对比）。这确实构成了选择 Astro 的实际理由之一——它默认的渲染方式更容易用更少的前端 JavaScript 交付内容。
但这组数字需要正确解读：它比较的是两类网站的整体样本，而不是同一个团队把同一个项目分别用两套技术构建两遍。WordPress 覆盖的站点构成要宽泛得多，其中包含大量老旧安装，以及预算、维护规范差异很大的项目。
这些数字可以作为参考背景，却无法预测单个项目的实际表现。Astro 站点同样可能因为交互组件、分析脚本和第三方服务而加载相当可观的 JavaScript——框架自身轻量，不等于成品页面轻量。在 WordPress 上，主题选择、插件行为、托管、缓存和图片处理同样会左右结果。更可靠的做法，是在上线后的真实站点上测试代表性页面和关键交互，而不是只看平台名字。
安全与维护：静态化省下的不是全部
完全静态的 Astro 部署直接分发生成好的文件，公网访问时不需要运行 WordPress、PHP 插件或数据库来渲染每个页面，这确实消除了若干常见攻击面。
但维护并没有随之消失。项目依然有依赖包、部署凭证，以及任何被接入的 CMS 或服务需要加固。一旦加入服务端渲染路由、认证或自定义端点，责任面又会进一步扩大。
也就是说，选择 Astro 换来的是更少的运行时攻击面，但并没有更少的运维责任——只是责任的重心从「维护 WordPress、插件和数据库」转移到了「维护代码依赖、构建流水线和外部服务集成」。
对于准备从 WordPress 迁往 Astro 的团队，这才是评估时最需要提前想清楚的部分：静态生成带来的性能与安全收益，是否足以覆盖迁移过程中重建表单、电商、会员和可视化编辑流程的成本，以及此后由团队自己承担的那部分维护责任。
WordPress 与 Astro：两套维护逻辑正在分化，AI 工具开始长进平台内部
在把「下一个站点做 WordPress 还是 Astro」当成一道选择题之前，先要清楚一件事：这两个平台的维护曲线完全不是一回事。WordPress 面临的是生态级的漏洞披露压力与插件治理问题，Astro 面临的则是工程级的构建与部署复杂度。而 2026 年以来真正在改变判断的，是 AI 能力开始以「官方基础设施」的形式进入平台内部，而不再只是第三方插件的附加项。
Patchstack 在 2026 年 WordPress 安全报告中记录：2025 年整个 WordPress 生态共披露 11,334 个漏洞，比 2024 年增长 42%；其中约 91% 来自插件，核心代码另有 6 个低优先级问题。
需要厘清的是，这些是生态范围内的披露总量，并不意味着每个 WordPress 站点都存在这些漏洞。某个具体站点的风险敞口，取决于它实际装了哪些软件。
因此成熟的 WordPress 实践是一套组合拳：只使用少量经过验证的插件，在合适的地方接入漏洞监控，再配合及时更新、经过测试的备份、访问权限控制，以及一套替换已弃用软件的预案。托管环境的防护是另一层防线，不能替代应用本身的维护。
核心变化：AI 工具嵌入平台骨架
WordPress 侧
- Abilities API（WordPress 6.9 引入）允许开发者以机器可读的形式注册能力（abilities）。
- WordPress 7.0 加入 AI Client，为插件提供了一个统一的 PHP 接口来对接各类 AI 服务提供商。
两者都是面向开发者的基础设施——最终用户能用到哪些功能，取决于站点实际安装和配置了哪些工具。
具体落地上，官方 MCP Adapter 可以把已注册的能力暴露给兼容的客户端；构建者也会自行添加工具。Divi 的 AI Agents 则直接工作在 Visual Builder 内，用自然语言指令就能创建页面，以及新增、编辑、移动模块。
Astro 侧
Astro 的 AI 工具文档重点是让编码 Agent 能顺畅处理 Astro 项目，其文档 MCP Server 让兼容工具可以直接访问 Astro 官方文档。
差异在哪里
两者都能配合编码 Agent 使用，实际差别在于工作流发生的位置：集成在 WordPress 内部的工具可以在既有编辑环境中就地工作；而典型的 Astro 编码工作流会直接改动项目文件，并让这些变更走完构建与部署流程。
中间路线：WordPress 负责编辑，Astro 负责前端
把 WordPress 当作 Astro 前端背后的 headless CMS 是一种可行组合：编辑人员继续使用熟悉的 WordPress 后台，Astro 通过 API 拉取内容并决定公开页面的渲染方式。
但这条路同时带来两层应用栈的维护成本，需要提前规划：内容拉取机制、预览、必要的鉴权，以及发布后的变更如何触达访客。
- 对静态页面，通常意味着内容变更就触发一次重新部署。
- 按请求实时拉取内容的路由可以避开重建需求，但要看它的缓存策略。
Astro 的 headless WordPress 指南提供了获取文章与自定义文章类型的起点；自定义字段和全站级设置仍需额外配置。例如 ACF 的文章字段，在对应字段组开启 Show in REST API 后即可出现在 REST 响应中；而 Options 页的值需要单独处理，比如通过一个安全配置妥当的自定义端点，或使用合适的集成方案。只向前端暴露你确实打算公开的数据。 需要说明的是：作者本人并未为客户落地过这种混合架构，所以它应当被当作一次独立的架构决策来评估，而不是默认它比两者中任何一个都更省事。
影响与建议：按场景选型
| 站点类型 | 更合适的选择 | 理由 |
|---|---|---|
| 开发者自维护的营销站 | Astro | 开发者主导内容流程，需要对标记、资源与集成有直接控制权 |
| 文档站 | Astro + Starlight | 面向结构化文档的专注起点 |
| 客户站（共享设置 + 结构化内容） | WordPress | 编辑后台本身就是平台的一部分，交付更直接 |
| 电商 | WordPress + WooCommerce | 店铺管理内置于站内；若要自定义店面并对接独立电商平台，可考虑 Astro |
| 会员与课程 | WordPress | 有成熟插件把访问控制、支付与编辑工具打包；Astro 能做，但集成工作量更大 |
| 博客 | 视团队而定 | 喜欢文件式发布流的开发者适合 Astro；写手与编辑需要浏览器端发布、定时与版本回退时，WordPress 通常更省事（部分 Astro CMS 集成也可提供这些能力） |
落地步骤：先跑通一条日常链路
在正式选定之前，把一件日常事务从头到尾完整测一遍：
- 更新一个共享设置；
- 发布一条内容；
- 预览变更；
- 确认它何时真正到达线上站点。
这一步能告诉你的东西，比任何框架跑分都更有参考价值。
最终判断
对作者自己的客户站而言，WordPress 依然务实：我已有成熟的开发流程、熟悉的插件与主题生态，以及客户能直接上手的编辑环境，AI 工具也让这套流程更顺。Astro 值得考虑的前提是它的取向与项目匹配——由开发者掌控布局、以内容为中心的页面，以及一支准备好挑选并维护周边服务的团队。它的灵活性有价值，但编辑体验需要和前端一样多的规划。
如果想探索基于 Astro 的 CMS，Cloudflare 的 EmDash 是另一个值得评估的选项。
What Is a Theme Builder? Site Building With WordPress
发布于 2026 年 8 月 27 日，分类 WordPress
Is AI Going to Kill WordPress?
发布于 2026 年 8 月 14 日，分类 WordPress
2026 年做博客，WordPress 主题还重要吗？——从「AI 会不会杀死 WordPress」的争论说起
如果现在去问一圈「AI 会不会让 WordPress 被淘汰」，你会得到完全相反的答案。有人笃定地认为 WordPress 基本上已经完了——没人会理智地在今天还从零开始一个新站点；而另一批人依旧在持续更新维护自己的站点、主题和插件生态。
这种分歧本身值得注意。它更多反映的是内容生产方式的变化，而不是技术栈的更替。而在这个背景下，一个更实际的问题被摆到了台面上：做博客时，主题到底还承担什么角色？
核心变化：主题的职责从「做模板」变成「不打扰你」
原文给出的判断相当克制，也相当清晰。运行一个博客时，底层主题应该同时做到两件事：
- 写作时不碍事——不打断编辑体验，不塞进多余模块和弹窗；
- 让站点看起来是你自己的——而不是一眼看穿的模板货色。
这两条要求，在 2026 年和十五年前是完全不同的权重。早期建站更多是「能不能跑起来」，今天则是「能不能在海量模板中一眼被认出来」。文章原话是：如今开始写博客，和十五年前已经是两回事了。
另一条变化同样明确：随着 AI 写作和内容生产工具的普及，内容本身不再是瓶颈，站点辨识度和写作体验才是。这直接改变了主题的取舍标准——那些只靠「漂亮」取胜、但写作时处处添堵的主题，在 2026 年逐渐失去吸引力。
影响与建议：怎么挑，怎么落地
原文给出的对比主线是面向博主的 7 款 WordPress 主题横向比较（2026 年 8 月 4 日更新于 WordPress 主题分类）。就选型方法而言，可以拆成几个可操作的维度：
选型维度
- 写作优先：编辑器体验、快捷键、专注模式、全屏写作是否顺畅；
- 视觉可定制：是否支持自定义区块、配色、字体、页头页脚与导航，而不必依赖子主题硬改；
- 性能与体积：主题包体、字体与图标加载、首屏渲染；
- 模板之外的扩展位：是否自带作品集、联系表单、邮件订阅等博客常用模块；
- 可维护性与生态：更新频率、主题被弃用的风险、配套插件的兼容性；
- SEO 与可访问性：结构化数据、语义化标签、对比度与键盘可达性。
人群与场景建议
- 刚开始写、还没想清楚风格：优先选「默认即干净」、改色改字就能用的主题，把时间留给内容；
- 已有稳定读者、想做出辨识度：选区块化、可深度定制的类型，配合自定义页面模板做封面页、归档页；
- 以图文内容为主、需要大量图集：关注图片区块的默认样式、灯箱与懒加载表现；
- 做的是专业站/作品集：优先考虑带完整区块库和整站模板（Patterns）的主题，减少从零拼装的成本。
落地步骤
- 先用两三款候选主题跑通一篇真实文章，而不是只看首页截图；
- 在移动端和窄屏下复核写作页与阅读页的实际观感；
- 检查主题的默认字体和配色是否与你的阅读长度、图文比例匹配；
- 确认关键功能（搜索、订阅、表单、分享）是否需要额外插件，避免主题与插件互相冲突；
- 上线前做一次性能与可访问性检查，并记录主题版本，便于日后回滚。
需要说明的是：原文这一段的完整 7 款主题逐项对比清单（含每款的具体优缺点）并未包含在本段内容中，这里只保留了它给出的核心判断与选型框架，具体名单与逐项说明请以原文为准。
