Last updated: 2026-06-26

Last verified: 2026-06-26 for draft-level Cloudflare Pages and WordPress.org source check. Exact Cloudflare limits, WordPress requirements, hosting prices, plugin behavior, and provider claims must be re-checked before publication.

OnlyPat 建站指南 is an independent guide-site project. This draft is not Cloudflare, WordPress.org, WordPress.com, Automattic, hosting-provider, or registrar official documentation and does not imply affiliation with any provider.

先说结论

Cloudflare Pages 和 WordPress 没有绝对赢家。

如果你要做的是静态优先的网站，比如指南站、文档站、作品集、落地页、简单项目页，Cloudflare Pages 往往更轻、更干净，也更适合低成本起步。

如果你从第一天就需要可视化后台、非技术人员频繁编辑、成熟插件生态、会员、预约、商城、复杂表单或传统 CMS 工作流，WordPress 往往更直接。

真正要比较的不是“哪个更高级”，而是：

  • 你的第一版网站到底要完成什么任务；
  • 谁来更新内容；
  • 是否需要后台；
  • 是否依赖插件；
  • 是否能接受 Git、Markdown 或模板工作流；
  • 复杂功能是不是可以后面再加。

这篇文章会帮你把选择变成一个清楚的判断，而不是在两个名字之间纠结。

如果你读完后还想继续拆，可以接着看三篇配套文章：Cloudflare Pages 免费建站指南：适合什么，不适合什么、静态网站和动态网站到底有什么区别、用 90 天搭一个 Cloudflare 指南站的路线图。它们分别帮你确认 Pages 是否适合、静态和动态的边界在哪里，以及第一版应该按什么顺序推进。

30 分钟开工版

先不要选技术栈。

先填这张表：

问题 如果答案偏左 如果答案偏右
网站主要是什么？ 文章、指南、文档、落地页 会员、商城、后台、复杂内容管理
谁更新内容？ 你自己或少数懂流程的人 多个非技术编辑
内容怎么写？ Markdown、模板、版本管理可以接受 必须浏览器后台可视化编辑
是否需要插件生态？ 暂时不需要 强依赖表单、SEO、会员、商城、预约等插件
是否需要数据库？ 第一版不需要 第一版就需要
是否能先上线简单版本？ 可以先静态发布 必须一次具备 CMS 功能
是否能接受技术流程？ 可以接受 Git 或构建流程 不想碰部署和构建

左边多，优先考虑 Cloudflare Pages。

右边多，优先考虑 WordPress 或其他 CMS/建站平台。

如果左右都有，说明你的项目可能需要分阶段：第一版用静态站验证内容，后面再看是否接 CMS、后台或动态功能。

做到这里就可以停。现在不要创建 Cloudflare Pages 项目，不要买 WordPress 主机，也不要开始迁移内容。先把表格里的“第一版必须有”和“以后再加”分开，技术选择才不会被未来假设带偏。

先理解两种模式

Cloudflare Pages 更像是静态网站的发布平台。

你把网站内容构建成静态文件，然后通过 Cloudflare Pages 发布出去。它支持 Git 集成，也支持 Direct Upload 这类上传方式。[Official fact - recheck before publishing] 如果需要一些后端式逻辑，可以再结合 Pages Functions 或 Workers 之类的能力，但这已经是额外架构设计。[Official fact - recheck before publishing]

WordPress 更像是一个数据库驱动的内容管理系统。

你登录后台写文章、管理页面、安装主题和插件。WordPress.org 当前官方要求里会列出运行 WordPress 推荐的 PHP、数据库和 HTTPS 等环境要求。[Official fact - recheck before publishing] 这意味着 WordPress 不是单纯上传一堆静态文件，而是需要运行环境、数据库、主题、插件和更新维护。

一个简单比喻：

  • Cloudflare Pages 更像把做好的书页放到一个快速分发系统里；
  • WordPress 更像一个带后台、编辑器、主题和插件仓库的出版系统。

