Last updated: 2026-06-26

Last verified: 2026-06-26 for draft-level Cloudflare source check. Exact platform limits, prices, terms, and dashboard wording must be re-checked before publication.

OnlyPat 建站指南 is an independent guide-site project. This draft is not Cloudflare official documentation and does not imply any affiliation with Cloudflare.

先说结论

如果你想做一个个人站、指南站、文档站、作品集、落地页，或者一些主要在浏览器里运行的小工具，Cloudflare Pages 可以是一条很适合的低成本建站路线。

更重要的是，它会把“建一个网站”这件事从一团雾变成几块很清楚的积木：内容、域名、部署、HTTPS、后续变现。你不需要一开始就买服务器、搭数据库、做后台系统。只要第一版是静态优先的网站，就可以先把一个能看的版本跑起来，再一点点加内容、模板、工具和服务入口。

这也是 Cloudflare Pages 最让人兴奋的地方：它不是让你幻想一个庞大的系统，而是让你先做出一个可发布、可更新、可验证的小站。

但 Cloudflare Pages 不是万能的免费后端，也不应该被当成免费视频平台、大文件分发平台、网盘、复杂会员系统或重数据库应用的替代品。如果你的网站从第一天就需要用户登录、后台管理、支付、数据库、复杂权限、视频分发或大量文件下载，就要更谨慎地设计架构。

这篇文章先帮你判断：

  • 什么类型的网站适合 Cloudflare Pages；
  • 什么类型的网站不适合；
  • “免费建站”到底还会有哪些成本；
  • 新手在域名、部署方式、HTTPS 和后续变现上要先想清楚什么。

如果你读完后还在犹豫，可以继续看三篇配套文章：Cloudflare Pages 和 WordPress 怎么选、静态网站和动态网站到底有什么区别、用 90 天搭一个 Cloudflare 指南站的路线图。这三篇分别解决平台选择、架构理解和行动顺序问题。

这不是一步一步的部署教程。部署教程应该在平台限制、域名状态和项目技术栈确认后单独写。

30 分钟开工版

如果你现在只是想知道“我能不能开始”，先不用打开 Cloudflare 控制台，也不用改 DNS。

你可以先做这 5 件事：

  1. 写下网站的一句话定位，例如：我想做一个帮助新手用 Cloudflare Pages 低成本建站的中文指南站。
  2. 列出前 10 篇文章标题，先覆盖决策、域名、广告、WordPress 对比、静态/动态区别这些基础问题。
  3. 决定第一版是否静态优先：如果主要是文章、清单、模板和少量浏览器端工具，答案大概率是 yes。
  4. 记下你已有的域名和 DNS 状态，不要急着改。比如 onlypat.com 的注册商在阿里云，当前 DNS 已经在 Cloudflare。
  5. 给自己设一个小目标：先做出一个能被别人读懂的指南站，而不是一开始就做完整商业系统。

做到这里，你已经不是“想建站”，而是在做建站前最关键的判断了。

做到这里就可以停一下。你现在不需要创建 Pages 项目，不需要修改 DNS，也不需要申请 AdSense。下一步更值得做的是把网站路线写清楚：第一版谁会读、先发布哪些文章、上线前要准备哪些信任页面。

Cloudflare Pages 到底是什么

你可以先把 Cloudflare Pages 理解成一个适合托管静态网站的平台。

更通俗地说：你先把网站内容做成浏览器可以直接打开的文件，例如 HTML、CSS、JavaScript、图片和字体。然后把这些文件交给 Cloudflare Pages。Cloudflare 负责把这些文件从离用户更近的位置发给访问者。

对新手来说，这里有三个概念容易混在一起。

第一个是静态页面。它不是“不能动”的页面，而是服务器不需要每次都临时生成页面。比如一篇指南文章、一个作品集页面、一个产品介绍页，都可以是静态页面。页面里仍然可以有样式、图片、动画，也可以有一部分浏览器端交互。

第二个是静态站点生成。很多网站不是手写每一个 HTML 文件，而是用 Markdown、模板或组件写内容，再通过构建工具生成最终的静态文件。这样既能保持内容管理的效率，也能让最终上线的文件适合静态托管。

