Cloudflare Pages vs GitHub Pages vs Netlify Free: Which Host Fits a Small Dev Site in 2026?
If you ship documentation, a toolkit blog, or a small open-source landing page, the free static host decision is about daily friction: how you deploy, how previews work, what happens on traffic spikes, and whether the free tier still respects your time six months later.
This guide compares Cloudflare Pages, GitHub Pages, and Netlify’s free Starter tier for English-language developer content in 2026. The goal is not a universal winner—it is a default for a pilot site you might later monetize with display ads, without painting yourself into a corner.
Decision criteria that actually matter
Ignore “unlimited bandwidth” claims until you understand enforcement. For a small content site, prioritize:
- Deploy path — Git push vs CLI upload vs drag-and-drop. CLI matters when HTML is generated on a build machine that is not GitHub.
- Preview URLs — Unique URLs per upload save hours of “works on my laptop” debates.
- Headers and redirects — You will need robots.txt, trailing-slash redirects, and security headers. Prefer hosts that make this a file in the publish directory.
- Custom domain friction — Especially if nameservers cannot move (common with free subdomain providers). CNAME-only setups matter.
- Cold-start for content — How fast can you publish eight long articles and a privacy page without fighting the platform?
Also weigh accounting overhead: every extra vendor is another password, invoice email, and ToS change to track. For a solo pilot, fewer accounts usually beats slightly prettier dashboards.
Cloudflare Pages
Cloudflare Pages pairs a global CDN with a straightforward static publish model. Connect a Git repository or use direct upload via Wrangler (wrangler pages deploy). For pilots built on a scratch machine or agent box, direct upload is often the difference between shipped today and blocked on GitHub OAuth.
Strengths for a developer how-to site:
- Fast edge delivery and a clean
*.pages.devURL—ideal before binding a custom domain. - Workers integration when you later need a form endpoint or lightweight API.
- Reasonable free allowances for bandwidth and builds on typical blog traffic.
- Headers via
_headersand redirects via_redirectsin many setups, plus dashboard rules when needed.
Watch-outs: Wrangler versions track Node engine requirements; pin Node LTS on your build machine. Store account ID and tokens outside the web root—never in HTML or public Drive. Custom domains are easy on Cloudflare DNS, but if you must keep third-party nameservers, plan a CNAME to the Pages hostname and verify SSL in the Pages custom-domain UI later.
Operational tip: treat the folder on disk as source of truth. Redeploy the whole tree after edits instead of live-editing obscure dashboard fields. Keep a short runbook with the project name, production URL, and “how to redeploy” command so future-you (or a teammate) is not reverse-engineering chat logs.
GitHub Pages
GitHub Pages remains the path of least resistance if your source of truth is already a public GitHub repo. Enable Pages from a branch or Actions workflow, push Markdown or built HTML, and you get username.github.io or a project URL.
Strengths: zero extra accounts if you already live in GitHub; Actions can build Hugo, Eleventy, or a static export on every push; excellent for open-source docs tied to the same repo as the code. Limitations for an AdSense pilot: project sites under github.io share a parent-domain reputation story some publishers find slower for monetization experiments (not a hard block, but worth knowing). Custom domains work with A/AAAA or CNAME—only if you control DNS. Build minutes are usually fine for docs; they become painful if you rebuild huge artifact trees on every typo fix.
If you use Actions, cache dependencies and publish only the dist/ folder. Avoid committing generated secrets. For private repos, remember Pages availability depends on your GitHub plan—confirm before promising a client a private-docs URL on the free tier.
Netlify free
Netlify popularized JAMstack deploy UX: connect repo, set build command, get previews. The free Starter tier is still useful for demos and small marketing sites. Form handling, identity, and edge functions exist as product surfaces—but free quotas and fair-use policies change; read current Starter limits before promising “unlimited.”
Strengths: polished UI, deploy previews, large tutorial ecosystem. Friction: another vendor account, and bandwidth/build limits that can surprise you after a viral post. For pure static HTML with no build step, Netlify works but does not uniquely beat Pages or GitHub Pages for a content pilot.
If you already standardized on Netlify previews with designers, staying put can be rational. If you are starting greenfield and care about CLI upload from non-Git machines, Cloudflare Pages tends to win on workflow fit.
Side-by-side matrix
Need | CF Pages | GitHub Pages | Netlify free
--------------------------- | ------------ | ------------- | -------------
No-Git CLI upload | Excellent | Awkward | Possible
Git-connected builds | Strong | Native | Strong
Default URL | pages.dev | github.io | netlify.app
Custom domain via CNAME | Yes | Yes | Yes
Edge workers / functions | Workers | Actions only* | Functions
Best for agent/box builds | Yes | Needs GH push | Needs account
* serverless on GH needs separate hostingAdSense and policy notes
Host choice does not approve your AdSense application. Google cares about original content, clear ownership pages (About, Privacy, Contact), navigation, and policy-safe niches. Start on a stable HTTPS URL you control. A *.pages.dev pilot is a valid first step: publish substantial articles, keep ads as HTML comments (<!-- ADSENSE_SLOT -->) until you have a real publisher ID, then apply. Do not invent ca-pub IDs. Do not stuff keyword doorways. Prefer English how-tos that solve a real setup problem end-to-end.
When you later attach a free subdomain via CNAME, keep nameservers unchanged if your registrar requires it. Changing NS on some free domain providers can forfeit the domain—document that constraint in your runbook. Also separate “site ready for review” from “site ready for heavy ads”: placeholders and dashed boxes are fine pre-approval; after approval, use official AdSense code only.
A simple pick rule
Choose Cloudflare Pages when you want a fast pilot URL, CLI deploy from any machine, and a clean path to Workers later. Choose GitHub Pages when docs are inseparable from a public repo and you want zero extra vendors. Choose Netlify when your team already standardized on its preview workflow and Starter limits cover your traffic.
For the Negency Lab pilot, Cloudflare Pages plus a pages.dev URL is the deliberate first move: content and AdSense readiness first, custom domain CNAME second. Revisit the matrix after you have traffic data—not before you have eight solid articles and a privacy policy readers can actually understand.