这两种模式都能做网站，但运营方式不同。

Cloudflare Pages 适合什么项目

Cloudflare Pages 适合静态优先的网站。

比如指南站。大多数文章对每个访问者都是一样的，不需要每次访问都查询数据库。你可以先写内容、组织结构、做内链、准备清单和模板。

比如文档站。产品说明、教程、FAQ、帮助中心，很多都适合静态生成和版本管理。

比如作品集和个人主页。页面数量可控，内容更新不算频繁，重点是访问速度和表达清楚。

比如落地页和活动页。第一版通常只需要清楚说明、按钮、表单或联系路径，不需要复杂后台。

比如小型前端工具。只要数据不需要保存到服务器，也不涉及隐私或复杂账号体系，就可以先作为浏览器端工具规划。[Future implementation note]

对 OnlyPat 建站指南 来说，Cloudflare Pages 很适合第一版方向：[Editorial judgment]

  • 文章是核心；
  • 内容可以静态发布；
  • 前期不需要会员系统；
  • 可以先用清单、模板和服务线索验证信任；
  • 后面如果需要工具，再单独设计。

这不代表已经授权创建 Pages 项目或框架。当前仍然只是文档规划。

WordPress 适合什么项目

WordPress 适合需要成熟 CMS 工作流的网站。

如果你需要多人通过浏览器后台写文章、编辑页面、上传媒体、管理分类，WordPress 的后台体验更直接。

如果你需要大量现成主题和插件，WordPress 生态很成熟。表单、SEO、缓存、会员、商城、预约、邮件订阅、页面构建器等，都有大量插件和服务可选。

如果你的网站从第一版就需要内容后台，或者站点所有者不想碰 Git、构建、部署、Markdown，WordPress 可能更省心。

如果你已经熟悉 WordPress，或者团队已有 WordPress 运维、编辑和安全更新流程，也没必要为了“更现代”强行换成静态站。

但要记住：插件多不是免费午餐。插件越多，更新、兼容、安全、性能和维护问题也越需要管理。

编辑工作流怎么选

这是很多人真正会卡住的地方。

Cloudflare Pages 的典型工作流更偏开发者或半技术内容工作流：

  • 用 Markdown、模板或组件写内容；
  • 把内容放在仓库里；
  • 通过 Git 提交触发构建和部署；
  • 改动有版本记录；
  • 发布更可控，但上手门槛更高。

WordPress 的典型工作流更偏后台编辑：

  • 登录后台；
  • 用编辑器写文章；
  • 选择分类和标签；
  • 上传图片；
  • 点击发布；
  • 用主题和插件扩展功能。

如果你的内容团队里有多个非技术编辑，WordPress 会更自然。

如果网站主要由你自己维护，并且你愿意用版本管理管理内容，Cloudflare Pages 会更干净。

对一个指南站来说，Markdown 和 Git 工作流的好处是：每篇文章的修改都能追踪，内容结构更容易保持一致，也更适合把文章、清单、模板放在同一个项目里管理。

但如果这个工作流让你写不下去，那就不是好方案。能持续发布，比技术洁癖重要。

成本怎么比较

不要只比较“托管费”。

Cloudflare Pages 可以从低成本路径起步，但免费计划、构建次数、文件大小、项目数量、Functions 相关限制等都要以当前官方限制页为准。[Official fact - recheck before publishing]

WordPress 的成本取决于很多因素：

  • 主机或托管 WordPress 服务；
  • 域名；
  • 主题；
  • 插件；
  • 备份；
  • 安全；
  • CDN；
  • 邮件和表单服务；
  • 维护时间。

有些 WordPress 站可以很便宜，有些会因为插件、主题和托管服务变贵。Cloudflare Pages 也不是完全零成本，因为域名、内容生产、设计素材、工具和后续动态服务仍然可能花钱。

更合理的比较方式是：