第三个是边缘函数或后端逻辑。Cloudflare Pages 可以和 Pages Functions、Workers 等能力组合使用，用来处理一些后端式功能，例如表单提交、轻量 API 或边缘逻辑。[Official fact - recheck before publishing] 但这不等于你可以把所有复杂后端都直接塞进 Pages。当项目需要登录、数据库、支付、权限和后台管理时，应该单独设计。

所以，Cloudflare Pages 最适合的起点是：网站的主要价值来自内容、页面结构和少量前端交互，而不是一个重后台系统。

哪些人应该考虑 Cloudflare Pages

如果你符合下面几种情况，Cloudflare Pages 值得优先考虑。

你是个人创作者，想用很低的固定成本做一个个人站、博客、指南站或作品集。你不想一开始就租服务器、维护系统、处理复杂后端，但愿意接受一个更偏“静态内容 + 部署流程”的工作方式。

你是小团队，需要一个文档站、帮助中心、产品说明页或项目落地页。内容更新有节奏，页面结构可控，不需要一开始就做复杂 CMS。

你想做一个像 OnlyPat 建站指南 这样的内容站：先用文章、清单、模板和小工具建立信任，再慢慢测试 affiliate、模板、服务线索和广告，而不是一开始就堆大量动态功能。

你是开发者，或者愿意学习一点 Git、Markdown、静态网站生成器和部署流程。Cloudflare Pages 的 Git 集成适合长期维护内容和版本记录。[Official fact - recheck before publishing]

你不是开发者，但可以接受先从模板和简单内容流程开始。后续如果需要后台编辑、视觉 CMS 或多人写作工作流，再根据真实需要升级。

Cloudflare Pages 适合做什么

Cloudflare Pages 很适合内容型、静态优先的网站。

比如指南站。指南站的核心是解决读者问题：解释概念、比较方案、列出步骤、给出检查清单。这类页面对每个读者通常是一样的，很适合静态生成和缓存。

比如文档站。产品文档、项目说明、使用手册、API 介绍、内部知识库，如果不依赖复杂权限，也很适合静态托管。

比如作品集和个人主页。页面数量不多，展示内容清晰，访问者主要是阅读和浏览。

比如落地页。一个活动页、产品介绍页、服务介绍页，通常不需要复杂后台，重点是加载速度、清晰表达和表单或联系方式。

比如小型前端工具。像简单计算器、格式转换器、清单生成器，如果数据不需要上传到服务器、也不涉及隐私或复杂持久化，可以先作为浏览器端工具实现。[Future implementation note] 这只是未来方向，不代表当前项目已经授权做工具代码。

Cloudflare Pages 不适合做什么

不要因为看到“免费托管”就把 Cloudflare Pages 当成所有项目的默认答案。

它不适合拿来做大规模视频托管。Cloudflare 对大体量视频和非 HTML 内容分发有单独的产品、政策和服务条款边界，正式发布前必须复核当前官方说明。[Official fact - recheck before publishing]

它也不适合被当成大文件下载站或网盘。指南站可以提供少量模板、清单、图片和正常网页资源，但如果网站主要价值变成大文件分发，就要重新检查 Cloudflare 的服务条款和更合适的产品路径。

它不适合从第一天就承担复杂会员系统。登录、权限、账户、支付、订单、后台管理、用户数据，这些都不是“放几个静态页面”能解决的问题。Cloudflare 生态里有 Workers、D1、KV、R2 等能力可以参与设计，但那已经是应用架构问题，不是单纯 Pages 托管问题。

它也不一定适合强依赖 WordPress 插件生态的项目。如果你从第一天就需要可视化编辑后台、多人编辑、成熟插件、评论系统、会员插件、WooCommerce 或大量现成主题，WordPress 可能更直接。Cloudflare Pages 和 WordPress 的选择，应该看工作流，不应该看谁更“高级”。

“免费建站”到底免费在哪里

新手最容易误解的一点是：Cloudflare Pages 可以让托管成本很低，但一个网站并不是完全零成本。

Cloudflare Pages 的免费路径通常指托管和部署可以从免费计划起步。官方限制页会列出构建次数、项目数量、自定义域名、文件数量、文件大小、Functions 相关限制等具体数字。[Official fact - recheck before publishing] 这些数字会变化，发布文章前必须重新检查官方文档，不应该靠旧教程记忆。

但你仍然要考虑其他成本。

域名通常是按年付费的。即使你用子域名启动，父域名也有续费成本。比如 guide.onlypat.com 这个规划中的子域名不需要单独购买，但 onlypat.com 本身仍然要续费。

模板、设计素材、图标、截图、AI 工具、写作时间、后续分析工具、邮件工具，都可能产生成本。你可以先少花钱，但不能把“托管免费”理解成“建站没有成本”。

还有一个容易被忽略的成本是维护。网站上线后要更新文章、修复过期截图、复核平台政策、处理坏链接、调整内链、维护域名和证书。一个低成本网站仍然需要持续管理。

可以把成本拆成下面几类：

成本项 是否可能免费起步 备注
Cloudflare Pages 托管 可以从免费路径开始 exact limits need current verification
域名 通常不能长期免费 要看注册商、后缀和续费价格
内容生产 没有现金成本也有时间成本 原创经验和更新最重要
模板和设计 可免费也可付费 不要一开始买太多
分析、邮件、搜索等工具 可先不用或用免费额度 后续按真实需求加
动态功能 简单功能可低成本，复杂功能另算 需要架构设计

选择 Pages 前必须理解的限制

Cloudflare Pages 有平台限制。限制不是坏事，它只是告诉你这个平台适合什么形态的网站。

正式发布前，至少要复核这些官方限制：

  • 每月构建次数；
  • 项目数量；
  • 自定义域名数量；
  • 单个文件大小；
  • 文件数量；
  • _headers 和 _redirects 等配置限制；
  • Pages Functions 与 Workers 配额之间的关系；
  • Direct Upload 和 Git 集成的工作流差异；
  • 大文件、视频和非 HTML 内容分发的服务条款边界。

这些内容都属于 [Official fact - recheck before publishing]。如果文章里要写具体数字，必须在发布当天或接近发布时间重新打开官方文档确认。

对一个正常指南站来说，最大的风险通常不是马上撞到 Pages 限制，而是误用场景。比如还没有内容，就先规划复杂会员系统；或者只是想做文章站，却把它设计成数据库应用；或者想靠免费 CDN 分发大量视频和文件。这些才是早期更实际的坑。

Git 集成和 Direct Upload 怎么选

Cloudflare Pages 常见的部署路径有两类：Git 集成和 Direct Upload。[Official fact - recheck before publishing]

Git 集成适合长期维护。你把网站项目放在 GitHub 或 GitLab 这样的代码仓库里，Cloudflare Pages 和仓库连接后，可以根据提交、分支或合并请求产生部署。对一个持续更新的指南站来说，这种方式更利于版本记录、回滚、协作和内容审核。

如果未来 OnlyPat 建站指南 进入实现阶段，较可能选择 Git 集成，因为这个项目需要长期写文章、改结构、做模板、加工具和记录变更。[Future implementation note] 这不是当前的实施授权，只是规划判断。

Direct Upload 则适合已经在别处构建好网站文件，然后直接上传到 Cloudflare 的情况。它可以减少对 Cloudflare 构建流程的依赖，也适合某些本地构建或外部构建平台。但如果后续要长期更新大量内容，仍然要考虑版本管理和自动化流程。

简单说：

  • 想长期做内容站、希望变更有记录：优先考虑 Git 集成；
  • 已经有构建产物，只想上传静态文件：可以了解 Direct Upload；
  • 不想碰任何技术流程：要么准备接受模板化工具，要么重新评估是否需要 WordPress 或托管式建站平台。

自定义域名和子域名怎么理解

Cloudflare Pages 默认会给项目一个 *.pages.dev 形式的地址，但正式对外发布时，通常会绑定自己的域名或子域名。[Official fact - recheck before publishing]

这里先把几个概念讲清楚。

onlypat.com 这种叫根域名，也常叫 apex domain。它通常代表一个品牌或主站。