成本项 Cloudflare Pages WordPress
托管起步 可低成本起步，需复核限制 取决于主机或托管服务
域名 仍然需要 仍然需要
内容编辑 需要内容工作流 后台更直接
主题/模板 可用静态模板 主题生态成熟
插件 不依赖传统插件生态 插件生态强
维护 依赖构建、依赖和域名管理 依赖核心、主题、插件、安全更新
动态功能 需要单独设计 很多功能可用插件起步

不要问“哪个一定更便宜”。应该问“我的第一版需要哪些能力，哪些成本是必须的”。

维护成本怎么比较

Cloudflare Pages 的维护重点是内容、构建、依赖、域名、DNS、HTTPS 和部署流程。

如果网站是静态优先，维护面会比较小。你不需要维护传统服务器，也不需要为每个页面访问运行数据库查询。

但它仍然有技术维护：

  • 构建工具要能跑；
  • 依赖要更新；
  • 内容结构要保持；
  • 域名和 HTTPS 要正常；
  • 后续如果加 Functions 或 Workers，还要维护代码和配额。

WordPress 的维护重点是核心版本、主题、插件、数据库、备份、安全、性能和主机环境。

WordPress 成熟，但也意味着你要认真对待更新。插件冲突、主题兼容、后台安全、垃圾评论、性能优化，都是常见维护面。

所以，WordPress 不等于“完全不用管”。Cloudflare Pages 也不等于“永远不用维护”。只是两者维护的东西不一样。

SEO 该怎么判断

Cloudflare Pages 和 WordPress 都可以做 SEO。

不要相信“某个平台自动排名更好”。

真正影响搜索表现的，通常是这些东西：

  • 内容是否有用；
  • 标题是否匹配搜索意图；
  • 页面是否可抓取；
  • 内链是否清楚；
  • 移动端是否可读；
  • 速度和稳定性是否合理；
  • 是否有原创经验和更新；
  • 是否避免低价值页面。

WordPress 有成熟 SEO 插件，可以帮助配置标题、描述、sitemap、schema 等。Cloudflare Pages 也可以通过静态站点生成器和构建流程做好这些，只是需要你在代码或模板层面设计。

所以 SEO 不应该是唯一选择依据。

如果你能持续写好内容、维护结构、更新页面，两个方向都能做。

动态功能怎么比较

动态功能是分水岭。

如果你第一版就需要这些功能，WordPress 或其他动态 CMS 可能更直接：

  • 多用户后台；
  • 会员系统；
  • 商品和订单；
  • 预约；
  • 评论管理；
  • 大量表单；
  • 可视化页面搭建；
  • 非技术编辑工作流。

如果你第一版主要是这些内容，Cloudflare Pages 更合适：

  • 文章；
  • 指南；
  • 文档；
  • 清单；
  • 模板下载；
  • 简单浏览器端工具；
  • 少量表单或联系路径。

Cloudflare Pages 也不是不能加动态功能。Pages Functions 可以为 Pages 项目增加服务端逻辑。[Official fact - recheck before publishing] 但每加一个动态功能，就要多一个设计决定：数据放哪里、权限怎么做、安全怎么做、成本怎么算、维护谁负责。

不要为了“以后可能需要”把第一版做得太重。也不要为了“静态更轻”忽略第一版确实需要后台的事实。

第一版边界怎么划

很多选择之所以变复杂，是因为读者把“以后可能要做的功能”当成“第一版必须有的功能”。

可以用这条边界先切开：

  1. 如果没有这个功能，第一版就无法被目标读者使用，它可能是必须项。
  2. 如果没有这个功能，第一版只是没那么完整，但仍然能发布、被阅读、被反馈，它通常可以后置。
  3. 如果这个功能只是让项目看起来更完整，却不能验证读者是否真的需要这个站，先不要让它决定技术栈。