www.onlypat.com 是常见的 www 子域名。很多网站会让 www 跳转到根域名，或者让根域名跳转到 www，关键是行为要一致。

guide.onlypat.com 是自定义子域名。这个项目目前把它作为 OnlyPat 建站指南 的工作 launch target，因为它既和建站主题相关，又不会把整个根域名立即迁移到新站。

DNS 记录就是告诉互联网：这个名字应该指向哪里。HTTPS 证书则是让浏览器信任 https:// 访问的那一层。

还有一个非常重要的操作区别：注册商、DNS 服务商、托管平台不是同一个概念。

以当前项目为例，用户确认 onlypat.com 的注册商在阿里云。也就是说，续费、域名所有权、实名、锁定、可能的备案和 nameserver 变更，未来要记得看阿里云这一层。

当前 guide.onlypat.com 已经在 Cloudflare Pages 里绑定，并在 Cloudflare DNS 中配置 CNAME 指向 Pages 项目。这个事实以后仍要在操作前复核，因为 DNS、nameserver 和项目绑定都可能被后续操作改变。

Cloudflare Pages 绑定自定义域名时，也不应该只手动加一条 CNAME 就结束。正确顺序通常应该是先在 Pages 项目里添加自定义域名，让 Cloudflare 给出或识别需要的配置，再去当前权威 DNS 里添加对应记录，最后验证 DNS、证书和访问结果。[Official fact - recheck before publishing]

当前项目仍处于文档规划阶段，不能修改 DNS、Cloudflare Pages、自定义域名、证书或 nameserver。

什么时候应该用 Cloudflare Pages

你可以用下面这份检查清单做判断。

适合使用 Cloudflare Pages 的情况：

  • 网站主要是文章、文档、作品集、落地页或静态工具；
  • 每个访问者看到的大部分内容相同；
  • 你希望降低服务器维护成本；
  • 你可以接受 Git、Markdown、模板或静态站点生成器工作流；
  • 你愿意把复杂功能放到后续阶段；
  • 你重视速度、版本记录和可控发布；
  • 你不想一开始就维护数据库和传统服务器。

需要谨慎的情况：

  • 你第一天就需要用户注册、登录和会员中心；
  • 你需要复杂后台管理；
  • 你需要大量非技术人员通过浏览器后台编辑内容；
  • 你严重依赖 WordPress 插件；
  • 你的网站主要是视频、大文件或下载分发；
  • 你还没有想清楚内容方向，只是想先找个免费托管；
  • 你不愿意处理任何域名、DNS、部署或版本管理概念。

如果你只是想做一个指南站，Cloudflare Pages 往往是合理起点。如果你想做一个完整 SaaS 或会员社区，Pages 可能只是前端托管的一部分，而不是整个系统。

一个更稳妥的第一项目路径

如果你是新手，不建议一开始就把目标设成“做一个能自动赚钱的网站”。更稳的路径是先做一个小而清晰的指南站。

第一步，确定一个具体主题。例如 Cloudflare Pages + 低成本建站 + 小网站变现准备。主题要窄到你能写出具体问题，而不是泛泛写“互联网教程”。

第二步，规划前 10 篇文章。对 OnlyPat 建站指南 来说，当前的前 10 篇文章包括 Cloudflare Pages 免费建站、Pages 能不能放广告、AdSense 准备、为什么不要只靠广告、Pages 和 WordPress 选择、域名选择、前 30 篇文章规划、affiliate 信任、静态和动态网站区别、90 天路线图。[OnlyPat internal standard]

第三步，先写有用内容，不急着上广告。广告不是不能做，但新站前期更需要证明读者愿意读、愿意点击相关链接、愿意下载清单、愿意询问服务。

第四步，准备基础信任页面。以后真正上线时，至少要有首页、指南索引、关于页、隐私政策、联系方式或联系路径。如果有 affiliate 链接，还要有清晰披露。

第五步，再考虑工具、模板和服务。比如建站准备清单、AdSense readiness 检查表、域名/DNS 检查表、第一批文章规划表。这些资产比单纯广告更适合小站早期测试信任。

第六步，等内容和用户体验足够完整后，再考虑 AdSense 或其他展示广告。这里没有保证过审，也没有保证收入。它只是一个更健康的顺序。

上线前先准备哪些信任页面

如果你把 Cloudflare Pages 当成低成本上线工具，很容易只盯着部署成功。但一个真正能让读者留下来的指南站，还需要让读者知道你是谁、你收集什么、你为什么推荐某个工具，以及他们怎么联系你。

第一版至少应该准备这些页面或说明：

  1. 首页：说明这个站解决什么问题，让读者知道从哪篇开始。
  2. 指南索引：按问题组织文章，而不是只按发布时间堆列表。
  3. 关于页：说明 OnlyPat 建站指南 是独立项目，不是 Cloudflare、Google、WordPress、阿里云或 DNSPod 官方站点。
  4. 隐私政策：只写实际启用的功能，不要提前写不存在的广告、表单、账号或支付逻辑。
  5. Affiliate Disclosure：如果未来有推广链接，要让读者在点击前知道可能存在佣金关系。
  6. 联系路径：允许读者反馈文章过期或咨询建站方向，但不要收集账号密码、API token、后台凭据或未打码敏感信息。

这些页面不需要一开始写得很复杂，但不能完全没有。它们会影响读者信任，也会影响以后做 affiliate、服务线索、模板、广告申请和政策复核时的基础质量。

对 OnlyPat 建站指南 来说，当前已经有站点信息架构规划，后续文章审稿时应该把这些信任页面自然串进内链和 CTA，而不是等到上线前最后一天才补。

常见错误

第一个错误，是把免费托管当成商业模式。免费托管只能降低成本，不能自动带来流量、信任、转化或收入。

第二个错误，是用大量通用 AI 文章填站。搜索和读者都不缺泛泛而谈的内容。一个新指南站更需要具体经验、决策理由、截图、清单、错误处理和持续更新。

第三个错误，是忽略域名和证书。网站内容写好了，但根域名、www、子域名、DNS、HTTPS、跳转关系混乱，会直接影响上线体验。

第四个错误，是第一版就做太多动态功能。评论、账号、支付、后台、搜索、邮件订阅、工具库都可以很有价值，但不一定都要在 MVP 里出现。

第五个错误，是把 Cloudflare Pages 当成大文件或视频分发平台。正常网页资源和指南站内容是一回事，大规模视频或文件分发是另一回事，必须查官方条款和对应产品。

第六个错误，是在没有披露和真实判断标准的情况下做 affiliate 推荐。推荐本身可以变现，但如果读者感觉你只是为了佣金推荐，信任会比收入先消失。

FAQ

Cloudflare Pages 真的可以免费建网站吗？

可以从免费路径开始，但不要理解成网站完全零成本。你还要考虑域名续费、内容生产、模板、工具、维护时间和后续可能的付费服务。具体免费计划限制必须以 Cloudflare 当前官方文档为准。[Official fact - recheck before publishing]

我需要会写代码吗？

不一定要成为专业开发者，但你至少要理解静态网站、部署、域名和 DNS 的基本概念。如果使用模板或别人搭好的系统，你的技术压力会低一些；如果自己维护 Git 和构建流程，就需要学习更多。

Cloudflare Pages 可以绑定自己的域名吗？

可以绑定自定义域名或子域名。[Official fact - recheck before publishing] 但正确做法不是只随便加一条 DNS 记录，而是要按 Pages 自定义域名流程配置，并在当前权威 DNS 服务商那里添加正确记录，最后验证 HTTPS。

我已经有阿里云域名，还能用 Cloudflare Pages 吗？

可以。域名注册在阿里云，不等于网站必须托管在阿里云。你需要先确认当前 DNS 权威服务商在哪里。当前 onlypat.com 的 DNS 已经在 Cloudflare；如果以后要改 nameserver，才涉及阿里云注册商侧操作。这个顺序要根据当时实际状态复核。

Cloudflare Pages 可以做 WordPress 吗？

传统 WordPress 是动态 CMS，需要 PHP、数据库和后台环境，不是直接跑在 Cloudflare Pages 上的典型模式。你可以用 WordPress 作为内容源再生成静态站点，但那已经是另一种架构。新手不要把“WordPress 网站”和“Pages 静态托管”混成一件事。