对指南站来说，第一版最重要的往往不是后台、会员、评论或支付，而是：读者能不能看懂路径，能不能找到下一篇，能不能相信你没有夸大承诺。把这些做好，静态优先路线才有意义。

如果你填完能力清单后仍然摇摆，先读 静态网站和动态网站到底有什么区别。那篇文章会把表单、评论、登录、支付、搜索和小工具放到更细的功能层面判断。

什么时候选 Cloudflare Pages

如果下面这些描述很像你的项目，Cloudflare Pages 可以优先考虑：

  • 第一版主要是文章、指南、文档或落地页；
  • 内容不需要很多人通过后台编辑；
  • 你可以接受 Markdown、模板或 Git 工作流；
  • 不需要从第一天就做会员、商城、支付或复杂后台；
  • 想尽量减少服务器和数据库维护；
  • 想先上线一个小而清楚的版本；
  • 愿意把工具、表单、搜索、评论等功能后置设计。

对 OnlyPat 建站指南，这就是当前更合理的方向。[Editorial judgment]

它的第一版不是会员社区，也不是商城，也不是大型 CMS。它首先应该是一个内容可信、结构清楚、能慢慢加模板和小工具的指南站。

什么时候选 WordPress

如果下面这些描述更像你的项目，WordPress 更值得考虑：

  • 多个非技术编辑每天更新内容；
  • 内容团队需要浏览器后台；
  • 需要大量成熟插件；
  • 需要可视化页面构建；
  • 需要会员、商城、预约、评论管理等功能；
  • 站点所有者已经熟悉 WordPress；
  • 你愿意接受 WordPress 的主题、插件、安全和更新维护。

WordPress 的优势是成熟和直接。

它的问题不是“不好”，而是你要接受它的运行方式：数据库、后台、主题、插件、主机和维护。

如果这些正是你需要的，WordPress 是很现实的选择。

今天能完成什么

今天不要纠结工具名字。

先写一份“第一版能力清单”：

能力 第一版必须有吗 可以以后再加吗 更偏 Pages 还是 WordPress
文章和指南
首页和关于页
隐私政策
联系表单
搜索
评论
会员登录
支付
后台编辑
多作者
模板下载
小工具

填完之后，你会发现答案通常很明显：

  • 如果大多数必须项都是内容和静态页面，选 Cloudflare Pages；
  • 如果大多数必须项都是后台、插件和动态功能，选 WordPress；
  • 如果只是“以后可能需要”，不要让未来假设绑架第一版。

OnlyPat 建站指南 的当前建议

对当前项目，我建议第一版继续按 Cloudflare Pages 方向规划。[Editorial judgment]

理由很具体：

  • 当前核心是中文指南内容；
  • 前四篇草稿已经是静态文章形态；
  • 短期要做的是内容、内链、清单、模板和服务线索；
  • 暂时没有多人后台编辑需求；
  • 暂时没有会员、商城、支付或复杂数据库需求；
  • guide.onlypat.com 更适合先做一个低风险子域名 launch target。

但这不是永久决定。

当前最合理的动作不是马上开项目，而是把第一版边界写下来：先做哪些文章和信任页面，哪些功能明确后置，哪些事实上线前必须再查官方来源。等边界清楚后，再接 用 90 天搭一个 Cloudflare 指南站的路线图 去安排执行顺序。

如果后面出现这些情况，可以重新评估：

  • 需要多人浏览器后台写作；
  • 要做大量结构化内容管理；
  • 要做会员或付费内容；
  • 非技术维护成本变成主要问题；
  • 静态工作流影响持续发布。

好的技术选择不是一次性信仰，而是跟着产品阶段调整。

FAQ

Cloudflare Pages 比 WordPress 更适合新手吗？

不一定。对愿意学习静态站、模板、Git 或部署流程的新手，Cloudflare Pages 可以很轻。对完全不想碰技术流程、只想在后台写文章的新手，WordPress 可能更直接。

WordPress 能不能部署到 Cloudflare Pages？