Cloudflare Pages 网站可以放广告吗？

技术上，静态网页可以加载广告脚本，但能不能申请并持续使用 AdSense 或其他广告网络，取决于广告平台的审核、政策、内容质量和用户体验。Cloudflare 托管不等于 Google 批准。这个问题应该单独看。

Cloudflare Pages 适合中文网站吗？

适合不适合，主要看目标读者、内容质量、访问地区、域名和合规要求。中文内容本身不是问题，但如果涉及中国大陆访问、备案、域名注册商、DNS、加速和服务可用性，就要单独评估。

后面可以加表单、评论、登录或支付吗？

可以设计，但不要把它当成 Pages 的默认静态能力。表单可以用第三方服务或函数，评论可以用外部服务或独立系统，登录和支付则需要更谨慎的安全与后端设计。建议先用最小功能验证内容价值。

最后怎么判断

如果你现在想做的是一个内容清晰、成本低、后续可以慢慢加工具和变现方式的指南站，Cloudflare Pages 值得认真考虑。

如果你现在想做的是一个复杂应用、会员系统、视频站、大文件下载站或重后台 CMS，那么 Cloudflare Pages 可能不是完整答案，最多只是整个架构的一部分。

对 OnlyPat 建站指南 这个项目来说，当前更合理的路线是：

  1. 先保持文档和内容规划；
  2. 写出第一批高质量指南草稿；
  3. 确认信息架构、首页、关于页、隐私政策和披露页；
  4. 在明确授权后再选择技术栈并创建 Cloudflare Pages 项目；
  5. 按顺序处理 guide.onlypat.com 的自定义域名、DNS、HTTPS 和上线验证；
  6. 用模板、清单、服务线索和 affiliate 测试早期信任；
  7. 等内容和体验成熟后，再评估广告。

如果你也在做类似的小网站，可以先问自己一句话：

我的网站第一版，核心价值是不是“让读者读懂并完成一件事”？

如果答案是 yes，Cloudflare Pages 很可能是一个值得从这里开始的选项。

下一步不要急着配置一堆东西。先把这三项准备好：

  1. 第一批 10 个文章题目；
  2. 一个明确的域名或子域名计划；
  3. 一个最小上线目标，例如“先发布 5-10 篇能解决真实问题的指南”。

这三项想清楚之后，再去做 Cloudflare Pages 项目、DNS、HTTPS 和部署，成功率会高很多，也不容易在控制台里迷路。

如果你下一步想继续判断技术路线，先读 静态网站和动态网站到底有什么区别。如果你在 Pages 和 WordPress 之间摇摆，先读 Cloudflare Pages 和 WordPress 怎么选。如果你已经决定做指南站，就直接用 用 90 天搭一个 Cloudflare 指南站的路线图 把第一阶段拆成可执行任务。

Publication Verification Checklist

Before publishing this article, re-check:

  • Cloudflare Pages current limits and pricing language.
  • Cloudflare Pages Git integration behavior.
  • Cloudflare Pages Direct Upload behavior.
  • Cloudflare Pages custom-domain setup steps.
  • Cloudflare Pages Functions and Workers quota relationship.
  • Cloudflare service terms and video / large-file delivery policy.
  • Current DNS state for any project-specific onlypat.com example.
  • Whether any exact platform numbers in the article still match official docs.
  • Whether internal links point to the final published URLs for the WordPress comparison, static/dynamic explanation, and 90-day roadmap.
  • Whether About, privacy policy, affiliate disclosure, and contact-path wording match the actual site features enabled at launch.
  • Whether the article still avoids implying Cloudflare, Google, WordPress, Aliyun, DNSPod, AdSense, affiliate-program, traffic, or revenue guarantees.

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 custom domains: https://developers.cloudflare.com/pages/configuration/custom-domains/
  • Cloudflare service-specific terms: https://www.cloudflare.com/service-specific-terms-application-services/
  • Cloudflare video delivery policy note: https://developers.cloudflare.com/fundamentals/reference/policies-compliances/delivering-videos-with-cloudflare/