传统 WordPress 需要 PHP 和数据库，不是直接跑在 Cloudflare Pages 上的典型模式。可以用 WordPress 作为内容源再生成静态站点，但那已经是另一种架构，需要额外设计。

Cloudflare Pages 能不能做评论、表单、登录？

可以通过第三方服务、Pages Functions、Workers 或其他后端服务设计，但这些不是纯静态页面的默认能力。第一版如果不是必须，建议先后置。

哪个更适合 AdSense？

AdSense 更关心网站内容、导航、政策合规、用户体验和发布者控制权，不是简单看 Pages 或 WordPress。两个平台都不能保证通过。

哪个更适合 affiliate？

都可以。关键是文章是否解决真实选择问题，推荐是否有帮助，披露是否清楚，外链是否按当前规则处理。

以后能从 Pages 换到 WordPress 吗？

可以迁移，但会有内容结构、URL、图片、内链、SEO、模板和重定向成本。反过来从 WordPress 静态化也有成本。所以第一版要尽量选对工作流，但不用因为未来迁移可能而迟迟不开始。

最后怎么判断

选技术栈前，先问一句话：

第一版网站的核心，是内容发布，还是后台系统？

如果核心是内容发布，而且你愿意接受静态站工作流，Cloudflare Pages 是很好的起点。

如果核心是后台编辑、插件生态和动态功能，WordPress 更现实。

对大多数刚开始的小型指南站来说，最稳的动作不是找一个“完美平台”，而是先做出一个清楚、可读、可更新的第一版。

你今天真正要完成的不是注册一堆服务，而是写清楚第一版能力清单。

把必须有的功能列出来，把可以后置的功能划掉，技术选择就会安静很多。

如果你的表格明显偏 Cloudflare Pages，下一步先读 Cloudflare Pages 免费建站指南：适合什么，不适合什么，确认它适合什么、不适合什么。然后读 用 90 天搭一个 Cloudflare 指南站的路线图，把第一批内容、信任页面、域名准备和后续上线动作拆开。如果你的表格明显偏 WordPress，先不要硬转静态站，而是把后台、插件、编辑流程和维护责任列清楚。

如果你想测试服务线索，先回到 docs/service-lead-positioning.md，只保留“建站方向诊断”这种轻量边界。在实现获批前，不创建服务页、表单、支付、Cloudflare 项目、WordPress 主机或迁移流程。

Publication Verification Checklist

Before publishing this article, re-check:

  • Current Cloudflare Pages limits.
  • Current Cloudflare Pages Git integration and Direct Upload behavior.
  • Current Cloudflare Pages Functions documentation and quota relationship.
  • Current WordPress.org requirements.
  • Any specific WordPress hosting-provider pricing, feature, backup, security, or plugin claims if later added.
  • Current AdSense readiness guidance if the FAQ keeps ad-related comparisons.
  • Any affiliate or hosting recommendation disclosure and link qualification requirements.
  • Whether internal links point to the final published URLs for the Pages free website guide, static-vs-dynamic article, and 90-day roadmap.
  • Whether any service-lead CTA matches docs/service-lead-positioning.md and does not imply account handling, implementation work, migration work, traffic, revenue, or approval guarantees.
  • Whether the article still compares Cloudflare Pages and WordPress fairly, without implying either provider is universally better or officially connected to OnlyPat 建站指南.

Source Links

  • Cloudflare Pages limits: https://developers.cloudflare.com/pages/platform/limits/
  • Cloudflare Pages Git integration: https://developers.cloudflare.com/pages/get-started/git-integration/
  • Cloudflare Pages Direct Upload: https://developers.cloudflare.com/pages/get-started/direct-upload/
  • Cloudflare Pages Functions: https://developers.cloudflare.com/pages/functions/
  • WordPress.org requirements: https://wordpress.org/about/requirements/
  • WordPress.org features: https://wordpress.org/about/features/